Ctrl-\ while executing a pipeline made zsh quit

Ctrl-\ while executing a pipeline made zsh quit

[Vincent Lefevre]

With zsh 5.8.1 under Linux (zsh 5.8.1-1 Debian/unstable package),
while I was executing a pipeline, I typed Ctrl-\ to interrupt it
(Ctrl-C had no effect), which made unexpectedly zsh quit: SIGQUIT
should interrupt the commands zsh starts, not the interactive shell
itself.

The backtrace:

Core was generated by `zsh'.
Program terminated with signal SIGQUIT, Quit.
#0  0x00007f6e9cd2dbe8 in __GI___sigsuspend (set=set@entry=0x7ffc0653d8e0)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:26
26      ../sysdeps/unix/sysv/linux/sigsuspend.c: No such file or directory.
(gdb) bt
#0  0x00007f6e9cd2dbe8 in __GI___sigsuspend (set=set@entry=0x7ffc0653d8e0)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:26
#1  0x000056392a430207 in signal_suspend (sig=sig@entry=17,
    wait_cmd=wait_cmd@entry=0) at ../../Src/signals.c:393
#2  0x000056392a3fae2f in zwaitjob (job=<optimized out>, wait_cmd=0)
    at ../../Src/jobs.c:1603
#3  0x000056392a3fb544 in waitjobs () at ../../Src/jobs.c:1673
#4  0x000056392a3dc64b in execpline (state=state@entry=0x7ffc0653de20,
    slcode=<optimized out>, how=<optimized out>, how@entry=18, last1=0)
    at ../../Src/exec.c:1759
#5  0x000056392a3dd4a7 in execlist (state=state@entry=0x7ffc0653de20,
    dont_change_job=dont_change_job@entry=0, exiting=exiting@entry=0)
    at ../../Src/exec.c:1419
#6  0x000056392a3dd9a2 in execode (p=p@entry=0x7f6e9d066580,
    dont_change_job=dont_change_job@entry=0, exiting=exiting@entry=0,
    context=context@entry=0x56392a452285 "toplevel") at ../../Src/exec.c:1198
#7  0x000056392a3f3254 in loop (toplevel=toplevel@entry=1,
    justonce=justonce@entry=0) at ../../Src/init.c:212
#8  0x000056392a3f6a2e in zsh_main (argc=<optimized out>, argv=<optimized out>)
    at ../../Src/init.c:1779
#9  0x00007f6e9cd187fd in __libc_start_main (main=0x56392a3bad40 <main>,
    argc=1, argv=0x7ffc0653e1b8, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7ffc0653e1a8)
    at ../csu/libc-start.c:332
#10 0x000056392a3bad7a in _start ()

The pipeline was:

  svn log | m

where "svn" is aliased to "svnwrapper" (which is a sh script
reexecuted as zsh) and "m" is aliased to "mless", which is the
following shell function:

mless () {
        emulate -LR zsh
        if [[ "$argv[-1]" == - ]]
        then
                read line && less "$@[1,-2]" "$line"
        else
                less "$@"
        fi
}

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Ctrl-\ while executing a pipeline made zsh quit

[Vincent Lefevre]

On 2022-04-26 02:36:49 +0200, Vincent Lefevre wrote:
> With zsh 5.8.1 under Linux (zsh 5.8.1-1 Debian/unstable package),
> while I was executing a pipeline, I typed Ctrl-\ to interrupt it
> (Ctrl-C had no effect), which made unexpectedly zsh quit: SIGQUIT
> should interrupt the commands zsh starts, not the interactive shell
> itself.
> 
> The backtrace:
> 
> Core was generated by `zsh'.
> Program terminated with signal SIGQUIT, Quit.
> #0  0x00007f6e9cd2dbe8 in __GI___sigsuspend (set=set@entry=0x7ffc0653d8e0)
>     at ../sysdeps/unix/sysv/linux/sigsuspend.c:26
> 26      ../sysdeps/unix/sysv/linux/sigsuspend.c: No such file or directory.
[...]

More information with the full backtrace:

Thread 1 (Thread 0x7f6e9cccf740 (LWP 99414)):
#0  0x00007f6e9cd2dbe8 in __GI___sigsuspend (set=set@entry=0x7ffc0653d8e0) at ../sysdeps/unix/sysv/linux/sigsuspend.c:26
        sc_ret = -514
        sc_ret = <optimized out>
#1  0x000056392a430207 in signal_suspend (sig=sig@entry=17, wait_cmd=wait_cmd@entry=0) at ../../Src/signals.c:393
        ret = <optimized out>
        set = {__val = {2, 5440281970810964224, 9, 18446744073709551496, 9, 94803531777152, 0, 0, 94803529069392, 140113054513588, 94803529165200, 94803531761792, 94803531790544, 94803531761792, 0, 94803521934268}}
#2  0x000056392a3fae2f in zwaitjob (job=<optimized out>, wait_cmd=0) at ../../Src/jobs.c:1603
        q = 3
        jn = 0x56392aac7350
#3  0x000056392a3fb544 in waitjobs () at ../../Src/jobs.c:1673
        jn = 0x56392aac7350
#4  0x000056392a3dc64b in execpline (state=state@entry=0x7ffc0653de20, slcode=<optimized out>, how=<optimized out>, how@entry=18, last1=0) at ../../Src/exec.c:1759
        jn = 0x56392aac7350
        updated = 1
        ipipe = {0, 0}
        opipe = {0, 0}
        pj = 0
        newjob = 1
        old_simple_pline = 0
        slflags = 0
        code = <optimized out>
        lastwj = 1
        lpforked = 0
#5  0x000056392a3dd4a7 in execlist (state=state@entry=0x7ffc0653de20, dont_change_job=dont_change_job@entry=0, exiting=exiting@entry=0) at ../../Src/exec.c:1419
        isend = <optimized out>
        donedebug = <optimized out>
        this_donetrap = 0
        donetrap = 0
        next = 0x7f6e9d0665e0
        code = <optimized out>
        ret = <optimized out>
        cj = 0
        csp = 0
        ltype = 18
        old_pline_level = 0
        old_list_pipe = 0
        old_list_pipe_job = 0
        old_list_pipe_text = 0x0
        oldlineno = 19
        oldnoerrexit = 0
#6  0x000056392a3dd9a2 in execode (p=p@entry=0x7f6e9d066580, dont_change_job=dont_change_job@entry=0, exiting=exiting@entry=0, context=context@entry=0x56392a452285 "toplevel") at ../../Src/exec.c:1198
        s = {prog = 0x7f6e9d066580, pc = 0x7f6e9d0665e0, strs = 0x7f6e9d0665e4 "svnwrapper"}
        zsh_eval_context_len = 32
        alen = <optimized out>
#7  0x000056392a3f3254 in loop (toplevel=toplevel@entry=1, justonce=justonce@entry=0) at ../../Src/init.c:212
        toksav = SEPER
        prog = 0x7f6e9d066580
        err = <optimized out>
        non_empty = 1
#8  0x000056392a3f6a2e in zsh_main (argc=<optimized out>, argv=<optimized out>) at ../../Src/init.c:1779
        errexit = 0
        t = <optimized out>
        runscript = <optimized out>
        zsh_name = <optimized out>
        cmd = 0x0
        t0 = <optimized out>
#9  0x00007f6e9cd187fd in __libc_start_main (main=0x56392a3bad40 <main>, argc=1, argv=0x7ffc0653e1b8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc0653e1a8) at ../csu/libc-start.c:332
        self = <optimized out>
        result = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {94803522285008, -328400302498789135, 94803521678672, 0, 0, 0, 326868374137981169, 408824851181193457}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x1, 0x7ffc0653e1b8}, data = {prev = 0x0, cleanup = 0x0, canceltype = 1}}}
        not_first_call = <optimized out>
#10 0x000056392a3bad7a in _start ()
No symbol table info available.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Ctrl-\ while executing a pipeline made zsh quit

[Bart Schaefer]

On Mon, Apr 25, 2022 at 5:37 PM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> With zsh 5.8.1 under Linux (zsh 5.8.1-1 Debian/unstable package),
> while I was executing a pipeline, I typed Ctrl-\ to interrupt it
> (Ctrl-C had no effect), which made unexpectedly zsh quit: SIGQUIT
> should interrupt the commands zsh starts, not the interactive shell
> itself.

I'm unable to reproduce this on Ubuntu 20.04 with 5.8.1.2-test.

I vaguely recall there's actually a bug in some version(s?) of "less"
that causes its parent to exit?

I did discover that if "less" exits with an error, the whole pipeline
becomes unkillable with either INT or QUIT; the shell is hung until
the left side exits.

Re: Ctrl-\ while executing a pipeline made zsh quit

[Vincent Lefevre]

On 2022-04-25 18:24:15 -0700, Bart Schaefer wrote:
> On Mon, Apr 25, 2022 at 5:37 PM Vincent Lefevre <vincent@vinc17.net> wrote:
> >
> > With zsh 5.8.1 under Linux (zsh 5.8.1-1 Debian/unstable package),
> > while I was executing a pipeline, I typed Ctrl-\ to interrupt it
> > (Ctrl-C had no effect), which made unexpectedly zsh quit: SIGQUIT
> > should interrupt the commands zsh starts, not the interactive shell
> > itself.
> 
> I'm unable to reproduce this on Ubuntu 20.04 with 5.8.1.2-test.

I can't reproduce it either. This may be a timing related issue:
perhaps there's some place where if a signal is received, everything
goes wrong (Ctrl-C normally has an effect, so perhaps things were
wrong when I first try Ctrl-C).

The only case I had found where Ctrl-C had no effect was this bug:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931216
  https://github.com/gwsw/less/issues/12

i.e. in case of process substitution, but here there was no such thing.

Or perhaps the cause of the issue was that here, the Ctrl-C didn't
kill the left-hand side (possibly because the ssh started by svn
got frozen... not sure).

> I vaguely recall there's actually a bug in some version(s?) of "less"
> that causes its parent to exit?

I'm not aware of that, and I don't see how this could be the fault
of "less" (unless it kills his parent, but why would it do this?).

> I did discover that if "less" exits with an error, the whole pipeline
> becomes unkillable with either INT or QUIT; the shell is hung until
> the left side exits.

If "less" really exits, how could this happen?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Ctrl-\ while executing a pipeline made zsh quit

[Bart Schaefer]

On Mon, Apr 25, 2022 at 8:00 PM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> > I did discover that if "less" exits with an error, the whole pipeline
> > becomes unkillable with either INT or QUIT; the shell is hung until
> > the left side exits.
>
> If "less" really exits, how could this happen?

When I couldn't replicate your problem, I thought perhaps I was
running the mless function the wrong way, so I did this:

( zsh -fc 'print a few words; /bin/sleep 30' ) | mless -

This causes less to exit with a no-such-file error, at which point all
signals were ignored and no prompt returned until the "sleep 30"
finished.

Re: Ctrl-\ while executing a pipeline made zsh quit

[Vincent Lefevre]

On 2022-04-25 21:05:11 -0700, Bart Schaefer wrote:
> On Mon, Apr 25, 2022 at 8:00 PM Vincent Lefevre <vincent@vinc17.net> wrote:
> >
> > > I did discover that if "less" exits with an error, the whole pipeline
> > > becomes unkillable with either INT or QUIT; the shell is hung until
> > > the left side exits.
> >
> > If "less" really exits, how could this happen?
> 
> When I couldn't replicate your problem, I thought perhaps I was
> running the mless function the wrong way, so I did this:
> 
> ( zsh -fc 'print a few words; /bin/sleep 30' ) | mless -
> 
> This causes less to exit with a no-such-file error, at which point all
> signals were ignored and no prompt returned until the "sleep 30"
> finished.

I wasn't using "mless" in that way, though this may be related to
what I got. Anyway, I think that this is a bug in zsh; this issue
is also reproducible with "head -n 1" instead of "less".

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

pipeline that cannot be interrupted (was: Ctrl-\ while executing a pipeline made zsh quit)

[Vincent Lefevre]

On 2022-04-26 11:07:22 +0200, Vincent Lefevre wrote:
> I wasn't using "mless" in that way, though this may be related to
> what I got. Anyway, I think that this is a bug in zsh; this issue
> is also reproducible with "head -n 1" instead of "less".

Or even simpler:

zira:~> ( zsh -fc 'print a few words; /bin/sleep 10' ) | { head -n 1 }
a few words
^C^C^C^C^C^C^C^C^\^\^\^\%

(the curly brackets are important).

I think that's the same issue I had reported in 2019, for which I got
no replies:

────────────────────────────────────────────────────────────────────────
Date: Fri, 2 Aug 2019 16:51:06 +0200
From: Vincent Lefevre <vincent@vinc17.net>
To: zsh-workers@zsh.org
Subject: [BUG] pipeline that cannot be interrupted with Ctrl-C (regression)

With zsh 5.7.1 under Debian, the following pipeline cannot be
interrupted with Ctrl-C:

  { /bin/sleep 10 ; /bin/sleep 20; } | { /bin/sleep 30 ; /bin/sleep 40; }

But if I remove one of the sleep, it can be interrupted by Ctrl-C.

There was no issue with zsh 5.3.1 (Debian 9).

Note: I mentioned this example in zsh-users in the thread
"kill the LHS command of a pipe once the RHS command terminates".
────────────────────────────────────────────────────────────────────────

See:
  https://www.zsh.org/mla/workers/2019/msg00672.html
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933730

Neither Ctrl-C nor Ctrl-\ has any effect.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: pipeline that cannot be interrupted

[Vincent Lefevre]

On 2022-04-26 11:18:33 +0200, Vincent Lefevre wrote:
> Date: Fri, 2 Aug 2019 16:51:06 +0200
> From: Vincent Lefevre <vincent@vinc17.net>
> To: zsh-workers@zsh.org
> Subject: [BUG] pipeline that cannot be interrupted with Ctrl-C (regression)
> 
> With zsh 5.7.1 under Debian, the following pipeline cannot be
> interrupted with Ctrl-C:
> 
>   { /bin/sleep 10 ; /bin/sleep 20; } | { /bin/sleep 30 ; /bin/sleep 40; }
> 
> But if I remove one of the sleep, it can be interrupted by Ctrl-C.
> 
> There was no issue with zsh 5.3.1 (Debian 9).
> 
> Note: I mentioned this example in zsh-users in the thread
> "kill the LHS command of a pipe once the RHS command terminates".

More tests similar this one:

zira% {
  echo L1 > /dev/tty
  /bin/sleep 10
  echo L2 > /dev/tty
  /bin/sleep 20
  echo L3 > /dev/tty
} | {
  echo R1 > /dev/tty
  /bin/sleep 30
  echo R2 > /dev/tty
  /bin/sleep 40
  echo R3 > /dev/tty
}
R1
L1
^CR2
^C^C^C^C^\^\

So the "/bin/sleep 30" gets interrupted by Ctrl-C, then
Ctrl-C and Ctrl-\ are ignored until "/bin/sleep 40" ends.

With "date" (a command) instead of the "echo" builtin, the signals
are ignored until the "/bin/sleep 20" ends, and before the 3rd date
command:

zira% {
  date "+L1 %F %T" > /dev/tty
  /bin/sleep 10
  date "+L2 %F %T" > /dev/tty
  /bin/sleep 20
  date "+L3 %F %T" > /dev/tty
} | {
  date "+R1 %F %T" > /dev/tty
  /bin/sleep 30
  date "+R2 %F %T" > /dev/tty
  /bin/sleep 40
  date "+R3 %F %T" > /dev/tty
}
R1 2022-04-26 12:00:50
L1 2022-04-26 12:00:50
^C^C^C^\^\L2 2022-04-26 12:01:00
^C^C^C^\^\
zira% 

with the prompt at 2022-04-26 12:01:20.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: pipeline that cannot be interrupted

[Bart Schaefer]

On Tue, Apr 26, 2022 at 3:12 AM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> > There was no issue with zsh 5.3.1 (Debian 9).

zsh-5.5.1 - a single ^C returns to the prompt
zsh-5.6.2 - first ^C jumps to R2, second ^C to prompt
zsh-5.7.1 - broken in the way Vincent describes

I don't have time right now to dig any further, but there were changes
to list_pipe handling in each of the latter two releases.

Re: pipeline that cannot be interrupted

[Bart Schaefer]

On Wed, Apr 27, 2022 at 1:07 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> I don't have time right now to dig any further

OK, I fibbed a little ... but I really don't have time to chase down
what is really going on.

> zsh-5.5.1 - a single ^C returns to the prompt

zsh-5.6 - a single ^C returns to the prompt
zsh-5.6.1 - broken as Vincent describes

That points to workers/43409 as the culprit, but ...

> zsh-5.6.2 - first ^C jumps to R2, second ^C to prompt

... that means workers/43446 partly fixed it?

> zsh-5.7.1 - broken in the way Vincent describes

And workers/43535 broke it again.

Naively, the following not-really-a-patch-yet fixes it, and all tests
still pass.

diff --git a/Src/jobs.c b/Src/jobs.c
index af0a1233d..8ed2219bb 100644
--- a/Src/jobs.c
+++ b/Src/jobs.c
@@ -1476,7 +1476,7 @@ addproc(pid_t pid, char *text, int aux, struct
timeval *bgtime,
      * set it for that, too.
      */
     if (gleader != -1) {
-        jobtab[thisjob].gleader = gleader;
+        jobtab[thisjob].gleader = pid /* gleader */;
         if (list_pipe_job_used != -1)
         jobtab[list_pipe_job_used].gleader = gleader;
         /*

Re: pipeline that cannot be interrupted

[Bart Schaefer]

[-- Attachment #1: Type: text/plain, Size: 197 bytes --]

On Wed, Apr 27, 2022 at 1:29 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> Naively, the following not-really-a-patch-yet fixes it, and all tests
> still pass.

Does this make more sense?

[-- Attachment #2: gleader.txt --]
[-- Type: text/plain, Size: 511 bytes --]

diff --git a/Src/jobs.c b/Src/jobs.c
index af0a1233d..85d4c4d1f 100644
--- a/Src/jobs.c
+++ b/Src/jobs.c
@@ -1476,7 +1476,10 @@ addproc(pid_t pid, char *text, int aux, struct timeval *bgtime,
 	 * set it for that, too.
 	 */
 	if (gleader != -1) {
-	    jobtab[thisjob].gleader = gleader;
+	    if (jobtab[thisjob].stat & STAT_CURSH)
+		jobtab[thisjob].gleader = gleader;
+	    else
+		jobtab[thisjob].gleader = pid;
 	    if (list_pipe_job_used != -1)
 		jobtab[list_pipe_job_used].gleader = gleader;
 	    /*