Thank you for checking this.
If I read this right, the leaking that was coming from the exceptions
during static linking was eliminated using this patch. That seems like a
good thing.
There are 2 leaks left, but they are always leaking. I know one of them
is argv[0] (the currently running program). Probably makes sense to
leave this alone. Not sure what the 16byte thing is, but it doesn't
seem to be cumulative, so I'm not much motivated to seek it out.
dw
On 10/31/2014 11:27 PM, lh_mouse wrote:
> 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
------------------------------------------------------------------------------
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
