[Gc] windows static thread (release) error

Christophe Meessen meessen at cppm.in2p3.fr
Sun May 27 05:28:06 PDT 2007


Hello,

Boehm, Hans a écrit :
> Can you clarify whether you're using REDIRECT_MALLOC?

I use straight out of the box NT_STATIC_THREAD makefile. Apparently
there is no REDIRECT_MALLOC anywhere.

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

Maybe I should define REDIRECT_MALLOC. What should I do to do so ?

I'm using vc++2003. I tried to install vc++2005 but apparently it seem
to block in the installation process. I had to stop it after two hours
running.

Symptom summary:
- 6.8&7.0a9 debug: no problems,
- 6.8 debug and commenting out GC_INIT: no problem,
- 6.8 release: stops at program start -> attempt to write at address 10
- 7.0a9 release: stops when starting a new thread -> attempt to write at
address 10.
- 7.0a9 debug with GC_INIT commented out: stops at program start ->
attempt to write at address 10.
- 7.0a9 release without -DTHREAD_LOCAL_ALLOC: still stops at start.

The error message are similar between 6.8 and 7.0 but this might be a
coincidence. One get such type of message when dereferencing a NULL
pointer. The last test produces the same error message with debug
version when the collector is not initialized. This seems to indicate
that the problem is related to missing initialization.




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

Sorry, I have not enough understanding of the gc engine to understand this.

> 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?

Should it be defined ?


More information about the Gc mailing list