A weird bug

A weird bug

[Alexandre Duret-Lutz]

While trying to zcompile all of my completion functions, I got a segfault.
Looking closer, I discovered there was a .rej in the files, and that
zcompile segfaulted on this file.

I don't expect zsh to know what to do with a .rej file, of course.  Garbage
in garbage out rule. But a segfault is not reasonable garbage...

I tried to strip the file the most I could, but I'm afraid it is still a
bit long.  If I remove some lines or tokens from the file `file.bug' used
below, Zsh doesn't segfault anymore (I get a syntax error).

% zsh -f
phobos% cat file.bug
***************
*** 1,27 ****
-
- setopt localoptions nullglob
-
- local -U d
- local i j e m f n
- local p
- local m
-
- if (( ! $+_m )) then
-
-   typeset -U -g _m
-   typeset -U -g _m _m _m _m _p
-
-   _m=()
-   _m=()
-   _m=()
-   _m=()
-   _m=()
-   _p=()
    [[ -f $v ]] && _m=()
--- 1,69 ----
+ _m() {
+
+   local e n
+   local p
+   local m
+   if (( ! $+_m )) then
+     _m "$@"
+   fi
+   case "${c}" in
+     (*:m:*)
+       if [[ "$P" == +* ]]; then
+       _t m
phobos% zcompile foo file.bug
zsh: segmentation fault (core dumped)  zsh -f

#0  0x808f37b in ecstrcode (s=0x40016160 "\231\212P\231")
    at ../../latest/Src/parse.c:306
306                 if (p->nfunc == ecnfunc && !strcmp(s, p->str))
(gdb) p p
$1 = (struct eccstr *) 0x15a
(gdb) bt
#0  0x808f37b in ecstrcode (s=0x40016160 "\231\212P\231")
    at ../../latest/Src/parse.c:306
#1  0x808f461 in ecstr (s=0x40016160 "\231\212P\231")
    at ../../latest/Src/parse.c:327
#2  0x809296c in par_simple (complex=0xbfffeb50, nr=0)
    at ../../latest/Src/parse.c:1444
#3  0x80908f7 in par_cmd (complex=0xbfffeb50) at ../../latest/Src/parse.c:802
#4  0x808ff38 in par_pline (complex=0xbfffeb50) at ../../latest/Src/parse.c:666
#5  0x808fee7 in par_sublist2 (complex=0xbfffeb50)
    at ../../latest/Src/parse.c:648
#6  0x808fd0f in par_sublist (complex=0xbfffeb90)
    at ../../latest/Src/parse.c:603
#7  0x808fb4c in par_list (complex=0xbfffebd0) at ../../latest/Src/parse.c:548
#8  0x8092aed in par_simple (complex=0xbfffecd0, nr=0)
    at ../../latest/Src/parse.c:1478
#9  0x80908f7 in par_cmd (complex=0xbfffecd0) at ../../latest/Src/parse.c:802
#10 0x808ff38 in par_pline (complex=0xbfffecd0) at ../../latest/Src/parse.c:666
#11 0x808fee7 in par_sublist2 (complex=0xbfffecd0)
    at ../../latest/Src/parse.c:648
#12 0x808fd0f in par_sublist (complex=0xbfffed10)
    at ../../latest/Src/parse.c:603
#13 0x808fb4c in par_list (complex=0xbfffed48) at ../../latest/Src/parse.c:548
#14 0x808f8cf in parse_list () at ../../latest/Src/parse.c:475
#15 0x805c8cd in parse_string (
    s=0x80eba20 '*' <repeats 15 times>, "\n*** 1,27 ****\n- \n- setopt localoptions nullglob\n-\n- local -U d\n- local i j e m f n\n- local p\n- local m\n- \n- if (( ! $+_m )) then\n- \n-   typeset -U -g _m\n-   typeset -U -g _m _m _m _m _"..., ln=1) at ../../latest/Src/exec.c:158
#16 0x8094b67 in build_dump (nam=0x40014750 "zcompile", 
    dump=0x40014780 "foo.zwc", files=0xbfffee78, ali=0, map=1)
    at ../../latest/Src/parse.c:2401
#17 0x80946ea in bin_zcompile (nam=0x40014750 "zcompile", args=0xbfffee74, 
    ops=0xbfffeed8 "", func=0) at ../../latest/Src/parse.c:2283
#18 0x8052008 in execbuiltin (args=0x40014720, bn=0x80b7144)
    at ../../latest/Src/builtin.c:368
#19 0x8062630 in execcmd (state=0xbffff1b0, input=0, output=0, how=18, last1=2)
    at ../../latest/Src/exec.c:2244
#20 0x805f19b in execpline2 (state=0xbffff1b0, pcode=195, how=18, input=0, 
    output=0, last1=0) at ../../latest/Src/exec.c:1172
#21 0x805e709 in execpline (state=0xbffff1b0, slcode=5122, how=18, last1=0)
    at ../../latest/Src/exec.c:965
#22 0x805e129 in execlist (state=0xbffff1b0, dont_change_job=0, exiting=0)
    at ../../latest/Src/exec.c:812
#23 0x805de56 in execode (p=0x400146c0, dont_change_job=0, exiting=0)
    at ../../latest/Src/exec.c:721
#24 0x8072995 in loop (toplevel=1, justonce=0) at ../../latest/Src/init.c:144
#25 0x80515a2 in main (argc=2, argv=0xbffff2a4) at ../../latest/Src/main.c:86


-- 
Alexandre Duret-Lutz

Re: A weird bug

[Bart Schaefer]

On Mar 6,  7:03pm, Alexandre Duret-Lutz wrote:
} Subject: A weird bug
}
} phobos% zcompile foo file.bug
} zsh: segmentation fault (core dumped)  zsh -f

This looks to be a parser bug, not a compilation bug.  Try

    fpath=($PWD)
    autoload +X file.bug

and you'll get the same crash.  The problem is that ecadd() is running
over the end of ecbuf[], apparently because of an off-by-one error in
the value of ecfree.  But there are so many places in parse.c where
ecused is modified (usually decremented, but incremented in ecispace())
without also modifying ecfree that I'm not sure what the relationship
between the two is supposed to be.

I discovered this by setting watchpoints in gdb.  I attempted to use
ElectricFence, but it's nearly useless for zsh because of the heap; it
can't see overruns that are inside the large heap spaces that zsh pre-
allocates.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com