JvAttachCurrentThread doesn't seem to call GC_new_thread

Mon Jan 26 23:24:00 GMT 2004

I think it's not trivial to fix, though probably possible.
There was some discussion of this on the GC list, together with code
to fix this on the Linux side by using linker games to intercept pthread_create
and thus to keep track of all threads. This probably isn't exactly what you want,
but it may be good enough. And it doesn't work on Windows.
On the Windows side, calling GC_new_thread() in the newly created thread is
basically correct, I think, though there should probably be a check to
prevent duplicate registration.
On the Unix/Linux side, it should also be possible to do something similar.
But we need a way to find the stack base from corresponding to an arbitrary thread.
(In the case of IA64, we need both of them.) Pthread_getattr_np() might
do the trick for Linux, but I'm not sure it's reliable. Otherwise, GC_find_limit()
should work if there is a guard page at the base of the stack. Or
we could try searching /proc/self/maps. But that sounds brittle.
In any case, something along these lines needs to get added soon.
Hans
> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> Sent: Monday, January 26, 2004 2:02 PM
> To: Per Bothner
> Cc: java@gcc.gnu.org; hans_boehm@hp.com
> Subject: Re: JvAttachCurrentThread doesn't seem to call GC_new_thread
>>> >>>>> "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
>