| Bug #25222 | Win32 HANDLE leak in my_sopen() | ||
|---|---|---|---|
| Submitted: | 20 Dec 2006 19:15 | Modified: | 13 Mar 2007 19:10 |
| Reporter: | Shane Bester (Platinum Quality Contributor) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: General | Severity: | S3 (Non-critical) |
| Version: | 5.0 | OS: | Windows (windows) |
| Assigned to: | Iggy Galarza | CPU Architecture: | Any |
[5 Jan 2007 18:11]
MySQL Verification Team
trudy, it's only a handle leak that happens *after* the server starts spitting out errno 24... So, it's something that an administrator would fix before the handle leak itself becomes a problem. (windows can allocated hundreds of thousands of handles). The fix is so simple (1 liner) it should be done anyway.
[7 Mar 2007 15:50]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/21371 ChangeSet@1.2468, 2007-03-07 10:46:38-05:00, iggy@recycle.(none) +1 -0 Bug#25222 Win32 HANDLE leak in my_sopen() - When attempting to associate a Windows File handle to a C run-time file handle there is an upper bound. Once reached, the newly created handles will cause a memory leak since they are not properly associated with a handle that can later be cleaned up.
[8 Mar 2007 22:01]
Timothy Smith
pushed to 5.0.38, 5.1.17 Minor user-visible difference. Once mysqld (on windows only) reached the limit of open file descriptors, it used to start leaking memory (due to not cleaning up a partially-allocated resource). Now this error condition is noticed and the resource is cleaned up, removing the memory leak. Note this is a minor issue, since the leak only shows up once you're already in trouble.
[13 Mar 2007 19:10]
Paul DuBois
Noted in 5.0.38, 5.1.17 changelogs.
Description: I looked at the code in my_open.c, and noticed that Win32 function CreateFile() is used to open a file on windows. Then, a c runtime handle is created using the _open_osfhandle() function. Those c runtime handles can reach a maximum of 2048 before mysqld will give errno 24. This is expected. It looks like a HANDLE leak exists in my_sopen() when errno 24 is given. CreateFile() will succeed, but _open_osfhandle() can fail at 2048.. In this case, the handle from CreateFile is never closed!! The result is ever increasing open win32 HANDLE's. How to repeat: read the code in my_open.c: File my_sopen(const char *path, int oflag, int shflag, int pmode) ... if ((osfh= CreateFile(path, fileaccess, fileshare, &SecurityAttributes, filecreate, fileattrib, NULL)) == INVALID_HANDLE_VALUE) { /* * OS call to open/create file failed! map the error, release * the lock, and return -1. note that it's not necessary to * call _free_osfhnd (it hasn't been used yet). */ _dosmaperr(GetLastError()); /* map error */ return -1; /* return error to caller */ } fh= _open_osfhandle((intptr_t)osfh, oflag & (_O_APPEND | _O_RDONLY | _O_TEXT)); return fh; Suggested fix: if the call to _open_osfhandle() above fails, CloseHandle() must be called on the osfh HANDLE !