From bruen...@google.com on February 20, 2013 11:38:26

xref issue #1134 xref the leak mentioned here, in gcc's libgcc/config/i386/gthr-win32.c,
though the leak for this issue is still there with -mthreads:

1. The destructor supplied to __gthread_key_create is ignored for
   generic x86-win32 ports. This will certainly cause memory leaks
   due to unreclaimed eh contexts (sizeof (eh_context) is at least
   24 bytes for x86 currently).

   This memory leak may be significant for long-running applications
   that make heavy use of C++ EH.

   However, Mingw runtime (version 0.3 or newer) provides a mechanism
   to emulate pthreads key dtors; the runtime provides a special DLL,
   linked in if -mthreads option is specified, that runs the dtors in
   the reverse order of registration when each thread exits. If
   -mthreads option is not given, a stub is linked in instead of the
   DLL, which results in memory leak. Other x86-win32 ports can use
   the same technique of course to avoid the leak.

From bruen...@google.com on February 20, 2013 11:46:31

although I have not taken the time to prove it, most likely this is a real leak so I'm going to add a suppression

Labels: -Bug-FalsePositive ThirdParty-Bug

From bruen...@google.com on February 20, 2013 11:48:34

for the record, this shows up on the test app listed in issue #1134

From bruen...@google.com on February 20, 2013 11:54:21

Actually, the reason the mingw key dtors aren't freeing the memory may be
due to the issue #1134 bug.
from mingw's src/libcrt/crt/tlsthrd.c:
LPVOID value = TlsGetValue (keyp->key);
if (GetLastError () == ERROR_SUCCESS)
{
if (value)
(*keyp->dtor) (value);
}

TlsGetValue() will fail b/c TlsFree was already called (that's the issue #1134 bug) and thus the destructor won't be called, at least from looking at the
code.

From bruen...@google.com on February 20, 2013 13:08:30

filed as https://sourceforge.net/p/mingw/bugs/1928/

From derek.br...@gmail.com on February 21, 2013 13:42:50

This issue was closed by revision r1190 .

Status: Fixed