Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!cs.utexas.edu!yale!mintaka!bloom-beacon!bloom-beacon!athena.mit.edu!scs
From: scs@adam.mit.edu (Steve Summit)
Newsgroups: comp.bugs.4bsd
Subject: /bin/sh "longjmp botch" upon logout
Message-ID: <1990Aug3.230130.7347@athena.mit.edu>
Date: 3 Aug 90 23:01:30 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: scs@adam.mit.edu (Steve Summit)
Distribution: usa
Organization: Thermal Technologies, Inc.
Lines: 38

Under some versions of the Bourne shell, the traditional logout
script, requested with

	trap '. $HOME/.eliforp; exit' 0

instead causes the shell to generate a longjmp botch, and leave
an annoying core file in whatever had been the current directory,
upon logout.  The logout script .eliforp does not execute.  I
have seen this bug come and go on various systems I've used;
strings on the one I'm using now reveals that main.c is version
4.3 from 3/19/85 and word.c is version 4.6 from 10/31/85.  (The
rest of the SCCS ID's are older, most from 1983.)

The bug is reminiscent of one I once tracked down in adb on a
Sequent Balance 8000.  The BSD-derived adb used an undocumented
and hitherto-unknown-to-me setjmp/longjmp variant (names long
since forgotten) which did the usual establish-context-at-top-
level upon startup and revert-to-it after an error.  (Why these
routines existed at all, when they appeared to be a special case
of setjmp/longjmp, is beyond me.)  The problem was that someone
at Sequent had almost-cleverly implemented this pair in terms of
setjmp and longjmp; I unwittingly pulled these "Berkeley
compatibility" routines out of Sequent's libc.a when compiling
adb.  Attractive though it may have seemed, setjmp is not a
building block out of which you can build something like setjmp.
A context-saving routine which calls setjmp to save the context
and then returns has just invalidated that context.

I mention this because something like it may be going on inside sh.

I would track this down myself except that I do not have source
access at the moment.  Has anyone else seen it or tracked it
down?  (There must be one or two sh users left in the country.)
Is it fixed in the current BSD release, indicating that I've
simply been saddled with an obsolete copy?

                                            Steve Summit
                                            scs@adam.mit.edu