Re: Bug: ZSH crashes upon receiving SIGINT

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Mon, 9 Mar 2015 17:46:43 +0000 (UTC)
John <da_audiophile@xxxxxxxxx> wrote:
> Background:  Arch Linux[1] has a bash script used for installing the
> distro and or fixing a broken distro which is shipped with the live CD
> called 'arch-chroot.' 
> Bug:  ZSH is not capable of defending itself against SIGINT and
> crashes from within a chroot.

From the report below it's obviously something more specific than this
that's happening.

> How to trigger the bug:
> 1) Mount an Arch partition and install 'zsh' within it
> 2) Execute the chroot command from another Arch env: arch-chroot
> /mnt/mini /bin/zsh
> 3) Hit ctrl+c in the chroot

I'm afraid the fact this description appears to be specific to that
distro and it looks like a lot of setting up of the chroot partition is
presupposed, so it's unlikely anyone on this list who can actually help
debug this is going to be able to reproduce it in this form.
Nonetheless, it does look like we have enough information at least to
start making suggestions, so if you're able to do a bit of further
prodding it's not hopeless...

> # arch-chroot /mnt/mini /bin/zsh
> 
> #
> <<hit ctrl-c>>
> # umount: /mnt/mini/dev/pts: target is busy
> (In some cases useful info about processes that
> use the device is found by lsof(8) or fuser(1).)
> umount: /mnt/mini/dev: target is busy
> (In some cases useful info about processes that
> use the device is found by lsof(8) or fuser(1).)
> %
> zsh: error on TTY read: Input/output error

Is that ^C happening at the command line, i.e. when no other
programme than the shell is running?  That's how I read the above, but
it would be good to be explicit.

In that case, what does the umount stuff mean?  That's certainly got
nothing to do with the shell's internal response to a Ctrl-C.

The error at the end comes from a specific point in the shell line
editor: if it finds it can't read from the TTY, and the error isn't one
of the small number it thinks are recoverable, it will exit.  In this
case the error appears to be EIO.  So this certainly ties in with the
behaviour you're seeing.

The question is where this error is coming from and it looks pretty
likely it's somehow associated with that "umount /mnt/mini/dev/pts" as
that looks like an attempt to remove the devices providing the ttys (I'm
guessing as is this is system stuff I don't know about).  The unmount
may have failed but may also have left the tty in a bad state.  I think
we need to know what's going on here.

To get anywhere within the shell, we need to know a little bit more
about the nature of the error and what we can do about it.  Clearly if
the terminal *has* become unusable, there's nothing we can do.  If it's
not happening with other shells, do you still see the errors to do with
"umount"?   If not, I'm afraid I'm stuck --- I just don't see any way
the shell can create system administration commands out of thin air.  If
they do, do you see any evidence of errors owing to bad terminal state?
Is there some shell framework installed by user commands, for example a
trap, that might be related to the unmounts?

My guess would be EIO isn't actually recoverable, so retrying wouldn't
help, though it would be fairly easy to add some test code to see.
Here's a useful summary from http://aplawrence.com/Unixart/errors.html

  #define EIO 5 /* I/O error */

  The catchall for all manner of unexpected hardware errors. It could be
  from a physical error, but additionally, an orphaned process (a
  process whose parent has died) that attempts to read from standard
  input will get this. BSD systems return this if you try to open a pty
  device that is already in use. An attempt to read from a stream that
  is closed will return EIO, as will a disk read or write that is
  outside of the physical bounds of the device. An open of /dev/tty when
  the process has no controlling tty will spit back EIO also.

It's possible zsh is somehow exacerbating the situation by performing
some operation like reopening the terminal, although it could be
anything --- I haven't looked for this and it's pure theorising but
something like this might explain why other shells soldier on but zsh
has problems.  The effect of this in the case we appear to be seeing
would be very system specific.  We can add test code for this, too, but
at the moment I think that's premature --- the evidence above suggests
something outside the shell is making life difficult and we need to
track that down first.

pws