Matthias Drochner <M.Drochner@fz-juelich.de> writes:

> I've tried to track down why many thread using applications
> get into a tight loop "if something goes wrong".
> The little test program appended shows the same symptoms.
> The handler is just not reached, the program gets into an
> endless loop catching SIGSEGVs.

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.

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.

> When I switch on pthread signal debugging, I get:
> 
> (up 0x48600000) switching to 0xbfbc0000 (uc: T 0xbfbff7d0 pc: 8048960)
> (recycle 0xbfbc0000) recycled 0x48600000
> (up 0x48600000) type 4 LWP 1 ev 1 intr 0
> (fi 0x48600000) victim 0 0xbfbc0000(1) nonlockholder
> (pt_signal 0x48600000) setting proc sigmask to 00000000
> (pthread__kill 0x48600000) target 0xbfbc0000 sig 11 code 6
> 
> repeated endlessly.

The signal is blocked in the target thread's mask the first
time the signal was delivered and pthread__kill() was called; the
interesting part of the debug log for this problem is unfortunately at
the very beginning of the program's execution and can quickly be
overwritten in the debug log's circular buffer.

> Looking where the "target" comes from I got discouraged when I
> saw the kernel's psendsig() -- perhaps someone can explain
> me what that
> 		if (code)
> 			le = l;
> 		else
> 			li = l;
> does? (or better add comments...)

It selects whether the signal is reported to userland as a synchronous
(thread-generated) signal or as an async, process-targeted signal, by
choosing whether to pass the current LWP as the "event" involved in
the upcall, or as an "interrupted" bystander.

        - Nathan