Subject: Re: signal handling oddity with pthreads
To: Nathan J. Williams <email@example.com>
From: Matthias Drochner <M.Drochner@fz-juelich.de>
Date: 08/22/2003 22:17:19
> Hi. I think I've fixed this with revision 1.17 of pthread_sig.c; it
> was fallout from the pt_trapuc changes a while ago.
Thanks - my test program works fine now.
It still needs a fix against the pagefault-within-upcall thing --
Christian Limpach's relatively finegrained patch works well for me, without
it I'm getting eg
sa_switch(10483.17 flag 900004): Not enough stacks.
itimerfire(10483): overrun 1 on timer 88880010 (userret is 0xc0268308)
with the patch, everything went fine so far.
> That said, I think that programs that catch SEGV are evil, because
> they don't leave useful core files, and they're riding on the ragged
> edge of permitted/defined behavior. If you're working with GNOME
> programs, I highly recommend setting the GNOME_DISABLE_CRASH_DIALOG
> environment variable.
In my case, it was the SDL library.
> The signal is blocked in the target thread's mask the first
> time the signal was delivered and pthread__kill() was called
Yes, obviously -- but where is that mask set?
> It selects whether the signal is reported to userland as a synchronous
> (thread-generated) signal or as an async, process-targeted signal
Hmm - the "code" is that lowlevel traphandling T_* thing which is defined
in sys/<arch>/include/trap/h usually? In there some mi meaning which I missed?