trap causes longjmp botch (Was: Command line argument in Cshell script

Leo de Wit leo at philmds.UUCP
Sun Jun 12 20:26:51 AEST 1988


In article <11820 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
 [stuff deleted]
>Here is how I might write it:
>
>	case $# in
>	0)	echo "usage: $0 file [arguments to plot3d]" 1>&2; exit 1;;
>	esac
>
>	TEMP=/tmp/z$$			# make a unique temporary file name
>	/bin/rm -f $TEMP		# remove it if it exists
>	trap '/bin/rm -f $TEMP; exit' 0 1 2 3 15 # and again at exit or signal

    Used to write it myself that way too ... until one day the sh (/bin/sh;
the Bourne shell on an Ultrix machine) complained about a 'longjmp botch'; 
I don't remember if there was a core dump.
    What is the problem with this trap? The normal signals, as 1 2 3 and 15 are
handled with interrupt routines in the shell, using signal() or sigvec() or
whatever. The 0 signal isn't really a signal, just used by the shell to
perform certain actions at closing time (putting chairs on tables, removing
any drunks left 8-). It could well have been implemented using setjmp and
longjmp (I dunno, don't have the source); that could explain the 'longjmp
botch'. The last command in the trap is 'exit'. But when the shell exits,
it has to perform the trap! So another reason for the 'longjmp botch' message
could be the shell trying to recursively trap and exit, each calling the
other and finally finding out it's running out of stack space.
    Perhaps it is safer to add another trap:
    trap '/bin/rm -f $TEMP; trap 0; exit' 0 1 2 3 15
In this case the 'exit'-trap is reset when the trap is executed.

    Leo.



More information about the Comp.unix.questions mailing list