Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!schaefer
From: schaefer@ogicse.ogi.edu (Barton E. Schaefer)
Newsgroups: comp.mail.mush
Subject: Re: Another 'longjmp botch'...
Message-ID: <7887@ogicse.ogi.edu>
Date: 10 Mar 90 21:30:37 GMT
References: <255@elrond.locus.com>
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR
Lines: 53

In article <255@elrond.locus.com> ghb@elrond.locus.com (George Bray) writes:
} Well, I've found another one.  (This is after installing the quickie
} patch you sent).  In fact, this may even be the same race condition,
} but it has a very different stack trace, so I'm bugging the world
} about it again.  As a reminder, this is 7.0.4 (plus change to mail.c)
} running under 4.3Tahoe on a Vax.

It's not the same race condition.

} This time I got a longjmp botch repeatably while reading a
} particular mail message.  It turned out that the mail message had an
} escape sequence in it. [....]
} The failure only occurred on my Wyse 60 terminal.  The ESC 4 sequence
} is 'send unprotected cursor line' which I assume means send the entire
} line containing the cursor as input.  

You should definitely disable this "feature" of your terminal as soon
as possible.  This is a truly classic security hole; what if the line
containing the ESC-4 had contained somewhere the string "!rm -f *" ...

} When I displayed the message containing this (using the internal
} pager), it would eventually die with a longjmp botch.  [...]
} I said above that it would "eventually" die because sometimes the
} message would be repeatedly displayed.  [...]
} It was fairly entertaining watching mush bang itself over the head
} with this message until it finally croaked.

Mush was not banging *itself* over the head, your *terminal* was banging
it over the head.  Send enough random keyboard signals at any interactive
program and it will very likely get confused.

Nevertheless, it is true that mush's current setjmp/longjmp usage is
a little fragile, and there are some "windows" where a signal could
cause the wrong jumpbuf to be used.  Those "windows" are generally
about as wide as the time required to make one function call (i.e., the
critical section where signals are blocked ends, and then a function
is called which immediately does a setjmp()).

} Any ideas?  Is this the same race, made worse by machine-speed input?

Most likely, you managed to interrupt mush in one of the "windows" noted
above, or in the middle of a setjmp(), causing it to longjmp() to either
an out-of-date jumpbuf or one that was only partially filled in.  I've
done all I can without totally revamping the signal mechanism to keep
those holes as small as possible, so the situation is not likely to get
better in the immediate future.  An overhaul of the signal stuff *is*
being designed, but I can't guess when anyone will have time to implement
such a thing.
-- 
Bart Schaefer          "EARTH: Surrender IMMEDIATELY or we PICKLE DAN QUAYLE"

                                                                    "THPPFT!"
schaefer@cse.ogi.edu (used to be cse.ogc.edu)