This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: JvAttachCurrentThread doesn't seem to call GC_new_thread
- From: Tom Tromey <tromey at redhat dot com>
- To: Per Bothner <per at bothner dot com>
- Cc: java at gcc dot gnu dot org, hans_boehm at hp dot com
- Date: 26 Jan 2004 15:02:18 -0700
- Subject: Re: JvAttachCurrentThread doesn't seem to call GC_new_thread
- References: <40158528.4070603@bothner.com>
- Reply-to: tromey at redhat dot com
>>>>> "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