JvAttachCurrentThread doesn't seem to call GC_new_thread
Tom Tromey
tromey@redhat.com
Mon Jan 26 22:12:00 GMT 2004
>>>>> "Per" == Per Bothner <per@bothner.com> writes:
Per> I got a bug report from a client about aborting with "Collecting from
Per> unknown thread", which is in GC_push_all_stacks in
Per> win32_threads.c. This was from a native thread that he called
Per> JvAttachCurrentThread on.
Per> It looks to me like we don't handle the case of a native thread that
Per> is not the initial thread. This applies to both pthreads (Posix) and
Per> Win32.
Per> Am I missing something? Or is this a known limitation? Would it be
Per> difficult to fix? Obviously some locking is needed.
I think this is just an oversight. Fixing the libgcj side is pretty
easy, just add new GC hooks, call from the register and unregister
functions, and implement in boehm.cc and nogc.cc.
Whether or not this is fixable on the GC side is another story. I
don't know the answer. This text in gc.h (relevant to Windows) makes
it sound tricky:
* All threads must be created using GC_CreateThread, so that they will be
* recorded in the thread table. For backwards compatibility, this is not
* technically true if the GC is built as a dynamic library, since it can
* and does then use DllMain to keep track of thread creations. But new code
* should be built to call GC_CreateThread.
Folks on the GC list will probably have a better idea.
Tom
More information about the Java
mailing list