Aucbvax.5056
fa.unix-wizards
utzoo!decvax!ucbvax!unix-wizards
Tue Nov 10 00:23:56 1981
signal bug (long)
>From MBM@MIT-XX Mon Nov 9 23:48:01 1981
I believe I have found and fixed a race in the kernel signal handling.
The problem relates to the disposition of ignored tty interrupt signals
when a process is handling other signals as well. Processes dispose
of outstanding signals by doing "if (issig()) psig();" ... issig()
returns true if there are any signals to handle, filtering out the
ignored ones (i.e., those with signal-handler address of 1). psig()
then just goes through the signal mask and arranges for the user routine
to be called if non-zero. Unfortunately, if a tty interrupt came in
after you called issig() but before psig() finished, and you wanted to
ignore it, it will be sitting there in the signal mask with a function
address of 1 ... bus trap.
This problem has existed at least since version 6. It manifests itself
in the mysterious death of processes run in the background which do
interpreted floating point, among other things. To test for it,
try the following program:
main()
{
int loop();
for(;;)
{
signal(1,loop);
kill(getpid(),1);
}
}
loop()
{
}
Run it in the background and bang on the interrupt character on your
terminal. This will eventually bomb, leaving you a core dump with
the final pc at 3.
I have put an additional test into psig(); if the user function address
is 1, it just "continue;"'s the while loop of looking for signals in the
mask.
--mike
-------
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
of
http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.
