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:\Desktopg++ test.cpp -std=c++11
E:\Desktopa
++exception caught, e = 12345
/// using original mingw-w64 static libs - a number
leaked ///
E:\Desktopg++ test.cpp -std=c++11 -static
E:\Desktopa
--exception caught, e = 12345
/// using patched mingw-w64 shared libs - 2 leaked
///
E:\Desktopg++ 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:\Desktopa
++exception caught, e = 12345
/// using original mingw-w64 static libs - 2 leaked
///
E:\Desktopg++ 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:\Desktopa
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
