* segfault on menu-select @ 2010-08-12 14:46 Philipp Hartwig 2010-08-12 14:53 ` Frank Terbeck 0 siblings, 1 reply; 21+ messages in thread From: Philipp Hartwig @ 2010-08-12 14:46 UTC (permalink / raw) To: zsh-workers [-- 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 --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2010-08-12 14:46 segfault on menu-select Philipp Hartwig @ 2010-08-12 14:53 ` Frank Terbeck 2010-08-12 15:20 ` Philipp Hartwig 2010-08-12 16:04 ` Bart Schaefer 0 siblings, 2 replies; 21+ messages in thread From: Frank Terbeck @ 2010-08-12 14:53 UTC (permalink / raw) To: Philipp Hartwig; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2010-08-12 14:53 ` Frank Terbeck @ 2010-08-12 15:20 ` Philipp Hartwig 2010-08-12 15:49 ` Frank Terbeck 2010-08-12 16:04 ` Bart Schaefer 1 sibling, 1 reply; 21+ messages in thread From: Philipp Hartwig @ 2010-08-12 15:20 UTC (permalink / raw) To: Frank Terbeck; +Cc: zsh-workers [-- 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 --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2010-08-12 15:20 ` Philipp Hartwig @ 2010-08-12 15:49 ` Frank Terbeck 2010-08-12 16:53 ` Philipp Hartwig 0 siblings, 1 reply; 21+ messages in thread From: Frank Terbeck @ 2010-08-12 15:49 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2010-08-12 15:49 ` Frank Terbeck @ 2010-08-12 16:53 ` Philipp Hartwig 2010-08-12 17:07 ` Frank Terbeck 0 siblings, 1 reply; 21+ messages in thread From: Philipp Hartwig @ 2010-08-12 16:53 UTC (permalink / raw) To: Frank Terbeck; +Cc: zsh-workers [-- 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 --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2010-08-12 16:53 ` Philipp Hartwig @ 2010-08-12 17:07 ` Frank Terbeck 2010-08-12 17:33 ` Philipp Hartwig 0 siblings, 1 reply; 21+ messages in thread From: Frank Terbeck @ 2010-08-12 17:07 UTC (permalink / raw) To: Philipp Hartwig; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2010-08-12 17:07 ` Frank Terbeck @ 2010-08-12 17:33 ` Philipp Hartwig 2010-08-12 18:04 ` Frank Terbeck 2010-08-12 23:07 ` Bart Schaefer 0 siblings, 2 replies; 21+ messages in thread From: Philipp Hartwig @ 2010-08-12 17:33 UTC (permalink / raw) To: Frank Terbeck; +Cc: zsh-workers [-- 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 --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2010-08-12 17:33 ` Philipp Hartwig @ 2010-08-12 18:04 ` Frank Terbeck 2010-08-12 23:07 ` Bart Schaefer 1 sibling, 0 replies; 21+ messages in thread From: Frank Terbeck @ 2010-08-12 18:04 UTC (permalink / raw) To: Philipp Hartwig; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2010-08-12 17:33 ` Philipp Hartwig 2010-08-12 18:04 ` Frank Terbeck @ 2010-08-12 23:07 ` Bart Schaefer 2010-08-13 8:08 ` Philipp Hartwig 1 sibling, 1 reply; 21+ messages in thread From: Bart Schaefer @ 2010-08-12 23:07 UTC (permalink / raw) To: zsh-workers 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? -- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2010-08-12 23:07 ` Bart Schaefer @ 2010-08-13 8:08 ` Philipp Hartwig 2010-08-13 15:57 ` Bart Schaefer 0 siblings, 1 reply; 21+ messages in thread From: Philipp Hartwig @ 2010-08-13 8:08 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers mailing list [-- 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 --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2010-08-13 8:08 ` Philipp Hartwig @ 2010-08-13 15:57 ` Bart Schaefer 2010-08-13 20:43 ` Peter Stephenson 0 siblings, 1 reply; 21+ messages in thread From: Bart Schaefer @ 2010-08-13 15:57 UTC (permalink / raw) To: zsh-workers mailing list 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. -- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2010-08-13 15:57 ` Bart Schaefer @ 2010-08-13 20:43 ` Peter Stephenson 2010-08-15 20:43 ` Bart Schaefer 0 siblings, 1 reply; 21+ messages in thread From: Peter Stephenson @ 2010-08-13 20:43 UTC (permalink / raw) To: zsh-workers mailing list 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/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2010-08-13 20:43 ` Peter Stephenson @ 2010-08-15 20:43 ` Bart Schaefer 2010-08-15 22:34 ` Bart Schaefer 0 siblings, 1 reply; 21+ messages in thread From: Bart Schaefer @ 2010-08-15 20:43 UTC (permalink / raw) To: zsh-workers mailing list 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.) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2010-08-15 20:43 ` Bart Schaefer @ 2010-08-15 22:34 ` Bart Schaefer 2010-08-31 14:33 ` Philipp Hartwig 0 siblings, 1 reply; 21+ messages in thread From: Bart Schaefer @ 2010-08-15 22:34 UTC (permalink / raw) To: zsh-workers mailing list 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2010-08-15 22:34 ` Bart Schaefer @ 2010-08-31 14:33 ` Philipp Hartwig 2010-09-06 4:11 ` Bart Schaefer 0 siblings, 1 reply; 21+ messages in thread From: Philipp Hartwig @ 2010-08-31 14:33 UTC (permalink / raw) To: zsh-workers [-- 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 --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2010-08-31 14:33 ` Philipp Hartwig @ 2010-09-06 4:11 ` Bart Schaefer 2011-01-09 18:56 ` Philipp Hartwig 0 siblings, 1 reply; 21+ messages in thread From: Bart Schaefer @ 2010-09-06 4:11 UTC (permalink / raw) To: zsh-workers 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2010-09-06 4:11 ` Bart Schaefer @ 2011-01-09 18:56 ` Philipp Hartwig 2011-01-09 19:54 ` Bart Schaefer 0 siblings, 1 reply; 21+ messages in thread From: Philipp Hartwig @ 2011-01-09 18:56 UTC (permalink / raw) To: zsh-workers [-- 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 --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2011-01-09 18:56 ` Philipp Hartwig @ 2011-01-09 19:54 ` Bart Schaefer 2011-01-09 20:57 ` Philipp Hartwig 0 siblings, 1 reply; 21+ messages in thread From: Bart Schaefer @ 2011-01-09 19:54 UTC (permalink / raw) To: Philipp Hartwig, zsh-workers 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2011-01-09 19:54 ` Bart Schaefer @ 2011-01-09 20:57 ` Philipp Hartwig 0 siblings, 0 replies; 21+ messages in thread From: Philipp Hartwig @ 2011-01-09 20:57 UTC (permalink / raw) To: zsh-workers [-- 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 --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2010-08-12 14:53 ` Frank Terbeck 2010-08-12 15:20 ` Philipp Hartwig @ 2010-08-12 16:04 ` Bart Schaefer 2010-08-12 17:03 ` Philipp Hartwig 1 sibling, 1 reply; 21+ messages in thread From: Bart Schaefer @ 2010-08-12 16:04 UTC (permalink / raw) To: zsh-workers 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? -- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: segfault on menu-select 2010-08-12 16:04 ` Bart Schaefer @ 2010-08-12 17:03 ` Philipp Hartwig 0 siblings, 0 replies; 21+ messages in thread From: Philipp Hartwig @ 2010-08-12 17:03 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers [-- 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 --] ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2011-01-09 20:59 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-08-12 14:46 segfault on menu-select Philipp Hartwig 2010-08-12 14:53 ` Frank Terbeck 2010-08-12 15:20 ` Philipp Hartwig 2010-08-12 15:49 ` Frank Terbeck 2010-08-12 16:53 ` Philipp Hartwig 2010-08-12 17:07 ` Frank Terbeck 2010-08-12 17:33 ` Philipp Hartwig 2010-08-12 18:04 ` Frank Terbeck 2010-08-12 23:07 ` Bart Schaefer 2010-08-13 8:08 ` Philipp Hartwig 2010-08-13 15:57 ` Bart Schaefer 2010-08-13 20:43 ` Peter Stephenson 2010-08-15 20:43 ` Bart Schaefer 2010-08-15 22:34 ` Bart Schaefer 2010-08-31 14:33 ` Philipp Hartwig 2010-09-06 4:11 ` Bart Schaefer 2011-01-09 18:56 ` Philipp Hartwig 2011-01-09 19:54 ` Bart Schaefer 2011-01-09 20:57 ` Philipp Hartwig 2010-08-12 16:04 ` Bart Schaefer 2010-08-12 17:03 ` Philipp Hartwig
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).