* Bug: ZSH crashes upon receiving SIGINT @ 2015-03-09 17:46 John 2015-03-10 10:46 ` Peter Stephenson 0 siblings, 1 reply; 17+ messages in thread From: John @ 2015-03-09 17:46 UTC (permalink / raw) To: zsh-workers 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. No other shell tested ( mksh, bash, dash, fish, and tcsh) seems to suffer from this deficiency. In a recent bug report[2], the Arch devs believe this bug to be contained within ZSH, not within their code. 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 Example of the bug: # 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 Thank you for the time and I am glad to provide additional info or testing. PLEASE CC ME ON ANY REPLY AS I AM NOT SUBSCRIBED TO THIS ML. 1. https://www.archlinux.org 2. https://bugs.archlinux.org/task/44073 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bug: ZSH crashes upon receiving SIGINT 2015-03-09 17:46 Bug: ZSH crashes upon receiving SIGINT John @ 2015-03-10 10:46 ` Peter Stephenson 2015-03-10 11:16 ` Peter Stephenson 2015-03-10 22:06 ` John 0 siblings, 2 replies; 17+ messages in thread From: Peter Stephenson @ 2015-03-10 10:46 UTC (permalink / raw) To: John, zsh-workers On Mon, 9 Mar 2015 17:46:43 +0000 (UTC) John <da_audiophile@yahoo.com> 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bug: ZSH crashes upon receiving SIGINT 2015-03-10 10:46 ` Peter Stephenson @ 2015-03-10 11:16 ` Peter Stephenson 2015-03-10 22:06 ` John 1 sibling, 0 replies; 17+ messages in thread From: Peter Stephenson @ 2015-03-10 11:16 UTC (permalink / raw) To: John, zsh-workers On Tue, 10 Mar 2015 10:46:53 +0000 Peter Stephenson <p.w.stephenson@ntlworld.com> wrote: > 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. Minor update here: on looking a little more closely, I see the shell will only exit on the second occurrence of EIO when reading from the TTY. On the first it will attempt to fix things up by forcing itself to be the TTY foreground process. It's possible this is part of the puzzle. pws ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bug: ZSH crashes upon receiving SIGINT 2015-03-10 10:46 ` Peter Stephenson 2015-03-10 11:16 ` Peter Stephenson @ 2015-03-10 22:06 ` John 2015-03-11 0:43 ` Bart Schaefer 1 sibling, 1 reply; 17+ messages in thread From: John @ 2015-03-10 22:06 UTC (permalink / raw) To: Peter Stephenson, zsh-workers ----- Original Message ----- > > 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... > Firstly, thank you for your thoughtful reply. Yes, I didn't think I would be fortunate enough to have one of you guys running Arch Linux. If you have a spare partition free, you can just boot from the live CD (www.archlinux.org) and execute a few commands to have an Arch partition only for the purpose of seeing this bug/troubleshooting. If this is acceptable to you, I am glad to distill down exactly what you would type to do this. Please let me know. >> # 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. Yes, that is correct. Upon running the first line (arch-chroot ...) the chroot binary is called and the next prompt is INSIDE the partition target (/mnt/mini in my example). You can run commands inside the chroot just fine, but it breaks if you hit ctrl+c as I have denoted with the <<hit ctrl-c>> which probably wasn't very obvious without this explanation. > 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 umount and subsequent lines are all thrown when you hit 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. I agree with you. Most of the arch-chroot script is over my head. I have linked it here if the code within is meaningful and if you have the time to read through it. It is only 309 lines: http://pastebin.com/yDyuqxqi <snip> I'm afraid the comments from Dave in the Arch Linux bug report (https://bugs.archlinux.org/task/44073) are all I have to go on as to root cause. I am happy to try to troubleshoot if you do not want to try to make a simple Arch partition on your system and try yourself from the live CD. Please let me know and thanks again. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bug: ZSH crashes upon receiving SIGINT 2015-03-10 22:06 ` John @ 2015-03-11 0:43 ` Bart Schaefer 2015-03-11 9:44 ` Peter Stephenson ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Bart Schaefer @ 2015-03-11 0:43 UTC (permalink / raw) To: zsh-workers, John On Mar 10, 10:06pm, John wrote: } } > we need to know what's going on here. } } I agree with you. Most of the arch-chroot script is over my } head. I have linked it here if the code within is meaningful and } if you have the time to read through it. It is only 309 lines: } http://pastebin.com/yDyuqxqi I took at look at this script. The "unmount" is coming from the exit trap of the bash process that starts the whole thing off. So I *think* what's happening is: Bash starts "unshare" which becomes the TTY process group leader. Unshare starts zsh which does not make itself the process group leader (see previous -workers list discussions of zsh executing inside PID namespaces, of which "unshare" creates one). The ^C therefore is delivered to "unshare" which exits, ending the bash script and executing the trap, which removes the tty device. This causes zsh to get I/O error and exit. It's *possible* that this is already "fixed" in development versions of zsh, though most of the PID namespace changes had to do with avoiding being process group leader rather than forcibily becoming so. It's also not clear that this is actually zsh's problem; it seems to me that the arch-chroot script and/or "unshare" are not doing things they should be. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bug: ZSH crashes upon receiving SIGINT 2015-03-11 0:43 ` Bart Schaefer @ 2015-03-11 9:44 ` Peter Stephenson 2015-03-11 19:55 ` Peter Stephenson 2015-03-11 18:38 ` John 2015-03-13 6:44 ` Han Pingtian 2 siblings, 1 reply; 17+ messages in thread From: Peter Stephenson @ 2015-03-11 9:44 UTC (permalink / raw) To: Bart Schaefer, zsh-workers; +Cc: John On Tue, 10 Mar 2015 17:43:27 -0700 Bart Schaefer <schaefer@brasslantern.com> wrote: > So I *think* what's happening is: > > Bash starts "unshare" which becomes the TTY process group leader. > > Unshare starts zsh which does not make itself the process group leader > (see previous -workers list discussions of zsh executing inside PID > namespaces, of which "unshare" creates one). > > The ^C therefore is delivered to "unshare" which exits, ending the > bash script and executing the trap, which removes the tty device. > > This causes zsh to get I/O error and exit. > > It's *possible* that this is already "fixed" in development versions > of zsh, though most of the PID namespace changes had to do with avoiding > being process group leader rather than forcibily becoming so. It's also > not clear that this is actually zsh's problem; it seems to me that the > arch-chroot script and/or "unshare" are not doing things they should be. The PID namespace issue I remember is from the docker thread, zsh-workers/34503. http://www.zsh.org/mla/workers/2015/msg00427.html I only remember the problem with unreaped children in that case, but I'll refresh my mind when I get home. pws ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bug: ZSH crashes upon receiving SIGINT 2015-03-11 9:44 ` Peter Stephenson @ 2015-03-11 19:55 ` Peter Stephenson 0 siblings, 0 replies; 17+ messages in thread From: Peter Stephenson @ 2015-03-11 19:55 UTC (permalink / raw) To: Peter Stephenson, zsh-workers; +Cc: John On Wed, 11 Mar 2015 09:44:47 +0000 Peter Stephenson <p.stephenson@samsung.com> wrote: > On Tue, 10 Mar 2015 17:43:27 -0700 > Bart Schaefer <schaefer@brasslantern.com> wrote: > > So I *think* what's happening is: > > > > Bash starts "unshare" which becomes the TTY process group leader. > > > > Unshare starts zsh which does not make itself the process group leader > > (see previous -workers list discussions of zsh executing inside PID > > namespaces, of which "unshare" creates one). > > > > The ^C therefore is delivered to "unshare" which exits, ending the > > bash script and executing the trap, which removes the tty device. > > > > This causes zsh to get I/O error and exit. > > > > It's *possible* that this is already "fixed" in development versions > > of zsh, though most of the PID namespace changes had to do with avoiding > > being process group leader rather than forcibily becoming so. It's also > > not clear that this is actually zsh's problem; it seems to me that the > > arch-chroot script and/or "unshare" are not doing things they should be. > > The PID namespace issue I remember is from the docker thread, > zsh-workers/34503. I'm wrong, it's the discussion around 33992: http://www.zsh.org/mla/workers/2014/msg01779.html This does sound much more similar. -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bug: ZSH crashes upon receiving SIGINT 2015-03-11 0:43 ` Bart Schaefer 2015-03-11 9:44 ` Peter Stephenson @ 2015-03-11 18:38 ` John 2015-03-11 20:09 ` Peter Stephenson 2015-03-13 6:44 ` Han Pingtian 2 siblings, 1 reply; 17+ messages in thread From: John @ 2015-03-11 18:38 UTC (permalink / raw) To: Bart Schaefer, zsh-workers > I took at look at this script. The "unmount" is coming from the > exit trap of the bash process that starts the whole thing off. > > So I *think* what's happening is: > > Bash starts "unshare" which becomes the TTY process group leader. > > Unshare starts zsh which does not make itself the process group leader > (see previous -workers list discussions of zsh executing inside PID > namespaces, of which "unshare" creates one). > > The ^C therefore is delivered to "unshare" which exits, ending the > bash script and executing the trap, which removes the tty device. > > This causes zsh to get I/O error and exit. > > It's *possible* that this is already "fixed" in development > versions > of zsh, though most of the PID namespace changes had to do with avoiding > being process group leader rather than forcibily becoming so. It's also > not clear that this is actually zsh's problem; it seems to me that the > arch-chroot script and/or "unshare" are not doing things they should > be. Thank you for the reply. Not too sure that I can add anything intelligent to the discussion, but I can confirm that the latest zsh from git (5.0.7.336.ge85906e) does not fix this issue. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bug: ZSH crashes upon receiving SIGINT 2015-03-11 18:38 ` John @ 2015-03-11 20:09 ` Peter Stephenson 2015-03-11 23:23 ` John 0 siblings, 1 reply; 17+ messages in thread From: Peter Stephenson @ 2015-03-11 20:09 UTC (permalink / raw) To: John, zsh-workers As an easy check of the shell setup, could you run zmodload zsh/parameter print $options[MONITOR] in the problem case to see if job control has initialised properly? pws ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bug: ZSH crashes upon receiving SIGINT 2015-03-11 20:09 ` Peter Stephenson @ 2015-03-11 23:23 ` John 2015-03-11 23:31 ` Bart Schaefer 0 siblings, 1 reply; 17+ messages in thread From: John @ 2015-03-11 23:23 UTC (permalink / raw) To: Peter Stephenson, zsh-workers It seems OK. % zmodload zsh/parameter print $options[MONITOR] on % sudo arch-chroot /mnt/mini /bin/zsh# << this is in the chroot >> # << here I now hit ctrl+c and the bug happens >> # 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).) > As an easy check of the shell setup, could you run > > zmodload zsh/parameter > print $options[MONITOR] > > in the problem case to see if job control has initialised properly? > > pws > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bug: ZSH crashes upon receiving SIGINT 2015-03-11 23:23 ` John @ 2015-03-11 23:31 ` Bart Schaefer 2015-03-11 23:47 ` John 0 siblings, 1 reply; 17+ messages in thread From: Bart Schaefer @ 2015-03-11 23:31 UTC (permalink / raw) To: John; +Cc: Peter Stephenson, Zsh hackers list [-- Attachment #1: Type: text/plain, Size: 323 bytes --] On Mar 11, 2015 4:30 PM, "John" <da_audiophile@yahoo.com> wrote: > > It seems OK. > > % zmodload zsh/parameter > > print $options[MONITOR] > on > > > % sudo arch-chroot /mnt/mini /bin/zsh# << this is in the chroot >> Actually Peter wants you to run the zmodload and print from here inside the chroot, not from outside it. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bug: ZSH crashes upon receiving SIGINT 2015-03-11 23:31 ` Bart Schaefer @ 2015-03-11 23:47 ` John 2015-03-12 5:11 ` Andrew Janke 2015-03-12 19:58 ` Peter Stephenson 0 siblings, 2 replies; 17+ messages in thread From: John @ 2015-03-11 23:47 UTC (permalink / raw) To: Bart Schaefer; +Cc: Peter Stephenson, Zsh hackers list >Actually Peter wants you to run the zmodload and print from here inside the chroot, not from outside it. <<Headsmack>> Running it from within the chroot gives the opposite output. I googled for how I can toggle this parameter but didn't find a good answer. Please advise. # zmodload zsh/parameter # print $options[MONITOR] off ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bug: ZSH crashes upon receiving SIGINT 2015-03-11 23:47 ` John @ 2015-03-12 5:11 ` Andrew Janke 2015-03-12 19:06 ` John 2015-03-12 19:58 ` Peter Stephenson 1 sibling, 1 reply; 17+ messages in thread From: Andrew Janke @ 2015-03-12 5:11 UTC (permalink / raw) To: John, Bart Schaefer; +Cc: Peter Stephenson, Zsh hackers list Hi folks, I was able to set up an Arch Linux instance that can consistently reproduce this issue. It's on a public-facing server, so if having access to work with this directly would help you debug it, send me a direct email with a desired username and public SSH key and I'll set you up with an account. To set up a server to reproduce the issue: Start with a fresh Arch Linux installation, and then: pacman -Syy pacman -S zsh arch-install-scripts mkdir -p /chroots/mini pacstrap -d -i /chroots/mini base zsh Then to make the breakage happen: arch-chroot /chroots/mini /bin/zsh Wait for the prompt and hit Ctrl-C. It'll immediately produce those umount and input error messages. After you get errors from this, your mount table will be in an unclean state and subsequent arch-chroot calls will fail. To clean up manually so you can arch-chroot again: umount /chroots/mini/dev/pts umount /chroots/mini/dev Cheers, Andrew On 3/11/15 7:47 PM, John wrote: >> Actually Peter wants you to run the zmodload and print from here inside the chroot, not from outside it. > > <<Headsmack>> > > Running it from within the chroot gives the opposite output. I googled for how I can toggle this parameter but didn't find a good answer. Please advise. > > # zmodload zsh/parameter > # print $options[MONITOR] > off ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bug: ZSH crashes upon receiving SIGINT 2015-03-12 5:11 ` Andrew Janke @ 2015-03-12 19:06 ` John 0 siblings, 0 replies; 17+ messages in thread From: John @ 2015-03-12 19:06 UTC (permalink / raw) To: Andrew Janke, Bart Schaefer; +Cc: Peter Stephenson, Zsh hackers list > I was able to set up an Arch Linux instance that can consistently > reproduce this issue. It's on a public-facing server, so if having > access to work with this directly would help you debug it, send me a > direct email with a desired username and public SSH key and I'll set you > up with an account. <SNIP> Thanks for setting this up, Andrew. I think it will be a great tool for some folks more knowledgeable then I to use to see this and diagnose the problem. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bug: ZSH crashes upon receiving SIGINT 2015-03-11 23:47 ` John 2015-03-12 5:11 ` Andrew Janke @ 2015-03-12 19:58 ` Peter Stephenson 2015-03-13 4:00 ` Bart Schaefer 1 sibling, 1 reply; 17+ messages in thread From: Peter Stephenson @ 2015-03-12 19:58 UTC (permalink / raw) To: John, Zsh hackers list On Wed, 11 Mar 2015 23:47:07 +0000 (UTC) John <da_audiophile@yahoo.com> wrote: > # zmodload zsh/parameter > # print $options[MONITOR] > off OK, that means job control isn't enabled. Most likely it wasn't enabled from the start because the shell found something about the environment that didn't work. That points towards Bart's explanation --- if job control isn't enabled, zsh won't pick up the ^C by itself, it'll go to whatever process group zsh was started in. The final check for whether it can be enabled is in the init_io() function and then acquire_pgrp(). It looks like the line editor is working, otherwise it wouldn't be exiting at the point it is, so that probably means SHTTY (a rather odd choice of variable for the file descriptor used by the line editor and job control) is sane. We might be able to confirm with some instrumentation as below... Note this will be quite verbose if job control does get enabled and lots of processes get run as it outputs a message when the foreground process changes. Bart may well have more idea what might be going wrong and have more idea what to instrument, however. pws diff --git a/Src/init.c b/Src/init.c index 3e41fb9..d49a176 100644 --- a/Src/init.c +++ b/Src/init.c @@ -591,15 +591,21 @@ init_io(void) zsfree(ttystrname); ttystrname = ztrdup(""); } else { + fprintf(stderr, "SHTTY is open\n"); #ifdef FD_CLOEXEC long fdflags = fcntl(SHTTY, F_GETFD, 0); if (fdflags != (long)-1) { fdflags |= FD_CLOEXEC; fcntl(SHTTY, F_SETFD, fdflags); + fprintf(stderr, "Attempted to set FD_CLOEXEC on SHTTY\n"); } #endif - if (!ttystrname) + if (!ttystrname) { ttystrname = ztrdup("/dev/tty"); + fprintf(stderr, "Couldn't get TTY name\n"); + } else { + fprintf(stderr, "TTY name is %s\n", ttystrname); + } } /* We will only use zle if shell is interactive, * @@ -619,11 +625,15 @@ init_io(void) if (opts[MONITOR] && (SHTTY != -1)) { origpgrp = GETPGRP(); acquire_pgrp(); /* might also clear opts[MONITOR] */ - } else + } else { + if (opts[MONITOR]) + fprintf(stderr, "No terminal for job control\n"); opts[MONITOR] = 0; + } #else opts[MONITOR] = 0; #endif + fflush(stderr); } /**/ diff --git a/Src/jobs.c b/Src/jobs.c index 295f4c9..6c0a4f7 100644 --- a/Src/jobs.c +++ b/Src/jobs.c @@ -2741,8 +2741,10 @@ acquire_pgrp(void) sigaddset(&blockset, SIGTTOU); sigaddset(&blockset, SIGTSTP); oldset = signal_block(blockset); + fprintf(stderr, "Starting with mypgrp = %d\n", mypgrp); while ((ttpgrp = gettygrp()) != -1 && ttpgrp != mypgrp) { mypgrp = GETPGRP(); + fprintf(stderr, "mypgrp -> %d\n", mypgrp); if (mypgrp == mypid) { if (!interact) break; /* attachtty() will be a no-op, give up */ @@ -2764,12 +2766,17 @@ acquire_pgrp(void) if (setpgrp(0, 0) == 0) { mypgrp = mypid; attachtty(mypgrp); - } else + } else { opts[MONITOR] = 0; + fprintf(stderr, "setpgrp failed, abandoning job control\n"); + } } signal_setmask(oldset); - } else + } else { + fprintf(stderr, "mypgrp = %d, abandoning job control\n", + mypgrp); opts[MONITOR] = 0; + } } /* revert back to the process group we came from (before acquire_pgrp) */ diff --git a/Src/utils.c b/Src/utils.c index 3d12807..83e5459 100644 --- a/Src/utils.c +++ b/Src/utils.c @@ -4148,6 +4148,7 @@ attachtty(pid_t pgrp) static int ep = 0; if (jobbing && interact) { + fprintf(stderr, "Attaching TTY %d to %d\n", SHTTY, pgrp); #ifdef HAVE_TCSETPGRP if (SHTTY != -1 && tcsetpgrp(SHTTY, pgrp) == -1 && !ep) #else @@ -4160,13 +4161,16 @@ attachtty(pid_t pgrp) # endif #endif { - if (pgrp != mypgrp && kill(-pgrp, 0) == -1) + if (pgrp != mypgrp && kill(-pgrp, 0) == -1) { + fprintf(stderr, "Bad process group, attaching to mypgrp\n"); attachtty(mypgrp); - else { + } else { if (errno != ENOTTY) { zwarn("can't set tty pgrp: %e", errno); fflush(stderr); + } else { + fprintf(stderr, "Received ENOTTY, no job control\n"); } opts[MONITOR] = 0; ep = 1; ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bug: ZSH crashes upon receiving SIGINT 2015-03-12 19:58 ` Peter Stephenson @ 2015-03-13 4:00 ` Bart Schaefer 0 siblings, 0 replies; 17+ messages in thread From: Bart Schaefer @ 2015-03-13 4:00 UTC (permalink / raw) To: John, Zsh hackers list On Mar 12, 7:58pm, Peter Stephenson wrote: } Subject: Re: Bug: ZSH crashes upon receiving SIGINT } } Bart may well have more idea what might be going wrong and have more } idea what to instrument, however. No, your instrumentation there looks pretty comprehensive to me. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Bug: ZSH crashes upon receiving SIGINT 2015-03-11 0:43 ` Bart Schaefer 2015-03-11 9:44 ` Peter Stephenson 2015-03-11 18:38 ` John @ 2015-03-13 6:44 ` Han Pingtian 2 siblings, 0 replies; 17+ messages in thread From: Han Pingtian @ 2015-03-13 6:44 UTC (permalink / raw) To: zsh-workers On Tue, Mar 10, 2015 at 05:43:27PM -0700, Bart Schaefer wrote: > > It's *possible* that this is already "fixed" in development versions > of zsh, I tested according to what Dave suggested in the bug report, and looks like it has ben fixed in development version: % sudo unshare --fork --pid =zsh [root@localhost]/tmp# print $ZSH_VERSION 5.0.7-dev-1 [root@localhost]/tmp# print $ZSH_PATCHLEVEL zsh-5.0.7-336-ge85906e [root@localhost]/tmp# <^C here> [root@localhost]/tmp# <^C here> [root@localhost]/tmp# <^C here> [root@localhost]/tmp# <^C here> [root@localhost]/tmp# <^C here> [root@localhost]/tmp# <^D here> % % sudo unshare --fork --pid /usr/bin/zsh [root@localhost]/tmp# print $ZSH_VERSION 5.0.7 [root@localhost]/tmp# <^C here> [root@localhost]/tmp# % % [root@localhost]/tmp# zsh: error on TTY read: Input/output error % ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2015-03-13 6:56 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-03-09 17:46 Bug: ZSH crashes upon receiving SIGINT John 2015-03-10 10:46 ` Peter Stephenson 2015-03-10 11:16 ` Peter Stephenson 2015-03-10 22:06 ` John 2015-03-11 0:43 ` Bart Schaefer 2015-03-11 9:44 ` Peter Stephenson 2015-03-11 19:55 ` Peter Stephenson 2015-03-11 18:38 ` John 2015-03-11 20:09 ` Peter Stephenson 2015-03-11 23:23 ` John 2015-03-11 23:31 ` Bart Schaefer 2015-03-11 23:47 ` John 2015-03-12 5:11 ` Andrew Janke 2015-03-12 19:06 ` John 2015-03-12 19:58 ` Peter Stephenson 2015-03-13 4:00 ` Bart Schaefer 2015-03-13 6:44 ` Han Pingtian
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).