Phantom CPU gobbler?!

[Leo de Wit]

In article <1277 at tuewsd.win.tue.nl> wsinpdb at lso.win.tue.nl (Paul de Bra) writes:
|In article <960004 at teecs.UUCP> belkin at 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.