[Gc] windows static thread (release) error

Boehm, Hans hans.boehm at hp.com
Tue May 22 14:08:19 PDT 2007

I'm a bit confused about what's going on various Windows platforms.

Some general observations:

I checked a couple of bug fixes into the CVS tree that causes
NT_MAKEFILE (single threaded) to work again in the 7.0 tree.  A couple
of silly bugs had crept in.  These prevented a successful build.

Under 7.0, it is generally more important to call GC_INIT(), at least in
the absence of REDIRECT_MALLOC. 7.0 often
arranges for CC_malloc to do thread local allocation, which often makes
it harder to do initialization on first call.  The good news is that the
rules were simplified:  You just invoke GC_INIT() from the main
executable (not from a dynamic library) before you make any other GC
calls, except possibly for setting of some GC modes.

7.0 tries to avoid locking, and hence calling thread routines, before
the second thread is started.  This may improve some startup issues with

I have tested with REDIRECT_MALLOC only on Linux.  I suspect it will
still take work to get it to work on Windows with threads, but I haven't
had the time to seriously try.  Even on Linux, I suspect there are still
some rough spots with threads.  There is only a hack to deal with
thread-local data, which becomes potentially critical since the startup
code can use it to point to malloced data.  But this is far better than

If there's any way to avoid REDIRECT_MALLOC, please do.  If you can't,
your chances are usually much better with single-threaded executables.
Hopefully this will improve ...


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Christophe Meessen
> Sent: Friday, May 18, 2007 12:47 PM
> To: gc at napali.hpl.hp.com
> Subject: Re: [Gc] windows static thread (release) error
> I tried to compile gc6.8 in release mode and there is a 
> problem because GC_malloc_incollectable is called in 
> _cinit(). The function that initializes global and static 
> variables. I guess it is because GC_INIT() is not called.
> This malloc is apparently done by a bsic_filebuf constructor 
> which calls a basic_streambuf constructor.
> I didn't saw that with gc7.0a9. Weird.
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list