gcj crashes if a user-thread gives up its rights

Sun Dec 12 06:32:00 GMT 2004

My impression is that setuid is really intended to effect the whole
process, not just a thread, though Linuxthreads happens to implement
it the other way. Thus, if I understand this correctly, this is likely
to break with another threads implementation (NPTL?) for other reasons.
You are relying on a violation of the applicable standards.
That aside, the garbage collector may currently run in any thread that
allocates from the Java heap. Hence any thread may send signals.
Also Linuxthreads makes heavy use of signals internally for various
puposes.
Hans
On 2004年12月11日, Chris Gray wrote:
> On Saturday 11 December 2004 16:35, Jost Boekemeier wrote:
> > by calling setuid(#uid_nobody).
> >
> > The reason seems to be that when the user code is
> > finished, the thread tries to send a signal to another
> > system thread, but doesn't have the permission
> > anymore. gcj then aborts saying that pthread_kill
> > failed.
> >
> > I haven't looked at the code [...]
>> Nor have I, but in general a thread which has terminated needs to ask some
> other thread to release its resources - maybe a "reaper thread" dedicated to
> this task, or a "thread group manager thread" or whatever. Reason being that
> the statement
> free(this thread's stack)
> is not thread-safe. ;->
>> Chris
>>