[Gc] windows static thread (release) error

Boehm, Hans hans.boehm at hp.com
Wed May 23 11:03:32 PDT 2007


Can you clarify whether you're using REDIRECT_MALLOC?

I actually don't understand what's going on here.
GC_malloc_uncollectable() should initialize the collector on demand,
since it's never handled with a thread-local free list.  GC_malloc may
have a problem, but it also shouldn't with REDIRECT_MALLOC.

Is the problem with GC_malloc calls from static constructors without
REDIRECT_MALLOC?  Or is one of the initialization checks not working?

If we do need the initialization checks back, I think I would prefer to
perform them at the GC_malloc rather than operator new level.  It seems
weird to me that this would work one way and not the other.  In the more
common cases, I think we're talking about a zero check on a register in
GC_malloc, so the cost is not exorbitant.  I just can't figure out how
to move it to the slow path, as is the case for non-thread-local
allocation.

Looking at the GC_malloc code in thread_local_alloc, I'm suspicious that
the USE_PTHREAD_SPECIFIC and REDIRECT_MALLOC path doesn't quite work.
But that shouldn't affect you (nor probably very many others).
Presumably USE_WIN32_COMPILER_TLS is getting defined when you compile
thread_local_alloc.c?

Thanks.

Hans


> -----Original Message-----
> From: Christophe Meessen [mailto:meessen at cppm.in2p3.fr] 
> Sent: Wednesday, May 23, 2007 10:17 AM
> To: Boehm, Hans
> Cc: gc at napali.hpl.hp.com
> Subject: Re: [Gc] windows static thread (release) error
> 
> Hello,
> 
> since gc7.0a9 is not working in release mode, I'm back to 
> 6.8. But it also doesn't work in release mode. Stack trace 
> shows that a GC_malloc_uncollectable is performed in cinit 
> which is called before main to initialize global or static 
> variables. GC_INIT was not called.
> 
> Suggestion: adding inline code in all c++ new operators to 
> call GC_INIT before malloc if gc is not yet initialize. This 
> can be wrapped in an ifdef so that it is only inserted when desired.
> 
> This will make C++ code using libgc more robust against 
> global and static initialization involving malloc calls. I 
> will try it with gc6.8 to see how far I get with this change.
> 



More information about the Gc mailing list