Bug #25222 Win32 HANDLE leak in my_sopen()

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 !

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.

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.

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.

Noted in 5.0.38, 5.1.17 changelogs.