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 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.