[BUG] Another alias-related crash

[BUG] Another alias-related crash

[dana]

Oh, i found the original issue i said i was looking for in workers/43508. We're
pressing Return after each line here:

  # OK
  % unalias grep
  % echo $(( $(echo x | grep . ))
  cmdsubst> ^C

  # Crash
  % alias grep='grep --color=auto'
  % echo $(( $(echo x | grep . ))
  zsh: segmentation fault

It seems like ZLE is required to make this happen, but i don't think completion
is necessary this time. As before, i replicated on 5.4.2 (Linux) and master
(macOS).

input_hasalias() was introduced in workers/40306.

Back-trace from 5.4.2:

#0  input_hasalias () at ../../Src/input.c:696
        flags = <optimized out>
        instackptr = 0x55b509ad30a8
#1  0x000055b508572b11 in par_simple (nr=0, cmplx=0x7ffdea7ca1c4) at ../../Src/parse.c:1777
        isnull = 1
        p = <optimized out>
        isfunc = 0
        sr = 0
        nrediradd = <optimized out>
        r = 32521
        argc = 0
        oecused = 3
        c = 0
        assignments = 0
        ppost = 0
        is_typeset = 0
        hasalias = <optimized out>
        postassigns = <optimized out>
        oecused = <optimized out>
        isnull = <optimized out>
        r = <optimized out>
        argc = <optimized out>
        p = <optimized out>
        isfunc = <optimized out>
        sr = <optimized out>
        c = <optimized out>
        nrediradd = <optimized out>
        assignments = <optimized out>
        ppost = <optimized out>
        is_typeset = <optimized out>
        hasalias = <optimized out>
        postassigns = <optimized out>
        ptr = <optimized out>
        name = <optimized out>
        str = <optimized out>
        oldcmdpos = <optimized out>
        n = <optimized out>
        type2 = <optimized out>
        redir_var = <optimized out>
        eptr = <optimized out>
        ptr = <optimized out>
        toksave = <optimized out>
        idstring = <optimized out>
        ptr = <optimized out>
        name = <optimized out>
        str = <optimized out>
        n = <optimized out>
        parr = <optimized out>
        oldlineno = <optimized out>
        onp = <optimized out>
        so = <optimized out>
        oecssub = <optimized out>
        c = <optimized out>
        ll = <optimized out>
        sl = <optimized out>
        c = <optimized out>
        parg = <optimized out>
#2  par_cmd (cmplx=cmplx@entry=0x7ffdea7ca1c4, zsh_construct=zsh_construct@entry=0) at ../../Src/parse.c:1011
        sr = <optimized out>
        r = 3
        nr = 0
#3  0x000055b50857417c in par_pline (cmplx=cmplx@entry=0x7ffdea7ca1c4) at ../../Src/parse.c:858
        p = 2
        line = 2
#4  0x000055b508574389 in par_sublist2 (cmplx=cmplx@entry=0x7ffdea7ca1c4) at ../../Src/parse.c:839
        f = 0

dana

Re: [BUG] Another alias-related crash

[Peter Stephenson]

On Thu, 20 Sep 2018 18:30:03 -0500
dana <dana@dana.is> wrote:
>   # Crash
>   % alias grep='grep --color=auto'
>   % echo $(( $(echo x | grep . ))
>   zsh: segmentation fault

I'm not getting a crash but valgrind does show a problem.  It suggests
this simple patch fixes it.  The DPUTS is just a paranoid check which
isn't relevant to the crash here; these are all compiled out unless you
have a debug buid.

This code is particularly complicated owing to having to decide between

$(( $(echo stuff) ))

--- mathematical evaluation --- and

$(( $(echo stuff)); more stuff)

--- command substitution with a subshell inside, which as far as I can
see is valid syntax.  Although the alias bug isn't directly related, I
think it shows up here because of the particularly active use of the
input stack while the shell is deciding what's going on.

Would strongly advise NOT doing completion in that sort of code.  The
resulting bus smash of hard to understand bits of the shell could make
the quantum vacuum unstable.  (Sort of "off mass shell".  Physicists'
joke, sort of.)

pws

diff --git a/Src/input.c b/Src/input.c
index 9787dedf6..e9989ffe4 100644
--- a/Src/input.c
+++ b/Src/input.c
@@ -555,6 +555,7 @@ inpush(char *str, int flags, Alias inalias)
 	if ((instacktop->alias = inalias))
 	    inalias->inuse = 1;
     } else {
+	instacktop->alias = NULL;
 	/* If we are continuing an alias expansion, record the alias
 	 * expansion in new set of flags (do we need this?)
 	 */
@@ -691,6 +692,7 @@ char *input_hasalias(void)
     {
 	if (!(flags & INP_CONT))
 	    break;
+	DPUTS(instackptr == instack, "BUG: continuation at bottom of instack");
 	instackptr--;
 	if (instackptr->alias)
 	    return instackptr->alias->node.nam;

Re: [BUG] Another alias-related crash

[Bart Schaefer]

On Fri, Sep 21, 2018 at 8:14 AM, Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
>
> Would strongly advise NOT doing completion in that sort of code.  The
> resulting bus smash of hard to understand bits of the shell could make
> the quantum vacuum unstable.  (Sort of "off mass shell".  Physicists'
> joke, sort of.)

Zsh behavior is best described by using Feynman diagrams.

Re: [BUG] Another alias-related crash

[Daniel Shahaf]

Peter Stephenson wrote on Fri, 21 Sep 2018 16:14 +0100:
> This code is particularly complicated owing to having to decide between
> 
> $(( $(echo stuff) ))
> 
> --- mathematical evaluation --- and
> 
> $(( $(echo stuff)); more stuff)
> 
> --- command substitution with a subshell inside, which as far as I can
> see is valid syntax.  Although the alias bug isn't directly related, I
> think it shows up here because of the particularly active use of the
> input stack while the shell is deciding what's going on.
> 
> Would strongly advise NOT doing completion in that sort of code.

Can we *prevent* completion from being used in such code?  I.e., detect
that we're in a Schrödinger's «$((» and simply error out without
attempting to figure out what syntactical position we're generating
completions at?

I suspect that would be non-trivial (since IIRC completion and the
parser don't talk much to each other), but if it's possible it sounds
like it'd be an improvement.

> The resulting bus smash of hard to understand bits of the shell could
> make the quantum vacuum unstable.  (Sort of "off mass shell".
> Physicists' joke, sort of.)

Cheers,

Daniel