I have applied the patch and here are test results:
/////////////////////// using original mingw-w64 shared libs - 2 leaked
///////////////////////
E:\Desktop>g++ test.cpp -std=c++11
E:\Desktop>a
++exception caught, e = 12345
/////////////////////// using original mingw-w64 static libs - a number leaked
///////////////////////
E:\Desktop>g++ test.cpp -std=c++11 -static
E:\Desktop>a
++++++++--++++exception caught, e = 12345
----
/////////////////////// using patched mingw-w64 shared libs - 2 leaked
///////////////////////
E:\Desktop>g++ test.cpp -nodefaultlibs -L "E:\Desktop\temp\lib32" -std=c++11
-lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32
-lshell32 -luser32 -lkernel32 -liconv -lmingw32 -lgcc_s -lgcc -lmoldname
-lmingwex -lmsvcrt
E:\Desktop>a
++exception caught, e = 12345
/////////////////////// using original mingw-w64 static libs - 2 leaked
///////////////////////
E:\Desktop>g++ test.cpp -nodefaultlibs -L "E:\Desktop\temp\lib32" -std=c++11
-lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32
-lshell32 -luser32 -lkernel32 -liconv -lmingw32 -lgcc -lgcc_eh -lmoldname
-lmingwex -lmsvcrt -static
E:\Desktop>a
++++exception caught, e = 12345
--
(Stud PE reported no malloc() or free() was imported from msvcrt.dll.)
------------------
Best regards,
lh_mouse
2014-11-01
-------------------------------------------------------------
发件人：dw <limegreenso...@yahoo.com>
发送日期：2014-11-01 11:18
收件人：mingw-w64-public,lh_mouse
抄送：
主题：Re: [Mingw-w64-public] Potential memory leaks in exception handling?
>> AFAIK mingw-w64 uses callbacks to reclaim TLS memory. In the first
>> case, upon destruction of the static object there were 5 blocks of
>> memory unfreed; and in the second case there were 6. If we say there
>> was no memory leak in case 1, then there must be in case 2, IMO.
>
> I've tried this myself, and I think I'm seeing what you are seeing. It
> looks to me like the problem comes from ___w64_mingwthr_add_key_dtor
> in tlsthrd.c. In this routine, calloc is called to create a
> __mingwthr_key_t. However, I don't believe that memory ever gets freed.
>
> In theory it could get freed in ___w64_mingwthr_remove_key_dtor (at
> least there is a free for it there), but apparently that routine never
> gets called.
>
> Maybe it was supposed to be freed in __mingwthr_run_key_dtors when it
> gets called?
So, I believe I have the patch for this (attached). lh_mouse, can you
confirm?
Note that the way you were checking your code (test2.cpp) is flawed,
since some of the frees occur after the destructor of your counter. As
an alternative, try adding putchar('+') in malloc and putchar('-') in
free, and count the pluses and minuses in the output.
Turns out it's not much of a leak, and the memory can't be freed until
application shutdown (or possibly at dll unload time) since it is used
right up until the last minute.
dw
------------------------------------------------------------------------------
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
