Red Hat Bugzilla – Bug 1267251
crash in ksh mode with -n and $HOME [RHEL-7]
Last modified: 2016-11-03 19:01:59 EDT
Description of problem: zsh in ksh emulation mode, coredumps when trying to check the syntax of a shell script Version-Release number of selected component (if applicable): RHEL7: zsh-5.0.2-7.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1 Create test script: $ cat <<EOF > test1.ksh #!/usr/bin/ksh echo $HOME EOF or $ cat <<EOF > test2.ksh #!/usr/bin/ksh V=$HOME EOF $ cat <<EOF > test3.ksh #!/usr/bin/ksh export V=${HOME} EOF 2 Test syntax $ ksh -n test1.ksh $ ksh -n test2.ksh Actual results: zsh coredumps, in both occurences Expected results: exit cleanly, with code 0 or 1, depending on validity of the given script Additional info: Some variations of using the HOME env variable are ok: D=${HOME} or D=$HOME, for example This issue is similar to bz#1222867, but the fix for that issue doesn't fix this one. $ which ksh /usr/bin/ksh $ ls -l ksh lrwxrwxrwx. 1 root root 3 May 19 11:55 ksh -> zsh
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