Rare mishandling of interrupt signal

[Loren James Rittle <rittle@comm.mot.com>]

While testing es interrupt handling under SYS V machines, I found a
reproducible method to crash es-0.9-alpha1 on all platforms I have
access to when they are linked against either plain readline-2.0 or
the readline from the latest bash.

Has anyone else ever noticed this?

; while {sleep 1} {sleep 1}
[enter tty interrupt char]
; [enter tty interrupt char at prompt]
<es dies>

Or as run under the debugger:

; gdb es
(gdb) handle SIGINT noprint pass nostop
(gdb) run
; while {sleep 1} {sleep 1}
[enter tty interrupt char]
; [enter tty interrupt char at prompt]
Program exited normally.
(gdb)

After the while loop is broken with the tty interrupt char, the shell
seems to act properly until a tty interrupt char is entered while at
the shell prompt.  E.g. as long as the tty interrupt char is entered
while a program is running under the shell, the es shell properly
kills interactive programs started under it and returns to the prompt.

Here be dragons!  I wish I knew UNIX signal handling well enough to
even think about looking into this problem. :-)

FYI, es-0.84 (sunos 4.1.4, gcc 2.x, readline-2.0) appears to have this
problem as well.

Regards,
Loren