Path: utzoo!attcan!uunet!mcsun!hp4nl!phigate!ehviea!leo From: leo@ehviea.ine.philips.nl (Leo de Wit) Newsgroups: comp.unix.wizards Subject: Re: Phantom CPU gobbler?! Message-ID: <833@ehviea.ine.philips.nl> Date: 18 Jul 90 15:56:07 GMT References: <960004@teecs.UUCP> <1277@tuewsd.win.tue.nl> Reply-To: leo@ehviea.UUCP (Leo de Wit) Organization: Philips I&E Eindhoven Lines: 46 In article <1277@tuewsd.win.tue.nl> wsinpdb@lso.win.tue.nl (Paul de Bra) writes: |In article <960004@teecs.UUCP> belkin@teecs.UUCP (Hershel Belkin) writes: |>... |>Every so often I fins a shell process (sh or ksh) which has somehow |>become dis-associated with its logon session. By this I mean that |>the shell's PPID is "1", and the user is no longer logged on. |>... | |This is the infamous trap/signal/eof bug, which I don't know exactly, |but some combination of trapping and sending signals and having |end-of-file on standard input causes an infinite loop in the Bourne |and Korn shell, at least in some Unix versions which haven't fixed the bug. | |Anyone know the full scoop? | |Paul. Not the full scoop I'm afraid, but every bit may help ... Some years ago I had a comparable problem with a trap 0 command in the Bourne shell (this was Ultrix 1.0 if I remember correctly). The trap went something like: trap "rm -f tmpfile;exit" 0 and the error message when the shell exited (don't remember whether it really went away): longjmp botch (on this Pyramid this string is also in the binary /bin/sh). From the context it seems as if the signal handling was implemented with setjmp/longjmp pairs, and that after the first longjmp (the one caused by the end-of-file-on-stdin condition) the jmpbuf had become invalid (marked as such by the shell?) which was detected when the exit inside the trap string was performed (which probably triggered the trap again). All guesswork, I'm afraid. I was not able to reproduce this error on this machine, but some experimenting shows that inside a trap that same trap is disabled, much the same way that a signal is blocked while being handled (BSD). This would explain why I can't reproduce it here. Leo.