[Gc] windows static thread (release) error
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
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
> -----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
> 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