From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7087 invoked by alias); 10 Mar 2015 10:52:51 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 34694 Received: (qmail 15345 invoked from network); 10 Mar 2015 10:52:32 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-Originating-IP: [86.6.153.127] X-Spam: 0 X-Authority: v=2.1 cv=RdIeCjdv c=1 sm=1 tr=0 a=39NrsSuza2clQiZR/7fYWQ==:117 a=39NrsSuza2clQiZR/7fYWQ==:17 a=kj9zAlcOel0A:10 a=NLZqzBF-AAAA:8 a=CjxXgO3LAAAA:8 a=ktA1vFboAAAA:8 a=aqGaq9NnidgRE80ZY4wA:9 a=CjuIK1q_8ugA:10 a=Nan5esuaV4MA:10 Date: Tue, 10 Mar 2015 10:46:53 +0000 From: Peter Stephenson To: John , "zsh-workers@zsh.org" Subject: Re: Bug: ZSH crashes upon receiving SIGINT Message-ID: <20150310104653.181bd618@ntlworld.com> In-Reply-To: <262321015.1750177.1425923203098.JavaMail.yahoo@mail.yahoo.com> References: <262321015.1750177.1425923203098.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 9 Mar 2015 17:46:43 +0000 (UTC) John 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.'=20 > Bug: ZSH is not capable of defending itself against SIGINT and > crashes from within a chroot. =46rom 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 >=20 > # > <> > # 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