Subject: Re: signal handling oddity with pthreads
To: Nathan J. Williams <>
From: Matthias Drochner <>
List: current-users
Date: 08/22/2003 22:17:19 said:
> 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?

best regards