segfault on menu-select

segfault on menu-select

[Philipp Hartwig]

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

Hi,

I'm using the latest zsh from Debian which has the version number 
4.3.10-15, but I was able to reproduce the following behavior with the 
zsh 4.3.10 built from the official sources.

I have the line following line in my .zshrc:
> bindkey '^o' menu-select
The following sequence of keys will make zsh crash, provided that 
"gre<tab>" completes to "grep " on your system:
$ gre<tab><ctrl-o>

In /var/log/syslog I find the following lines after the crash:
> Aug 12 16:20:55 ph kernel: [228053.669743] zsh[14263]: segfault at 20 ip 00007fcba8135b92 sp 00007fff9c3402d8 error 4 in libc-2.11.2.so[7fcba80ba000+158000]
> Aug 12 16:21:01 ph /USR/SBIN/CRON[14357]: (ph) CMD (/home/ph/bin/checkoffline)
> Aug 12 16:21:01 ph /USR/SBIN/CRON[14356]: (ph) CMD (/home/ph/bin/checkmsmtp)
> Aug 12 16:21:36 ph kernel: [228094.527543] zsh[14864]: segfault at 1c ip 00007f507ce609dc sp 00007fff1b97c630 error 4 in complete.so[7f507ce4c000+23000]

I'd love to be of further assistance in tracking down what is going on 
in case the information I provided is not sufficient.

Best,
Philipp

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: segfault on menu-select

[Frank Terbeck]

Philipp Hartwig wrote:
> I'm using the latest zsh from Debian which has the version number 
> 4.3.10-15, but I was able to reproduce the following behavior with the 
> zsh 4.3.10 built from the official sources.
>
> I have the line following line in my .zshrc:
>> bindkey '^o' menu-select
> The following sequence of keys will make zsh crash, provided that 
> "gre<tab>" completes to "grep " on your system:
> $ gre<tab><ctrl-o>
[...]
> I'd love to be of further assistance in tracking down what is going on 
> in case the information I provided is not sufficient.

Can you reproduce this using CVS HEAD? Because I cannot from zsh -f and

zsh% autoload -Uz compinit
zsh% compinit
zsh% bindkey '^o' menu-complete
zsh% gre<tab><C-o>

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: segfault on menu-select

[Philipp Hartwig]

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

> Can you reproduce this using CVS HEAD? Because I cannot from zsh -f and
> 
> zsh% autoload -Uz compinit
> zsh% compinit
> zsh% bindkey '^o' menu-complete
> zsh% gre<tab><C-o>

The error occurs with menu-select, not menu-complete. I can reproduce it 
with the following .zshrc:

autoload -Uz compinit
compinit
zmodload -i zsh/complist
bindkey '^o' menu-select

Strangely enough I can NOT reproduce it with 
zsh -f
source .zshrc

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: segfault on menu-select

[Frank Terbeck]

Philipp Hartwig wrote:
> The error occurs with menu-select, not menu-complete. I can reproduce it 

Oops, sorry.

> with the following .zshrc:
>
> autoload -Uz compinit
> compinit
> zmodload -i zsh/complist
> bindkey '^o' menu-select
>
> Strangely enough I can NOT reproduce it with 
> zsh -f
> source .zshrc

Still. Can you reproduce this with CVS HEAD?

I cannot. Not with those lines as the only .zshrc and not with zsh -f
and "source .zshrc". There may be something in the global config files
on your system, that play a role... But then, if the issue is already
fixed in CVS, then we're wasting time here. :)

If it's reproducible with CVS HEAD, it would be good to create a debug
build and fetch a back trace from the core file.

Regards, Frank

Re: segfault on menu-select

[Philipp Hartwig]

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

> Still. Can you reproduce this with CVS HEAD?

Building this was not so easy. Installing the man pages (and hence a 
normal make install) still fails, but make, make check, make 
install.bin, make install.modules were successful and yes, I can 
reproduce the issue. Still not with zsh -f of course, but with the 
minimal .zshrc from before.

> If it's reproducible with CVS HEAD, it would be good to create a debug
> build and fetch a back trace from the core file.

Sorry, I don't know what that means but I'll be happy to follow any 
instructions.

Best,
Philipp

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: segfault on menu-select

[Frank Terbeck]

Philipp Hartwig wrote:
>> Still. Can you reproduce this with CVS HEAD?
>
> Building this was not so easy. Installing the man pages (and hence a
> normal make install) still fails, but make, make check, make
> install.bin, make install.modules were successful and yes, I can
> reproduce the issue. Still not with zsh -f of course, but with the
> minimal .zshrc from before.

To generate the manuals, you need the `yodl' package.

>> If it's reproducible with CVS HEAD, it would be good to create a debug
>> build and fetch a back trace from the core file.
>
> Sorry, I don't know what that means but I'll be happy to follow any
> instructions.

>From a fresh checkout, here's what I usually do:

% ./Util/preconfig
% /configure  --enable-cap --enable-function-subdirs \
              --enable-largefile --enable-maildir-support \
              --enable-multibyte --enable-pcre --enable-zsh-debug
% make
% su
# make install

Then when you've crashed the application, you can load the core file
together with the program's binary and use the "bt full" command to
produce a backtrace.

To put the backtrace to a file, the following oneliner works:

% gdb -c core /usr/local/bin/zsh <<< $'bt full\nquit\n' > backtrace.txt

Where `core' is the core file and `/usr/local/bin/zsh' being the
installed zsh binary which you just crashed.

The backtrace will only be useful if the zsh binary is from a debugging
build.

Regards, Frank

Re: segfault on menu-select

[Philipp Hartwig]

[-- Attachment #1.1: Type: text/plain, Size: 1224 bytes --]

> To generate the manuals, you need the `yodl' package.

I had installed this because even "make" failed without it, but "make 
install" still wouldn't work afterwards. On a new checkout it however 
does, so never mind.
 
> From a fresh checkout, here's what I usually do:
> 
> % ./Util/preconfig
> % /configure  --enable-cap --enable-function-subdirs \
>               --enable-largefile --enable-maildir-support \
>               --enable-multibyte --enable-pcre --enable-zsh-debug
> % make
> % su
> # make install
> 
> Then when you've crashed the application, you can load the core file
> together with the program's binary and use the "bt full" command to
> produce a backtrace.
> 
> To put the backtrace to a file, the following oneliner works:
> 
> % gdb -c core /usr/local/bin/zsh <<< $'bt full\nquit\n' > backtrace.txt
> 
> Where `core' is the core file and `/usr/local/bin/zsh' being the
> installed zsh binary which you just crashed.
> 
> The backtrace will only be useful if the zsh binary is from a debugging
> build.

Ok, apart from a "warning: Can't read pathname for load map: 
Input/output error." it looks like this has worked. I've attached the 
result.

Best,
Philipp

[-- Attachment #1.2: backtrace.txt --]
[-- Type: text/plain, Size: 6442 bytes --]

GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/zsh...done.
Reading symbols from /lib/libpcre.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib/libpcre.so.3
Reading symbols from /lib/libcap.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libcap.so.2
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libncursesw.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libncursesw.so.5
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libattr.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libattr.so.1
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib/libnss_compat.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/local/lib/zsh/4.3.10-dev-2/zsh/parameter.so...done.
Loaded symbols for /usr/local/lib/zsh/4.3.10-dev-2/zsh/parameter.so
Reading symbols from /usr/local/lib/zsh/4.3.10-dev-2/zsh/zle.so...done.
Loaded symbols for /usr/local/lib/zsh/4.3.10-dev-2/zsh/zle.so
Reading symbols from /usr/local/lib/zsh/4.3.10-dev-2/zsh/complete.so...done.
Loaded symbols for /usr/local/lib/zsh/4.3.10-dev-2/zsh/complete.so
Reading symbols from /usr/local/lib/zsh/4.3.10-dev-2/zsh/zutil.so...done.
Loaded symbols for /usr/local/lib/zsh/4.3.10-dev-2/zsh/zutil.so
Reading symbols from /usr/local/lib/zsh/4.3.10-dev-2/zsh/complist.so...done.
Loaded symbols for /usr/local/lib/zsh/4.3.10-dev-2/zsh/complist.so
Reading symbols from /usr/local/lib/zsh/4.3.10-dev-2/zsh/computil.so...done.
Loaded symbols for /usr/local/lib/zsh/4.3.10-dev-2/zsh/computil.so
Core was generated by `zsh'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f5cb77a3b92 in ?? () from /lib/libc.so.6
(gdb) #0  0x00007f5cb77a3b92 in ?? () from /lib/libc.so.6
No symbol table info available.
#1  0x00007f5cb63b76eb in instmatch (m=0x1776660, scs=0x7fff5707cf2c) at compresult.c:634
        l = 4
        r = 14
        ocs = 19
        a = 5
        brb = 0
        bradd = 0
        brpos = 0x7fff5707ce50
        bp = 0x7f5cb65fd7ac
#2  0x00007f5cb63b87bb in do_single (m=0x1776660) at compresult.c:989
        l = 0
        sr = 0
        scs = 0
        havesuff = 0
        partest = 1
        str = 0x5d8 <Address 0x5d8 out of bounds>
        ppre = 0x7f5cb7a84e98 "p\001\202\001"
        psuf = 0x9 <Address 0x9 out of bounds>
        prpre = 0x21 <Address 0x21 out of bounds>
#3  0x00007f5cb63a3616 in do_completion (dummy=0x7f5cb6810f68, dat=0x7fff5707d060) at compcore.c:413
        m = 0x1811e50
        ret = 0
        lst = 0
        incmd = 0
        osl = 0
        s = 0x1812140 ""
        opm = 0x1776700 ""
        n = 0x7f5cb7a84e40
#4  0x00000000004632a9 in runhookdef (h=0x7f5cb6810f68, d=0x7fff5707d060) at module.c:996
No locals.
#5  0x00007f5cb65fa1d5 in docompletion (s=0x1812140 "", lst=0, incmd=0) at zle_tricky.c:2179
        dat = {s = 0x1812140 "", lst = 0, incmd = 0}
#6  0x00007f5cb65f5a00 in docomplete (lst=0) at zle_tricky.c:859
        active = 1
        s = 0x1812140 ""
        ol = 0x0
        olst = 0
        chl = 0
        ne = 0
        ocs = 5
        ret = 0
        dat = {0, 0}
#7  0x00007f5cb65f3e54 in menucomplete (args=0x7f5cb68114c8) at zle_tricky.c:247
No locals.
#8  0x00007f5cb5f8a63d in menuselect (args=0x7f5cb68114c8) at complist.c:3378
        d = 0
#9  0x00007f5cb65e221f in execzlefunc (func=0x178d4d0, args=0x7f5cb68114c8, set_bindk=0) at zle_main.c:1333
        wflags = 645
        r = 0
        ret = 0
        remetafy = 0
        w = 0x178d470
        save_bindk = 0x178d4d0
#10 0x00007f5cb65e15c4 in zlecore () at zle_main.c:1058
No locals.
#11 0x00007f5cb65e1d32 in zleread (lp=0x6d6358, rp=0x0, flags=3, context=0) at zle_main.c:1227
        s = 0x0
        old_errno = 22
        tmout = 0
        initthingy = 0x0
#12 0x00007f5cb65e4821 in zle_main_entry (cmd=1, ap=0x7fff5707d510) at zle_main.c:1889
        lp = 0x6d6358
        rp = 0x0
        flags = 3
        context = 0
#13 0x000000000044be61 in zleentry (cmd=1) at init.c:1354
        ret = 0x0
        ap = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7fff5707d610, 
            reg_save_area = 0x7fff5707d550}}
#14 0x000000000044c8c1 in inputline () at input.c:281
        flags = 3
        ingetcline = 0x0
        ingetcpmptl = 0x6d6358
        ingetcpmptr = 0x0
        context = 0
#15 0x000000000044c738 in ingetc () at input.c:217
        lastc = 0
#16 0x0000000000441180 in ihgetc () at hist.c:279
        c = 0
#17 0x0000000000456375 in gettok () at lex.c:694
        c = 0
        d = 0
        peekfd = -1
        peek = 0
#18 0x0000000000455b3e in zshlex () at lex.c:381
No locals.
#19 0x0000000000477203 in parse_event () at parse.c:451
No locals.
#20 0x0000000000448f01 in loop (toplevel=1, justonce=0) at init.c:132
        prog = 0x1771420
        err = 1000
        non_empty = 0
#21 0x000000000044c32d in zsh_main (argc=1, argv=0x7fff5707d8d8) at init.c:1508
        t = 0x7fff5707d8e0
        runscript = 0x0
        t0 = 158
#22 0x000000000040ff44 in main (argc=1, argv=0x7fff5707d8d8) at ./main.c:93
No locals.
(gdb) 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: segfault on menu-select

[Frank Terbeck]

Philipp Hartwig wrote:
[...]
>> To put the backtrace to a file, the following oneliner works:
>> 
>> % gdb -c core /usr/local/bin/zsh <<< $'bt full\nquit\n' > backtrace.txt
>> 
[...]
> Ok, apart from a "warning: Can't read pathname for load map: 
> Input/output error." it looks like this has worked. I've attached the 
> result.

Thanks.
I've tried following the trace but frankly, I know next to nothing about
the code in compcore.c, compresult.c and zle_tricky.c.

I'm sure somebody else will pitch in when they find the time.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: segfault on menu-select

[Bart Schaefer]

On Aug 12,  7:33pm, Philipp Hartwig wrote:
}
} #1  0x00007f5cb63b76eb in instmatch (m=0x1776660, scs=0x7fff5707cf2c) at compresult.c:634
} #2  0x00007f5cb63b87bb in do_single (m=0x1776660) at compresult.c:989
} #3  0x00007f5cb63a3616 in do_completion (dummy=0x7f5cb6810f68, dat=0x7fff5707d060) at compcore.c:413
} #4  0x00000000004632a9 in runhookdef (h=0x7f5cb6810f68, d=0x7fff5707d060) at module.c:996

Interesting.  I can't even reproduce that stack trace.  If I put a
breakpoint in instmatch I get this trace:

#0  instmatch (m=0x8211d18, scs=0xbfebb2c4)
    at ../../../zsh-4.0/Src/Zle/compresult.c:580
#1  0x081032b3 in do_single (m=0x8211d18)
    at ../../../zsh-4.0/Src/Zle/compresult.c:989
#2  0x081041c6 in do_ambig_menu ()
    at ../../../zsh-4.0/Src/Zle/compresult.c:1404
#3  0x08102b1f in do_ambiguous () at ../../../zsh-4.0/Src/Zle/compresult.c:767
#4  0x080f31b3 in do_completion (dummy=0x815f8b4, dat=0xbfebb3d0)
    at ../../../zsh-4.0/Src/Zle/compcore.c:401
#5  0x080914da in runhookdef (h=0x815f8b4, d=0xbfebb3d0)
    at ../../zsh-4.0/Src/module.c:996

So that means you've hit this branch in compcore.c:

        } else if (nmatches == 1 || (nmatches > 1 && !diffmatches)) {

So I can force my shell through that same branch by hitting ^o in a
directory containing exactly one file, but I still don't get a crash.

What does "ls" show just before you begin completing?

-- 

Re: segfault on menu-select

[Philipp Hartwig]

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

> So I can force my shell through that same branch by hitting ^o in a
> directory containing exactly one file, but I still don't get a crash.
> 
> What does "ls" show just before you begin completing?

It's independent of that, it also works in an empty directory as I've 
just checked.

Note that in order to reproduce the issue it really seems to be 
necessary to have the 4 lines

autoload -Uz compinit
compinit
zmodload -i zsh/complist
bindkey '^o' menu-select

in your .zshrc. Just typing them or sourcing a file containing them will 
not lead to the crash in my case, even without the "-f" option. Instead 
I get a browsable list of all the files in the directory as it is 
supposed to be.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: segfault on menu-select

[Bart Schaefer]

On Aug 13, 10:08am, Philipp Hartwig wrote:
}
} Note that in order to reproduce the issue it really seems to be 
} necessary to have the 4 lines
} 
} autoload -Uz compinit
} compinit
} zmodload -i zsh/complist
} bindkey '^o' menu-select
} 
} in your .zshrc. Just typing them or sourcing a file containing them will 
} not lead to the crash in my case, even without the "-f" option.

Hmm, indeed.  I'm finally able to reproduce this.  It's also necessary to
have invoked completion once before trying menu-select, just hitting ^o
won't do it (in fact, won't do *anything*, which is slightly suspicious).

The more direct symptom is that there's garbage in minfo.group->matches
("minfo" is a global).  I tried putting a watchpoint on minfo.group but
because matches is a pointer that's not very helpful; all I determined
is that it's last assigned here:

Hardware watchpoint 1: minfo.group

Old value = 0x8853ea8
New value = 0x8872690
0x08103002 in do_allmatches (end=0)
    at ../../../zsh-4.0/Src/Zle/compresult.c:902
902         for (minfo.group = amatches;

At which point the contents of ->matches look like this:

(gdb) p m
$6 = 0x8d1efa8
(gdb) p *m
$7 = {str = 0x0, orig = 0x21 <Address 0x21 out of bounds>, 
  ipre = 0x886fcf8 "", 
  ripre = 0x8b6870 "(·Ô\b@\031\205\b¨ïÑ\b\230\032\207\b
ÔÔ\b\210õ\206\b \211Ò\b eÏ\b mÔ\b0ûÑ\b8oÏ\b(nÏ\b°éÒ\bhÆÓ\b@`Ô\b@`Ô\b¨<\205\b¨<\205\b\b|\206\b¸Â\204\b¸h\213",
isuf = 0x5f73756f <Address 0x5f73756f out of bounds>, 
  ppre = 0x69736f70 <Address 0x69736f70 out of bounds>, 
  psuf = 0x6e6f6974 <Address 0x6e6f6974 out of bounds>, prpre = 0x8d10073 "", 
  pre = 0x20 <Address 0x20 out of bounds>, 
  suf = 0x10 <Address 0x10 out of bounds>, 
  disp = 0x6d75645f <Address 0x6d75645f out of bounds>, 
  autoq = 0x6d646170 <Address 0x6d646170 out of bounds>, flags = 0, 
  brpl = 0x19, brsl = 0x0, rems = 0x8d23720 "dmeventd", remf = 0x0, 
  qipl = 142976480, qisl = 0, rnum = 17, gnum = 7173740, mode = 9136216, 
  modec = 0 '\0', fmode = 25, fmodec = -112 '\220'}

However, the crash doesn't always happen that deep in the call stack;
having the hardware watchpoint present changes the behavior a bit, so I
suspect *amatches has already been messed up for a while at this point.

Unfortunately I'm out of time to poke at it just now.

-- 

Re: segfault on menu-select

[Peter Stephenson]

On Fri, 13 Aug 2010 08:57:08 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Aug 13, 10:08am, Philipp Hartwig wrote:
> }
> } Note that in order to reproduce the issue it really seems to be 
> } necessary to have the 4 lines
> } 
> } autoload -Uz compinit
> } compinit
> } zmodload -i zsh/complist
> } bindkey '^o' menu-select
> } 
> } in your .zshrc. Just typing them or sourcing a file containing them will 
> } not lead to the crash in my case, even without the "-f" option.
> 
> Hmm, indeed.  I'm finally able to reproduce this.  It's also necessary to
> have invoked completion once before trying menu-select, just hitting ^o
> won't do it (in fact, won't do *anything*, which is slightly suspicious).

Check.

I won't tell you what valgrind said, it was really quite rude.  That and
the core dumps I got seemed to point the finger at amatches.

It's not this simple, is it?  It's a little difficult to see how this
could be wrong, but this is the completion system we're talking about.

Index: Src/Zle/compresult.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compresult.c,v
retrieving revision 1.78
diff -p -u -r1.78 compresult.c
--- Src/Zle/compresult.c	24 Apr 2009 09:00:38 -0000	1.78
+++ Src/Zle/compresult.c	13 Aug 2010 20:38:07 -0000
@@ -2284,6 +2284,8 @@ invalidate_list(void)
     zsfree(minfo.postbr);
     minfo.postbr = minfo.prebr = NULL;
     compwidget = NULL;
+    nmatches = 0;
+    amatches = NULL;
 
     return 0;
 }

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: segfault on menu-select

[Bart Schaefer]

On Aug 13,  9:43pm, Peter Stephenson wrote:
}
} I won't tell you what valgrind said, it was really quite rude.  That and
} the core dumps I got seemed to point the finger at amatches.

Yes ... but I think it's indirect, something stored in *amatches rather
than amatches itself.

} It's not this simple, is it?  It's a little difficult to see how this
} could be wrong, but this is the completion system we're talking about.

I agree there doesn't appear to be anything wrong with that patch, but it
also doesn't quite fix things.  I no longer get a reproducible core dump,
but now menu-select is a silent no-op.  (The minimal zshrc used so far is
still necessary to reproduce anything, as soon as I use my full startup I
get normal menu selection.)

Re: segfault on menu-select

[Bart Schaefer]

On Aug 15,  1:43pm, Bart Schaefer wrote:
}
} I agree there doesn't appear to be anything wrong with that patch, but it
} also doesn't quite fix things.  I no longer get a reproducible core dump,
} but now menu-select is a silent no-op.  (The minimal zshrc used so far is
} still necessary to reproduce anything, as soon as I use my full startup I
} get normal menu selection.)

The difference seems to be whether the zsh/compctl module is loaded.  I
don't immediately know why zsh/compctl would be necessary for proper
execution of menu-select, but if I add

zmodload zsh/compctl

to the minimal zshrc, I am no longer able to force a crash.  I tried with
zsh 4.3.9 as well, and I can crash it if compctl is not loaded, but not
when compctl is loaded.

Re: segfault on menu-select

[Philipp Hartwig]

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

> The difference seems to be whether the zsh/compctl module is loaded.  I
> don't immediately know why zsh/compctl would be necessary for proper
> execution of menu-select, but if I add
> 
> zmodload zsh/compctl
> 
> to the minimal zshrc, I am no longer able to force a crash.  I tried with
> zsh 4.3.9 as well, and I can crash it if compctl is not loaded, but not
> when compctl is loaded.

I also do not experience any more crashes since adding

zmodload zsh/compctl

to my .zshrc. Unfortunately this breaks the menu-select feature in some 
cases.

For example with this .zshrc

autoload -Uz compinit
compinit
zmodload -i zsh/complist
#zmodload zsh/compctl
zstyle ':completion:*' matcher-list 'm:{a-z}={A-Z}' 'r:|[._-]=* r:|=*' 'l:|=* r:|=*'
bindkey '^o' menu-select

and a folder 

ph% ls
baz-foo  test-foo

doing

ph% vi foo<tab><tab><ctrl-o>

will work out nice and give me the desired menu-selection (or crash).  
But if I comment in the line in the .zshrc above, no menu-select will 
take place anymore.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: segfault on menu-select

[Bart Schaefer]

On Aug 31,  4:33pm, Philipp Hartwig wrote:
} Subject: Re: segfault on menu-select
}
} > The difference seems to be whether the zsh/compctl module is loaded.  I
} > don't immediately know why zsh/compctl would be necessary for proper
} > execution of menu-select, but if I add
} > 
} > zmodload zsh/compctl
} > 
} > to the minimal zshrc, I am no longer able to force a crash.

Hmm, and hmm again.  (Yes, I'm hmm-ing at my own previous remarks.)

} I also do not experience any more crashes since adding
} 
} zmodload zsh/compctl
} 
} to my .zshrc. Unfortunately this breaks the menu-select feature in some 
} cases.

I've been fooling with this a bit, and it's not broken; the best I can
describe it is to say it's just not ready to start yet.

} [in a directory with files baz-foo and test-foo and compctl not loaded]
} 
} ph% vi foo<tab><tab><ctrl-o>
} 
} will work out nice and give me the desired menu-selection (or crash).  
} But if I [zmodload zsh/compctl as well], no menu-select will 
} take place anymore.

I can reproduce this.  However, menu-select will take place for me if I
simply add one more TAB:

torch% vi foo<tab><tab><tab><ctrl-o>

This comes down to the code passing through the "else" branch at lines
1013 - 1025 of Src/Zle/compcore.c -- with compctl not loaded, dat.lst
is 0 after runhookdef(COMPCTLMAKEHOOK, ...), but with compctl loaded
dat.list becomes nonzero if we have not made a third attempt to allow
compctl to perform default completion of -foo.

Now, what this has to do with the crash (not) happening after we have
passed (or not) through the compctl hooks, I still don't follow.

Re: segfault on menu-select

[Philipp Hartwig]

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

Hello,

I've just upgraded to 4.3.11 and I'm not able to reproduce this anymore.  
This is really great news for me as I still used to run into this bug 
several times a day and as it feels really weird to use a login shell 
which crashes all the time... (Loading zsh/compctl was not really an 
option for me as it broke parts of the feature.)

Has the bug been identified and removed or is this just a happy 
side-effect of other changes?

Thanks a lot in any case, I really hope I won't run into this problem 
again.

Best,
Philipp

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4611 bytes --]

Re: segfault on menu-select

[Bart Schaefer]

On Jan 9,  7:56pm, Philipp Hartwig wrote:
}
} I've just upgraded to 4.3.11 and I'm not able to reproduce this anymore.  
} Has the bug been identified and removed or is this just a happy 
} side-effect of other changes?

The crash was fixed by PWS in workers/28167.  However, as far as I can
tell the remaining (non-crashing) bug described in workers/28232 and its
references, was never further addressed; the thread ends there.

Re: segfault on menu-select

[Philipp Hartwig]

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

On Sun, Jan 09, 2011 at 11:54:10AM -0800, Bart Schaefer wrote:
> The crash was fixed by PWS in workers/28167.  

Oh, I see. I had always taken your comment in workers/28169 to mean that 
the patch from workers/28167 was not the solution yet. Obviously I've 
misunderstood the discussion.

> However, as far as I can tell the remaining (non-crashing) bug
> described in workers/28232 and its references, was never further
> addressed; the thread ends there.

True, I had not checked whether that one still exists in 4.3.11 (it 
does). Anyway, at least if compctl is not loaded menu-select seems to 
work perfectly now (which is the case in my setup).

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4611 bytes --]

Re: segfault on menu-select

[Bart Schaefer]

On Aug 12,  4:53pm, Frank Terbeck wrote:
} Subject: Re: segfault on menu-select
}
} Philipp Hartwig wrote:
} > I have the line following line in my .zshrc:
} >> bindkey '^o' menu-select
} > The following sequence of keys will make zsh crash, provided that 
} > "gre<tab>" completes to "grep " on your system:
} > $ gre<tab><ctrl-o>
} [...]
} > I'd love to be of further assistance in tracking down what is going on 
} > in case the information I provided is not sufficient.
} 
} Can you reproduce this using CVS HEAD? Because I cannot from zsh -f

I can't reproduce either, which makes me suspect it has something to do
with either multibyte character sets (Philipp, what's your $LANG ?) or
a specific zstyle.

At that point in completion _grep "knows" that a pattern is expected
and does nothing unless you have configured your styles to display the
explanation:

schaefer<504> grep
Completing pattern

which comes from my style

zstyle ':completion:*' format '%SCompleting %U%d%u%s'

Philipp, do you use anything like that?

-- 

Re: segfault on menu-select

[Philipp Hartwig]

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

> I can't reproduce either, which makes me suspect it has something to do
> with either multibyte character sets (Philipp, what's your $LANG ?) or
> a specific zstyle.

I have LANG=en_US.UTF-8
 
> [...]
> zstyle ':completion:*' format '%SCompleting %U%d%u%s'
>
> Philipp, do you use anything like that?

The .zshrc I use to reproduce this is

autoload -Uz compinit
compinit
zmodload -i zsh/complist
bindkey '^o' menu-select

I've just purged my Debian zsh so that there are no global config files 
left in /etc/zsh. Therefore I don't think any zstyle like this is active.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]