zsh 5.1 freezes with zombie child

zsh 5.1 freezes with zombie child

[Vincent Lefevre]

I did with zsh 5.1:

1. Run "emacs some_file &"
2. Run "less some_other_file"
3. Quit emacs.
4. Quit less.

The result is a frozen zsh with a zombie child corresponding to less.
100% reproducible.

The backtrace:

(gdb) bt
#0  0x00007f6cd1c35446 in do_sigsuspend (set=0x7ffc2716e9e0)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
#1  __GI___sigsuspend (set=set@entry=0x7ffc2716e9e0)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:41
#2  0x00000000004787f6 in signal_suspend (sig=sig@entry=17, 
    wait_cmd=wait_cmd@entry=0) at ../../Src/signals.c:375
#3  0x0000000000448ca6 in zwaitjob (job=<optimized out>, wait_cmd=0)
    at ../../Src/jobs.c:1453
#4  0x0000000000449367 in waitjobs () at ../../Src/jobs.c:1505
#5  0x000000000042cb1b in execpline (state=state@entry=0x7ffc27170610, 
    slcode=<optimized out>, how=<optimized out>, how@entry=18, last1=0)
    at ../../Src/exec.c:1601
#6  0x000000000042db2d in execlist (state=state@entry=0x7ffc27170610, 
    dont_change_job=dont_change_job@entry=1, exiting=exiting@entry=0)
    at ../../Src/exec.c:1283
#7  0x000000000045139b in execif (state=0x7ffc27170610, do_exec=0)
    at ../../Src/loop.c:565
#8  0x000000000042a4c1 in execcmd (state=state@entry=0x7ffc27170610, 
    input=input@entry=0, output=output@entry=0, how=<optimized out>, 
    how@entry=18, last1=2) at ../../Src/exec.c:3472
#9  0x000000000042be7e in execpline2 (state=state@entry=0x7ffc27170610, 
    pcode=pcode@entry=579, how=how@entry=18, input=0, output=0, 
    last1=last1@entry=0) at ../../Src/exec.c:1746
#10 0x000000000042c241 in execpline (state=state@entry=0x7ffc27170610, 
    slcode=<optimized out>, how=how@entry=18, last1=0) at ../../Src/exec.c:1524
#11 0x000000000042db2d in execlist (state=state@entry=0x7ffc27170610, 
    dont_change_job=dont_change_job@entry=1, exiting=exiting@entry=0)
    at ../../Src/exec.c:1283
#12 0x000000000042df00 in execode (p=p@entry=0x13871c0, 
    dont_change_job=dont_change_job@entry=1, exiting=exiting@entry=0, 
    context=context@entry=0x495257 "shfunc") at ../../Src/exec.c:1074
#13 0x000000000042ea19 in runshfunc (prog=0x13871c0, wrap=0x0, 
    name=0x7f6cd2af8d90 "mless") at ../../Src/exec.c:5356
#14 0x000000000042f355 in doshfunc (shfunc=shfunc@entry=0x132e320, 
    doshargs=doshargs@entry=0x7f6cd2af8d28, noreturnval=noreturnval@entry=0)
    at ../../Src/exec.c:5222
#15 0x000000000042f71f in execshfunc (shf=shf@entry=0x132e320, 
    args=args@entry=0x7f6cd2af8d28) at ../../Src/exec.c:4853
#16 0x000000000042b53b in execshfunc (args=0x7f6cd2af8d28, shf=0x132e320)
    at ../../Src/exec.c:4819
#17 execcmd (state=state@entry=0x7ffc27172280, input=input@entry=0, 
    output=output@entry=0, how=<optimized out>, how@entry=18, last1=2)
    at ../../Src/exec.c:3524
#18 0x000000000042be7e in execpline2 (state=state@entry=0x7ffc27172280, 
    pcode=pcode@entry=2499, how=how@entry=18, input=0, output=0, 
    last1=last1@entry=0) at ../../Src/exec.c:1746
#19 0x000000000042c241 in execpline (state=state@entry=0x7ffc27172280, 
    slcode=<optimized out>, how=how@entry=18, last1=0) at ../../Src/exec.c:1524
#20 0x000000000042db2d in execlist (state=state@entry=0x7ffc27172280, 
    dont_change_job=dont_change_job@entry=0, exiting=exiting@entry=0)
    at ../../Src/exec.c:1283
#21 0x000000000042df00 in execode (p=p@entry=0x7f6cd2af8bb8, 
    dont_change_job=dont_change_job@entry=0, exiting=exiting@entry=0, 
    context=context@entry=0x496791 "toplevel") at ../../Src/exec.c:1074
#22 0x00000000004417c9 in loop (toplevel=toplevel@entry=1, 
    justonce=justonce@entry=0) at ../../Src/init.c:208
#23 0x0000000000444c1e in zsh_main (argc=<optimized out>, argv=<optimized out>)
    at ../../Src/init.c:1678
#24 0x00007f6cd1c21b45 in __libc_start_main (main=0x4105c0 <main>, argc=1, 
    argv=0x7ffc271725c8, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7ffc271725b8) at libc-start.c:287
#25 0x00000000004105ee in _start ()

-- 
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: zsh 5.1 freezes with zombie child

[Vincent Lefevre]

On 2015-09-02 01:07:43 +0200, Vincent Lefevre wrote:
> I did with zsh 5.1:
> 
> 1. Run "emacs some_file &"
> 2. Run "less some_other_file"
> 3. Quit emacs.
> 4. Quit less.
> 
> The result is a frozen zsh with a zombie child corresponding to less.
> 100% reproducible.

Hmm... not reproducible after "zsh -f". There may be something else.

-- 
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: zsh 5.1 freezes with zombie child

[Vincent Lefevre]

On 2015-09-02 01:07:43 +0200, Vincent Lefevre wrote:
> I did with zsh 5.1:
> 
> 1. Run "emacs some_file &"
> 2. Run "less some_other_file"
> 3. Quit emacs.
> 4. Quit less.
> 
> The result is a frozen zsh with a zombie child corresponding to less.
> 100% reproducible.

After "zsh -f":

zira% updprompt() { true && { : } }
zira% TRAPCHLD() { updprompt }
zira% sleep 2 & sleep 3 ; echo OK
[1] 20452
[1]  + done       sleep 2

and zsh freezes here.

-- 
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: zsh 5.1 freezes with zombie child

[Bart Schaefer]

On Sep 2,  2:13am, Vincent Lefevre wrote:
}
} zira% updprompt() { true && { : } }
} zira% TRAPCHLD() { updprompt }
} zira% sleep 2 & sleep 3 ; echo OK
} [1] 20452
} [1]  + done       sleep 2
} 
} and zsh freezes here.

The following fixes it, but makes me nervous.  Is Mathias Fredriksson
still listening?  Try to reproduce that deadlock from the thread back
at the beginning of August?  (Was it really that recently?  Gaah.)


diff --git a/Src/signals.c b/Src/signals.c
index f45c186..aa0b5aa 100644
--- a/Src/signals.c
+++ b/Src/signals.c
@@ -1348,6 +1348,7 @@ void
 dotrap(int sig)
 {
     void *funcprog;
+    int q = queue_signal_level();
 
     if (sigtrapped[sig] & ZSIG_FUNC) {
 	HashNode hn = gettrapnode(sig, 0);
@@ -1370,5 +1371,9 @@ dotrap(int sig)
     if ((sigtrapped[sig] & ZSIG_IGNORED) || !funcprog || errflag)
 	return;
 
+    dont_queue_signals();
+
     dotrapargs(sig, sigtrapped+sig, funcprog);
+
+    restore_queue_signals(q);
 }

Re: zsh 5.1 freezes with zombie child

[Mathias Fredriksson]

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

I'm currently away, but I'll give it a try when I get back at the end of
the week.
On Sep 2, 2015 5:15 AM, "Bart Schaefer" <schaefer@brasslantern.com> wrote:

> On Sep 2,  2:13am, Vincent Lefevre wrote:
> }
> } zira% updprompt() { true && { : } }
> } zira% TRAPCHLD() { updprompt }
> } zira% sleep 2 & sleep 3 ; echo OK
> } [1] 20452
> } [1]  + done       sleep 2
> }
> } and zsh freezes here.
>
> The following fixes it, but makes me nervous.  Is Mathias Fredriksson
> still listening?  Try to reproduce that deadlock from the thread back
> at the beginning of August?  (Was it really that recently?  Gaah.)
>
>
> diff --git a/Src/signals.c b/Src/signals.c
> index f45c186..aa0b5aa 100644
> --- a/Src/signals.c
> +++ b/Src/signals.c
> @@ -1348,6 +1348,7 @@ void
>  dotrap(int sig)
>  {
>      void *funcprog;
> +    int q = queue_signal_level();
>
>      if (sigtrapped[sig] & ZSIG_FUNC) {
>         HashNode hn = gettrapnode(sig, 0);
> @@ -1370,5 +1371,9 @@ dotrap(int sig)
>      if ((sigtrapped[sig] & ZSIG_IGNORED) || !funcprog || errflag)
>         return;
>
> +    dont_queue_signals();
> +
>      dotrapargs(sig, sigtrapped+sig, funcprog);
> +
> +    restore_queue_signals(q);
>  }
>

Re: zsh 5.1 freezes with zombie child

[Mathias Fredriksson]

On Wed, Sep 2, 2015 at 5:14 AM, Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> The following fixes it, but makes me nervous.  Is Mathias Fredriksson
> still listening?  Try to reproduce that deadlock from the thread back
> at the beginning of August?  (Was it really that recently?  Gaah.)

Finally got around to testing this change, can't reproduce any deadlocks, *yay*!

Re: zsh 5.1 freezes with zombie child

[Peter Stephenson]

On Sat, 5 Sep 2015 01:39:25 +0300
Mathias Fredriksson <mafredri@gmail.com> wrote:
> On Wed, Sep 2, 2015 at 5:14 AM, Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > The following fixes it, but makes me nervous.  Is Mathias Fredriksson
> > still listening?  Try to reproduce that deadlock from the thread back
> > at the beginning of August?  (Was it really that recently?  Gaah.)
> 
> Finally got around to testing this change, can't reproduce any deadlocks, *yay*!

Thanks --- I've uploaded 5.1-test-1 to
htttp://www.zsh.org/pub/development and hope I'll be able to release a
bug fix version 5.1.1 in the middle of the week.

pws

Re: zsh 5.1 freezes with zombie child

[Bart Schaefer]

On Sep 6,  6:38pm, Peter Stephenson wrote:
} 
} Thanks --- I've uploaded 5.1-test-1 to
} htttp://www.zsh.org/pub/development and hope I'll be able to release a
} bug fix version 5.1.1 in the middle of the week.

Did someone fix Mikael's infinite-PS2-on-exit issue from 36407?

-- 
Barton E. Schaefer

Infinite loop on exit

[Peter Stephenson]

On Thu, 10 Sep 2015 07:25:10 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Did someone fix Mikael's infinite-PS2-on-exit issue from 36407?

No, it got tacked on to a thread about something else, so got missed.

It was this:

> zle -f
> % bindkey 0 e
> % e() exit
> % zle -N e
> % '
> quote> 0
>
> this prints the PS2 prompt indefinitely, ctrl-c is ignored

exit_pending is set because we need to tidy up functions before we exit.
To avoid going insane, we only recover at the top level (sanitising the
chain of checks to optimise this so we could exit earlier would be
pretty gruesome and gain almost nothing).  In that case we shouldn't try
and read another character to prevent us getting there.

The following works here and looks unobjectionable.  Flagging an error
is mostly to prevent another error message from appearing when the lexer
finds out its plans have gone agley.

This doesn't do anything special with ^C, but I think that was just down
to Zle being rather special with interrupts, so if we don't go back into
it repeatedly the issue doesn't arise.

pws

diff --git a/Src/hist.c b/Src/hist.c
index 75e809c..9c42d85 100644
--- a/Src/hist.c
+++ b/Src/hist.c
@@ -390,6 +390,12 @@ ihgetc(void)
 {
     int c = ingetc();
 
+    if (exit_pending)
+    {
+	lexstop = 1;
+	errflag |= ERRFLAG_ERROR;
+	return ' ';
+    }
     qbang = 0;
     if (!stophist && !(inbufflags & INP_ALIAS)) {
 	/* If necessary, expand history characters. */

Re: Infinite loop on exit

[Bart Schaefer]

On Sep 10,  3:51pm, Peter Stephenson wrote:
}
} To avoid going insane, we only recover at the top level (sanitising the
} chain of checks to optimise this so we could exit earlier would be
} pretty gruesome and gain almost nothing).

There was already a check of exit_pending within a few lines of the place
I added mine in 36470.  Should we do both patches?

} This doesn't do anything special with ^C, but I think that was just down
} to Zle being rather special with interrupts, so if we don't go back into
} it repeatedly the issue doesn't arise.

Agree.

Re: Infinite loop on exit

[Peter Stephenson]

On Thu, 10 Sep 2015 08:43:47 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Sep 10,  3:51pm, Peter Stephenson wrote:
> }
> } To avoid going insane, we only recover at the top level (sanitising the
> } chain of checks to optimise this so we could exit earlier would be
> } pretty gruesome and gain almost nothing).
> 
> There was already a check of exit_pending within a few lines of the place
> I added mine in 36470.  Should we do both patches?

I think they are not in competition, so that would probably be OK.

pws