signal handling bug demo....

D.J. Barrow barrow_dj at
Thu Feb 25 22:39:53 EST 1999

Here is a demonstration of the bug I described in earlier mails about signals being lost by the kernel.
I am now quite sure the bug will manifest itself in all variants of linux unless the signal dispatching has changed radically. The code is I believe posix compilant ( Thanks Lauro ).

The bug arises when (sig)longjmp gets called out of a signal handler sys_sigreturn dosen't get called & the signals queued on the user stack get trashed.

To Demo:
put parent.c child.c & testmake in the same
directory. Compile using testmake  run parent.
Note "the bug" that only one signal gets delivered per loop of the child.

This bug I believe can be fixed by simplifing the kernel. There is no reason  (I'm aware of ) to queue the signals on the user stack sys_sigreturn gets called in the kernel for every signal delivered so this queueing is fundamentally a braindamaged idea.

The bug can be fixed I believe by
1) Removeing the while loop in do signal 
2) Removing the current sys_sigreturn
3) Making do_signal also function as sys_sigreturn.
4) Remove handle_signal.
5) Unblock the signal before delivering it ( this would enable longjmp out of signal handlers to behave correctly also ) rather than leaving the signal blocked forever.

So no do_signal will get called for each signal delivered. The thing would be a lot stabiler & use less userstack & remove -200 lines of really crap code.

Get your free address at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: child.c
Type: application/octet-stream
Size: 284 bytes
Desc: child.c
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parent.c
Type: application/octet-stream
Size: 634 bytes
Desc: parent.c
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testmake
Type: application/octet-stream
Size: 107 bytes
Desc: testmake
URL: <>

More information about the Linuxppc-dev mailing list