[Gc] Memory leak in multithreaded application

Hans Boehm Hans.Boehm at hp.com
Sat May 12 09:06:58 PDT 2007

Note that the win32 thread support has changed significantly in 7.0,
and I checked in a bunch of changes to that very recently.  If there's
any way to use the CVS sources instead, that would be much better.
If it helps, I can generate a 7.0alpha9 package from the current CVS
sources rather quickly.


On Sat, 12 May 2007, Christophe Meessen wrote:

> 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?
> >
> > Hans
> 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
> _endthreadex call.
> 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 mailing list