gcj crashes if a user-thread gives up its rights
Tue Dec 14 21:25:00 GMT 2004
>From my perspective, it makes no sense to support this in the GC,
so long as this is relying on a pthreads implementation bug.
Fixing setuid semantics is apparently on the NPTL to-do list.
If we did want to support this, I think the first step would be for
the nptl maintainers to introduce a primitive which is documented
to do what you want (pthread_setuid_np()?). It's very unclear to
me whether this in fact can be reliably supported. Looking at the
nptl source, it still seems to rely on signals for a few things.
As a security mechanism, this also seems like a very partial solution
to me, since it's fairly easy for Java code to get other threads to
do things on its behalf (e.g. by defining a finalize() method, or through
some GUI toolkit that). And for non-Java code, it would be trivial
to just hijack another thread.
There may be other reasons to move towards running the GC in its
own thread, though those arguments apply mostly to the marker itself,
not the thread stopping code.
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org]On Behalf Of
> Bryce McKinlay
> Sent: Tuesday, December 14, 2004 8:39 AM
> To: Jost Boekemeier
> Cc: email@example.com
> Subject: Re: gcj crashes if a user-thread gives up its rights
> Jost Boekemeier wrote:
> >On Mon, 2004-12-13 at 18:17, Bryce McKinlay wrote:
> >>It would be interesting to know how these other VMs solved
> the issue.
> >Mediator pattern. The mediator still runs with the appropriate
> >privileges. I guess GCJ already has a mediator which
> iterates through
> >the list of threads and stops each of them when the user-thread's GC
> >wants to run. The only thing that seems to fail is the
> command that the
> >user-thread's GC sends to the mediator.
> In the current code, there isn't a separate "mediator" thread
> - any user
> thread which the GC happens to run in will try to call
> pthread_kill to
> suspend the other threads.
> >>Is there is another IPC mechanism with the necessary
> semantics - ie able
> >>to suspend any thread at any time, asynchronously?
> >I think this should not be necessary. The mediator waits
> for commands
> >anyway, so a simple pipe would be sufficient. Even a
> condition variable
> >will work. So we only have to change the pthread_kill() into a
> That wouldn't work, because pthread_cond_signal() won't interrupt a
> thread that isn't actually waiting on the right condition variable.
> You'd still have to either use pthread_kill() or have the compiler
> insert interrupt points at each basic block edge. The later
> would have a
> performance effect and would be tricky to implement in the
> presence of
> blocking IO, etc.
> What may work, however, is instead of sending the pthread_kill's from
> whichever thread the GC happens to occur in, dedicate one, always
> privileged thread to sending the pthread_kill's and running the GC.
> Suspended threads could then enter a pthread_cond_wait()
> waiting for the
> restart signal from the collector thread.
More information about the Java