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.
Hans
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.
>>>