signal handling bug demo....

[D.J. Barrow]

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.





_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: child.c
Type: application/octet-stream
Size: 284 bytes
Desc: child.c
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/19990225/a66b6e4d/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parent.c
Type: application/octet-stream
Size: 634 bytes
Desc: parent.c
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/19990225/a66b6e4d/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testmake
Type: application/octet-stream
Size: 107 bytes
Desc: testmake
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/19990225/a66b6e4d/attachment-0002.obj>