Bug 1267251

I believe this is fixed in zsh-5.0.2-14.el7.

*** This bug has been marked as a duplicate of bug 1222867 ***

The scripts that do core dump are:

$ cat <<EOF > test1.ksh
#!/usr/bin/ksh
echo $HOME
EOF

or

$ cat <<EOF > test2.ksh
#!/usr/bin/ksh
export V=${HOME}
EOF

Not the one with only V=$HOME.

I did test it with the package that should have fixed the issue. Also the backtraces are very different.

Backtrace from checking the first script:

(gdb) bt
#0  sepsplit (s=0x0, sep=sep@entry=0x0, allownull=allownull@entry=0, heap=heap@entry=1) at utils.c:3198
#1  0x000000000047c1da in paramsubst (pf_flags=<optimized out>, qt=<optimized out>, str=0x7ffdc3b69070, n=<optimized out>, 
    l=<optimized out>) at subst.c:3242
#2  stringsubst (list=list@entry=0x7f34d129a130, node=<optimized out>, pf_flags=<optimized out>, pf_flags@entry=0, asssub=asssub@entry=0)
    at subst.c:236
#3  0x000000000047e7c5 in prefork (list=list@entry=0x7f34d129a130, flags=0) at subst.c:77
#4  0x0000000000428d98 in execcmd (state=state@entry=0x7ffdc3b69950, input=input@entry=0, output=output@entry=0, how=how@entry=18, last1=2)
    at exec.c:2587
#5  0x000000000042b356 in execpline2 (state=state@entry=0x7ffdc3b69950, pcode=pcode@entry=195, how=how@entry=18, input=0, output=0, 
    last1=last1@entry=0) at exec.c:1685
#6  0x000000000042b78c in execpline (state=state@entry=0x7ffdc3b69950, slcode=<optimized out>, how=how@entry=18, last1=0) at exec.c:1470
#7  0x000000000042cb12 in execlist (state=state@entry=0x7ffdc3b69950, dont_change_job=dont_change_job@entry=0, exiting=exiting@entry=0)
    at exec.c:1253
#8  0x000000000042ce02 in execode (p=p@entry=0x7f34d129a0b0, dont_change_job=dont_change_job@entry=0, exiting=exiting@entry=0, 
    context=context@entry=0x48ef99 "toplevel") at exec.c:1062
#9  0x000000000043d4a2 in loop (toplevel=toplevel@entry=1, justonce=justonce@entry=0) at init.c:185
#10 0x000000000044074e in zsh_main (argc=<optimized out>, argv=<optimized out>) at init.c:1616
#11 0x00007f34d0176af5 in __libc_start_main (main=0x40ecf0 <main>, argc=3, ubp_av=0x7ffdc3b69b88, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffdc3b69b78) at libc-start.c:274


From checking the second one
(gdb) bt
#0  __strlen_sse2_pminub () at ../sysdeps/x86_64/multiarch/strlen-sse2-pminub.S:38
#1  0x000000000047bcd2 in paramsubst (pf_flags=<optimized out>, qt=<optimized out>, str=0x7ffdec4aca80, n=<optimized out>, 
    l=<optimized out>) at subst.c:3719
#2  stringsubst (list=list@entry=0x7fbf76307130, node=<optimized out>, pf_flags=<optimized out>, pf_flags@entry=0, asssub=asssub@entry=1)
    at subst.c:236
#3  0x000000000047e7c5 in prefork (list=list@entry=0x7fbf76307130, flags=1) at subst.c:77
#4  0x0000000000428d98 in execcmd (state=state@entry=0x7ffdec4ad360, input=input@entry=0, output=output@entry=0, how=how@entry=18, last1=2)
    at exec.c:2587
#5  0x000000000042b356 in execpline2 (state=state@entry=0x7ffdec4ad360, pcode=pcode@entry=195, how=how@entry=18, input=0, output=0, 
    last1=last1@entry=0) at exec.c:1685
#6  0x000000000042b78c in execpline (state=state@entry=0x7ffdec4ad360, slcode=<optimized out>, how=how@entry=18, last1=0) at exec.c:1470
#7  0x000000000042cb12 in execlist (state=state@entry=0x7ffdec4ad360, dont_change_job=dont_change_job@entry=0, exiting=exiting@entry=0)
    at exec.c:1253
#8  0x000000000042ce02 in execode (p=p@entry=0x7fbf763070b0, dont_change_job=dont_change_job@entry=0, exiting=exiting@entry=0, 
    context=context@entry=0x48ef99 "toplevel") at exec.c:1062
#9  0x000000000043d4a2 in loop (toplevel=toplevel@entry=1, justonce=justonce@entry=0) at init.c:185
#10 0x000000000044074e in zsh_main (argc=<optimized out>, argv=<optimized out>) at init.c:1616
#11 0x00007fbf751e3af5 in __libc_start_main (main=0x40ecf0 <main>, argc=3, ubp_av=0x7ffdec4ad598, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffdec4ad588) at libc-start.c:274
#12 0x000000000040ed21 in _start ()
(gdb)

As discussed on IRC, this is likely not a duplicate of bug #1222867 but it still seems to be fixed in zsh-5.0.2-14.el7.  The backtrace in comment #3 is obtained using zsh from a scratch build that I have not the corresponding source code for.

Please provide steps to reproduce using the tagged brew build zsh-5.0.2-14.el7.

In my testing, the issue also occurs in zsh-5.0.2-14.el7.

Backtraces are identical, with the exception of some line number differences in exec.c (+2)

I tried a fresh RHEL-7.1 machine with zsh-5.0.2-14.el7 installed on top of that and both tests worked as expected.  Please provide steps to reproduce the crash applicable on a fresh RHEL-7.1 machine.

Looks like I blindly copied the method to create the files, which replace $HOME to its actual value.

The files should instead be created using the following commands:

$ cat <<EOF > test1.ksh
#!/usr/bin/ksh
echo \$HOME
EOF

or

$ cat <<EOF > test2.ksh
#!/usr/bin/ksh
export V=\${HOME}
EOF

(In reply to Tim Speetjens from comment #9)
> Looks like I blindly copied the method to create the files, which replace
> $HOME to its actual value.

Thank you for clarifying that!

> The files should instead be created using the following commands:
> 
> $ cat <<EOF > test1.ksh
> #!/usr/bin/ksh
> echo \$HOME
> EOF

This crashes even with the latest upstream version of zsh.

> or
> 
> $ cat <<EOF > test2.ksh
> #!/usr/bin/ksh
> export V=\${HOME}
> EOF

This crash seems to be fixed (or avoided) in the current upstream version.

(In reply to Kamil Dudka from comment #10)
> > $ cat <<EOF > test1.ksh
> > #!/usr/bin/ksh
> > echo \$HOME
> > EOF
> 
> This crashes even with the latest upstream version of zsh.

Reported upstream:

http://www.zsh.org/mla/workers/2015/msg02696.html

> > $ cat <<EOF > test2.ksh
> > #!/usr/bin/ksh
> > export V=\${HOME}
> > EOF
> 
> This crash seems to be fixed (or avoided) in the current upstream version.

Assuming the fix for bug #1222867 is applied (it actually came later):

https://sourceforge.net/p/zsh/code/ci/af957f2e

... the crash was avoided by the following upstream commit:

https://sourceforge.net/p/zsh/code/ci/44757a65

... where it started to print the following diagnostic message:

    1: subst.c:3712: value is NULL in paramsubst

The diagnostic message went away with the following upstream commit:

https://sourceforge.net/p/zsh/code/ci/39b28980

Nevertheless the following command still crashes with the latest upstream:

$ ARGV0=ksh zsh -nc 'export .V=${HOME}'

upstream commit:

https://sourceforge.net/p/zsh/code/ci/83a17579

I can confirm the test scripts from

https://access.redhat.com/solutions/2221031

lead to coredump in zsh-5.0.2-14.el7_2.2.x86_64 (latest atm) as well:

#0  __strlen_sse2_pminub () at ../sysdeps/x86_64/multiarch/strlen-sse2-pminub.S:38
#1  0x00000000004819d2 in paramsubst (pf_flags=<optimized out>, qt=<optimized out>,
    str=0x7fffa70326b0, n=<optimized out>, l=<optimized out>) at subst.c:3719
#2  stringsubst (list=list@entry=0x7efffb63f1b8, node=<optimized out>, pf_flags=<optimized out>,
    pf_flags@entry=0, asssub=asssub@entry=1) at subst.c:236
#3  0x00000000004844c5 in prefork (list=list@entry=0x7efffb63f1b8, flags=1) at subst.c:77
#4  0x00000000004296a8 in execcmd (state=state@entry=0x7fffa7034190, input=input@entry=0,
    output=output@entry=0, how=how@entry=18, last1=2) at exec.c:2611
#5  0x000000000042c2a6 in execpline2 (state=state@entry=0x7fffa7034190, pcode=pcode@entry=195,
    how=how@entry=18, input=0, output=0, last1=last1@entry=0) at exec.c:1707
#6  0x000000000042c6e3 in execpline (state=state@entry=0x7fffa7034190, slcode=<optimized out>,
    how=how@entry=18, last1=0) at exec.c:1487
#7  0x000000000042e475 in execlist (state=state@entry=0x7fffa7034190,
    dont_change_job=dont_change_job@entry=0, exiting=exiting@entry=0) at exec.c:1259
#8  0x000000000042e762 in execode (p=p@entry=0x7efffb63f138,
    dont_change_job=dont_change_job@entry=0, exiting=exiting@entry=0,
    context=context@entry=0x495299 "toplevel") at exec.c:1062
#9  0x000000000044098f in loop (toplevel=toplevel@entry=1, justonce=justonce@entry=0)
    at init.c:187
#10 0x00000000004440ce in zsh_main (argc=<optimized out>, argv=<optimized out>) at init.c:1620
#11 0x00007efffa512b15 in __libc_start_main (main=0x40ed30 <main>, argc=3,
    ubp_av=0x7fffa7034558, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fffa7034548) at libc-start.c:274
#12 0x000000000040ed61 in _start ()

Is it possible to obtain the updates zsh package for testing?

(In reply to Zdenek Pytela from comment #19)
> lead to coredump in zsh-5.0.2-14.el7_2.2.x86_64 (latest atm) as well:

zsh-5.0.2-14.el7_2.2 does not contain a fix for this bug, but it is going to be fixed in RHEL-7.3 (zsh-5.0.2-17.el7 or newer, as the Fixed In Version field suggests).

*** Bug 1389492 has been marked as a duplicate of this bug. ***

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2152.html