[Gc] Memory leak in multithreaded application
meessen at cppm.in2p3.fr
Sat May 12 01:03:55 PDT 2007
Boehm, Hans a écrit :
> What's the GC version and platform?
> If the memory usage keeps increasing roughly linearly, I would suspect a
> leak somewhere. It would be good to understand whether the GC heap or
> something else is growing. This is usually easy to determine by running
> with GC_PRINT_STATS set. GC7 will also tell you the amount of reachable
> memory at each collection.
> If this is on Windows, and the problem is not primarily the GC heap, my
> top guess would be a leak of thread resources in win32_threads.c. There
> should probably be a test case that starts lots of threads in a loop ...
> Presumably there is some idle time, so the threads get a chance to shut
> down? How many threads does the OS think are alive?
I use gc6.8 with windows XP and visual 2003.
The leak source is related to threads and most probably because of
unclosed handle. Before investigating this further, I would first like
to know if I am using libgc support of threads properly. I could not
find any documentation or examples on this. Any link to suggest ?
I was using GC_CreateThread directly. Should I use thread_start instead ?
Browsing through the win32_thread.c file I saw that GC_CreateThread
calls CreateThread. According to windows documentation it should use
_beginthreadex and _endthreadex instead. "For an executable file linked
with LIBCMT.LIB, do not call the Win32 ExitThread API; this prevents the
run-time system from reclaiming allocated resources. _endthread and
_endthreadex reclaim allocated thread resources and then call ExitThread."
Since _endthreadex has to be called from within the thread before exit,
libgc should better use a proxy call that will take care of the
User should also call _exit() instead of exit(). It is apparently
related to releasing handle to DLLs. Without such calls, one may have
memory leaks resulting from handle leaks.
More information about the Gc