signal bug (long)

[utzoo!decvax!ucbvax!unix-wizards]

>From MBM at 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
-------