* Re: zsh 4.2.0 dumping core on completion attempt [not found] ` <20040525063239.19784.qmail@web51107.mail.yahoo.com> @ 2004-05-25 22:53 ` Thorsten Kampe 2004-05-25 23:46 ` Danek Duvall 2004-05-28 5:40 ` Felix Rosencrantz 0 siblings, 2 replies; 11+ messages in thread From: Thorsten Kampe @ 2004-05-25 22:53 UTC (permalink / raw) To: zsh-workers; +Cc: zsh-users * Felix Rosencrantz (2004-05-25 08:32 +0100) > One thing that would help others to reproduce your problem is to provide a > minimal "zsh -f" cut&paste script that reproduces the problem. It would even > be better if you can include a stack trace from your core dumps, or a valgrind > report. I have no idea how to use "valgrind". > All these will make it much easier for the folks who might fix the > bug to find the problem. > > Here is a possible start of such a script: > zsh -f > autoload -U compinit; compinit -C > zstyle ':completion:*' matcher-list 'm:[-._]=[-._] r:|[-./_]=**' > mkdir bug ; cd bug > > ls _f<TAB> > <CORE DUMP> > > Note that matching specs depend on the possible completion matches. So try to > find a minimal set of files to touch, that cause the core dump you see. I > tried your spec, and didn't get a core dump. zsh -f autoload -U compinit; compinit -C zstyle ':completion:*' matcher-list 'm:[-._]=[-._] r:|[-./_]=**' mkdir bug; cd bug _f<TAB> zsh: 2588 segmentation fault zsh -f The linux zsh produces no coredump but fortunately the Cygwin does (although I have disabled it via "ulimit -Sc 0") % cat zsh.exe.stackdump Exception: STATUS_ACCESS_VIOLATION at eip=610D3BE2 eax=0000005F ebx=00000000 ecx=00000000 edx=0A1016C3 esi=0A1016C3 edi=00000000 ebp=0022A308 esp=0022A2F4 program=C:\cygwin\bin\zsh.exe, pid 2588, thread main cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023 Stack trace: Frame Function Args 0022A308 610D3BE2 (0A1016C3, 00000000, 00000001, 00000001) 0022A328 66F4DFFD (0A0FC558, 0A0EC960, 00000001, 0A101748) 0022A368 66F4F16B (0A0EC960, 0A0FC558, 0A1016C4, 00000003) 0022A468 66F495EF (00000000, 0A1016E0, 0A0E0BD0, 0A0FC558) 0022A5A8 66F485ED (0022A5D0, 0A0D6270, 00000000, 00000000) 0022A648 66F41EE6 (0A082578, 0022A660, 0022A6C0, 00000000) 0022A768 66FE1A7F (0A0824E8, 66F56300, 00000001, 0022A81C) 0022A898 66FF2CB5 (0022B590, 00000000, 00000000, 00000012) 0022A8E8 66FF131D (0022B590, 00001183, 00000012, 00000000) 0022A948 66FF0A83 (0022B590, 00001802, 00000012, 00000000) 0022A988 66FF07F1 (0022B590, 00000001, 00000000, 66FF46DF) 0022A9B8 6700F411 (0022B590, 00000000, 00000001, 0022AA6C) 0022AAE8 66FF2A85 (0022B590, 00000000, 00000000, 00000012) 0022AB38 66FF131D (0022B590, 00001143, 00000012, 00000000) 0022AB98 66FF0A83 (0022B590, 00004802, 00000012, 00000000) 0022ABD8 66FF07F1 (0022B590, 00000001, 00000000, 66FF46DF) End of stack trace (more stack frames may be present) Thorsten ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh 4.2.0 dumping core on completion attempt 2004-05-25 22:53 ` zsh 4.2.0 dumping core on completion attempt Thorsten Kampe @ 2004-05-25 23:46 ` Danek Duvall 2004-05-26 10:55 ` Peter Stephenson 2004-05-28 5:40 ` Felix Rosencrantz 1 sibling, 1 reply; 11+ messages in thread From: Danek Duvall @ 2004-05-25 23:46 UTC (permalink / raw) To: Thorsten Kampe; +Cc: zsh-workers (Dropping zsh-users.) On Wed, May 26, 2004 at 12:53:17AM +0200, Thorsten Kampe wrote: > zsh -f > autoload -U compinit; compinit -C > zstyle ':completion:*' matcher-list 'm:[-._]=[-._] r:|[-./_]=**' > mkdir bug; cd bug > _f<TAB> > zsh: 2588 segmentation fault zsh -f It dumps on Solaris, as well. This stack trace is from S9/x86. I don't know why all the symbols are not being resolved (well, it's not a debug build, that's why). I've included the memory mapping as well, which may help. The SPARC stack is not the same; I can provide that as well, if it'd be useful. (dbx) where =>[1] strncmp(0xceb63928, 0xceb61668, 0x1), at 0xce97f759 [2] 0xce8b262e(0xceb63928, 0xceb61668, 0x1), at 0xce8b262d [3] join_clines(0xceb61668, 0xceb63928), at 0xce8b36f3 [4] add_match_data(0x0, 0xce7a2028, 0xce7c1068, 0xceb63928, 0xceb60258, 0x0, 0xceb60260, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xce8ae4d3 [5] addmatches(0x8043fbc, 0xce7d27f8), at 0xce8ad70a [6] 0xce8a6825(0xce863410, 0x8044040, 0x8044078, 0x0), at 0xce8a6824 [7] execbuiltin(0xce863380, 0xce8ca0c0), at 0x805a7de [8] 0x806c4aa(0x8044b88, 0x0, 0x0, 0x12, 0x2), at 0x806c4a9 [9] 0x8069a83(0x8044b88, 0x1183, 0x12, 0x0, 0x0, 0x0), at 0x8069a82 [10] 0x8069202(0x8044b88, 0x1802, 0x12, 0x0), at 0x8069201 [11] execlist(0x8044b88, 0x1, 0x0), at 0x8068e1e [12] execwhile(0x8044b88, 0x0), at 0x8086384 [13] 0x806c6ac(0x8044b88, 0x0, 0x0, 0x12, 0x2), at 0x806c6ab [14] 0x8069a83(0x8044b88, 0x1143, 0x12, 0x0, 0x0, 0x0), at 0x8069a82 [15] 0x8069202(0x8044b88, 0x4802, 0x12, 0x0), at 0x8069201 [16] execlist(0x8044b88, 0x1, 0x0), at 0x8068e1e [17] execif(0x8044b88, 0x0), at 0x808673a [18] 0x806c6ac(0x8044b88, 0x0, 0x0, 0x12, 0x2), at 0x806c6ab [19] 0x8069a83(0x8044b88, 0x7c3, 0x12, 0x0, 0x0, 0x0), at 0x8069a82 [20] 0x8069202(0x8044b88, 0x24002, 0x12, 0x0), at 0x8069201 [21] execlist(0x8044b88, 0x1, 0x0), at 0x8068e1e [22] execif(0x8044b88, 0x0), at 0x808673a [23] 0x806c6ac(0x8044b88, 0x0, 0x0, 0x12, 0x2), at 0x806c6ab [24] 0x8069a83(0x8044b88, 0x643, 0x12, 0x0, 0x0, 0x0), at 0x8069a82 [25] 0x8069202(0x8044b88, 0x2bc02, 0x12, 0x0), at 0x8069201 [26] execlist(0x8044b88, 0x1, 0x0), at 0x8068e1e [27] execfor(0x8044b88, 0x0), at 0x8085b37 [28] 0x806c6ac(0x8044b88, 0x0, 0x0, 0x2, 0x2), at 0x806c6ab [29] 0x8069a83(0x8044b88, 0x603, 0x2, 0x0, 0x0, 0x0), at 0x8069a82 [30] 0x8069202(0x8044b88, 0x2d402, 0x2, 0x0), at 0x8069201 [31] execlist(0x8044b88, 0x1, 0x0), at 0x8068e1e [32] execwhile(0x8044b88, 0x0), at 0x8086384 [33] 0x806c6ac(0x8044b88, 0x0, 0x0, 0x2, 0x2), at 0x806c6ab [34] 0x8069a83(0x8044b88, 0x5c3, 0x2, 0x0, 0x0, 0x0), at 0x8069a82 [35] 0x8069202(0x8044b88, 0x32402, 0x2, 0x0), at 0x8069201 [36] execlist(0x8044b88, 0x1, 0x0), at 0x8068e1e [37] execode(0x8116638, 0x1, 0x0), at 0x80689e2 [38] 0x806e380(0x8044d58, 0x0), at 0x806e37f [39] 0x806c6ac(0x8044d58, 0x0, 0x0, 0x12, 0x2), at 0x806c6ab [40] 0x8069a83(0x8044d58, 0x3, 0x12, 0x0, 0x0, 0x0), at 0x8069a82 [41] 0x8069202(0x8044d58, 0xc02, 0x12, 0x0), at 0x8069201 [42] execlist(0x8044d58, 0x1, 0x0), at 0x8068e1e [43] execode(0x80fdfc0, 0x1, 0x0), at 0x80689e2 [44] runshfunc(0x80fdfc0, 0x0, 0xce862728), at 0x806ea55 [45] 0xce8a7ccc(0x80fdfc0, 0x0, 0xce862728), at 0xce8a7ccb [46] runshfunc(0x80fdfc0, 0xce8ca018, 0xce862728), at 0x806e9f2 [47] doshfunc(0x80fd290, 0x80fdfc0, 0xce8624b8, 0x2200, 0x0), at 0x806e815 [48] 0x806e2eb(0x80fd278, 0xce8624b8), at 0x806e2ea [49] 0x806c583(0x8045124, 0x0, 0x0, 0x12, 0x2), at 0x806c582 [50] 0x8069a83(0x8045124, 0x943, 0x12, 0x0, 0x0, 0x0), at 0x8069a82 [51] 0x8069202(0x8045124, 0x1802, 0x12, 0x0), at 0x8069201 [52] execlist(0x8045124, 0x1, 0x0), at 0x8068e1e [53] execode(0x81158c0, 0x1, 0x0), at 0x80689e2 [54] 0x806e380(0x80452f4, 0x0), at 0x806e37f [55] 0x806c6ac(0x80452f4, 0x0, 0x0, 0x12, 0x2), at 0x806c6ab [56] 0x8069a83(0x80452f4, 0x3, 0x12, 0x0, 0x0, 0x0), at 0x8069a82 [57] 0x8069202(0x80452f4, 0xc02, 0x12, 0x0), at 0x8069201 [58] execlist(0x80452f4, 0x1, 0x0), at 0x8068e1e [59] execode(0x80fed90, 0x1, 0x0), at 0x80689e2 [60] runshfunc(0x80fed90, 0x0, 0xce862138), at 0x806ea55 [61] 0xce8a7ccc(0x80fed90, 0x0, 0xce862138), at 0xce8a7ccb [62] runshfunc(0x80fed90, 0xce8ca018, 0xce862138), at 0x806e9f2 [63] doshfunc(0x80fe778, 0x80fed90, 0xce862100, 0x2200, 0x0), at 0x806e815 [64] 0x806e2eb(0x80fe760, 0xce862100), at 0x806e2ea [65] 0x806c583(0x8045660, 0x0, 0x0, 0x2, 0x2), at 0x806c582 [66] 0x8069a83(0x8045660, 0x103, 0x2, 0x0, 0x0, 0x0), at 0x8069a82 [67] 0x8069202(0x8045660, 0xc02, 0x2, 0x0), at 0x8069201 [68] execlist(0x8045660, 0x1, 0x0), at 0x8068e1e [69] execode(0x81156e8, 0x1, 0x0), at 0x80689e2 [70] 0x806e380(0x8045830, 0x0), at 0x806e37f [71] 0x806c6ac(0x8045830, 0x0, 0x0, 0x12, 0x2), at 0x806c6ab [72] 0x8069a83(0x8045830, 0x3, 0x12, 0x0, 0x0, 0x0), at 0x8069a82 [73] 0x8069202(0x8045830, 0xc02, 0x12, 0x0), at 0x8069201 [74] execlist(0x8045830, 0x1, 0x0), at 0x8068e1e [75] execode(0x80fe368, 0x1, 0x0), at 0x80689e2 [76] runshfunc(0x80fe368, 0x0, 0xce8620f0), at 0x806ea55 [77] 0xce8a7ccc(0x80fe368, 0x0, 0xce8620f0), at 0xce8a7ccb [78] runshfunc(0x80fe368, 0xce8ca018, 0xce8620f0), at 0x806e9f2 [79] doshfunc(0x80e8e10, 0x80fe368, 0xce8620c8, 0x2200, 0x0), at 0x806e815 [80] 0x806e2eb(0x80fd4d0, 0xce8620c8), at 0x806e2ea [81] 0x806c583(0x8045b8c, 0x0, 0x0, 0x12, 0x2), at 0x806c582 [82] 0x8069a83(0x8045b8c, 0x83, 0x12, 0x0, 0x0, 0x0), at 0x8069a82 [83] 0x8069202(0x8045b8c, 0xc02, 0x12, 0x0), at 0x8069201 [84] execlist(0x8045b8c, 0x1, 0x0), at 0x8068e1e [85] execode(0xce862080, 0x1, 0x0), at 0x80689e2 [86] bin_eval(0xce862020, 0x8045bc8, 0x8045bfc, 0xe), at 0x8064129 [87] execbuiltin(0xce862000, 0x80c7c24), at 0x805a7de [88] 0x806c4aa(0x8045fe4, 0x0, 0x0, 0x2, 0x2), at 0x806c4a9 [89] 0x8069a83(0x8045fe4, 0x4c3, 0x2, 0x0, 0x0, 0x0), at 0x8069a82 [90] 0x8069202(0x8045fe4, 0x1022, 0x2, 0x0), at 0x8069201 [91] execlist(0x8045fe4, 0x1, 0x0), at 0x8068cd9 [92] execif(0x8045fe4, 0x0), at 0x808673a [93] 0x806c6ac(0x8045fe4, 0x0, 0x0, 0x2, 0x2), at 0x806c6ab [94] 0x8069a83(0x8045fe4, 0x3c3, 0x2, 0x0, 0x0, 0x0), at 0x8069a82 [95] 0x8069202(0x8045fe4, 0xa802, 0x2, 0x0), at 0x8069201 [96] execlist(0x8045fe4, 0x1, 0x0), at 0x8068e1e [97] execode(0x81152d8, 0x1, 0x0), at 0x80689e2 [98] 0x806e380(0x80461b4, 0x0), at 0x806e37f [99] 0x806c6ac(0x80461b4, 0x0, 0x0, 0x12, 0x2), at 0x806c6ab [100] 0x8069a83(0x80461b4, 0x3, 0x12, 0x0, 0x0, 0x0), at 0x8069a82 (dbx) proc -map Loadobject mappings for current core file: 0x08050000 /usr/sfw/bin/zsh 0xceb70000 /usr/lib/libsocket.so.1 0xceb90000 /usr/lib/libdl.so.1 is being filtered by: /usr/lib/ld.so.1 0xceab0000 /usr/lib/libnsl.so.1 0xcea60000 /usr/lib/libcurses.so.1 0xcea20000 /usr/lib/libm.so.1 0xce960000 /usr/lib/libc.so.1 0xce940000 /usr/lib/libmp.so.2 0xce8f0000 /usr/sfw/lib/zsh/4.2.0/zsh/zle.so 0xce8a0000 /usr/sfw/lib/zsh/4.2.0/zsh/complete.so 0xce880000 /usr/sfw/lib/zsh/4.2.0/zsh/compctl.so 0xce840000 /usr/sfw/lib/zsh/4.2.0/zsh/parameter.so 0xce820000 /usr/sfw/lib/zsh/4.2.0/zsh/zutil.so 0xce7f0000 /usr/sfw/lib/zsh/4.2.0/zsh/computil.so 0xcebc0000 /usr/lib/ld.so.1 [LM_ID_LDSO] core file address ranges: 0x08042000 - 0x08048000 (data) 0x08050000 - 0x080b6eda (text) 0x080c6000 - 0x080cd000 (data) 0x080cd000 - 0x0812b000 (data) 0xce7a0000 - 0xce7a4000 (data) 0xce7b0000 - 0xce7b4000 (data) 0xce7c0000 - 0xce7c4000 (data) 0xce7d0000 - 0xce7d4000 (data) 0xce7e0000 - 0xce7e1000 (data) 0xce7f0000 - 0xce7fc3d1 (text) 0xce80c000 - 0xce80d000 (data) 0xce820000 - 0xce824f29 (text) 0xce834000 - 0xce836000 (data) 0xce840000 - 0xce845666 (text) 0xce855000 - 0xce856000 (data) 0xce860000 - 0xce864000 (data) 0xce870000 - 0xce871000 (data) 0xce880000 - 0xce88c9f7 (text) 0xce89c000 - 0xce89e000 (data) 0xce8a0000 - 0xce8b96a5 (text) 0xce8c9000 - 0xce8cb000 (data) 0xce8e0000 - 0xce8e1000 (data) 0xce8f0000 - 0xce917232 (text) 0xce927000 - 0xce92d000 (data) 0xce92d000 - 0xce92e000 (data) 0xce940000 - 0xce94284c (text) 0xce953000 - 0xce954000 (data) 0xce960000 - 0xce9fe548 (text) 0xcea0f000 - 0xcea15000 (data) 0xcea15000 - 0xcea16000 (data) 0xcea20000 - 0xcea32a24 (text) 0xcea42000 - 0xcea44000 (data) 0xcea50000 - 0xcea51000 (data) 0xcea60000 - 0xcea85d52 (text) 0xcea96000 - 0xcea9d000 (data) 0xcea9d000 - 0xcea9f000 (data) 0xceab0000 - 0xceb392c0 (text) 0xceb4a000 - 0xceb4f000 (data) 0xceb4f000 - 0xceb57000 (data) 0xceb60000 - 0xceb64000 (data) 0xceb70000 - 0xceb7a488 (text) 0xceb8b000 - 0xceb8c000 (data) 0xceb90000 - 0xceb90868 (text) 0xcebb0000 - 0xcebb1000 (data) 0xcebc0000 - 0xcebe0f12 (text) 0xcebc0000 - 0xcebe0f12 (text) 0xcebf0000 - 0xcebf2000 (data) 0xcebf2000 - 0xcebf3000 (data) (dbx) Danek ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh 4.2.0 dumping core on completion attempt 2004-05-25 23:46 ` Danek Duvall @ 2004-05-26 10:55 ` Peter Stephenson 2004-05-26 14:17 ` Danek Duvall 0 siblings, 1 reply; 11+ messages in thread From: Peter Stephenson @ 2004-05-26 10:55 UTC (permalink / raw) To: zsh-workers Danek Duvall wrote: > It dumps on Solaris, as well. This stack trace is from S9/x86. I don't > know why all the symbols are not being resolved (well, it's not a debug > build, that's why). I've included the memory mapping as well, which may > help. The SPARC stack is not the same; I can provide that as well, if > it'd be useful. Nobody is really supporting the core completion code at present, so the hopeful tone suggesting somebody might look at this is possibly misplaced. However, it could well be simply a NULL pointer which needs trapping with a test somehwhere. -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh 4.2.0 dumping core on completion attempt 2004-05-26 10:55 ` Peter Stephenson @ 2004-05-26 14:17 ` Danek Duvall 0 siblings, 0 replies; 11+ messages in thread From: Danek Duvall @ 2004-05-26 14:17 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-workers > Nobody is really supporting the core completion code at present, so > the hopeful tone suggesting somebody might look at this is possibly > misplaced. :) Fair enough. At least the trace is in the mail archives for anyone to work off of if/when someone does find the time. Danek ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh 4.2.0 dumping core on completion attempt 2004-05-25 22:53 ` zsh 4.2.0 dumping core on completion attempt Thorsten Kampe 2004-05-25 23:46 ` Danek Duvall @ 2004-05-28 5:40 ` Felix Rosencrantz 2004-05-28 9:37 ` Oliver Kiddle 1 sibling, 1 reply; 11+ messages in thread From: Felix Rosencrantz @ 2004-05-28 5:40 UTC (permalink / raw) To: Thorsten Kampe, zsh-workers; +Cc: zsh-users --- Thorsten Kampe <thorsten@thorstenkampe.de> wrote: > I have no idea how to use "valgrind". It's not necessary, but if you could provide valgrind output that would be groovy and might be helpful. Also, if you look back at my original mail the sample script does a touch command to put some sample files in the bug directory. This is important because it limits the matches to a well-defined set that is viewable in your mail message, to anyone who might try to reproduce the bug. In your sample script, you complete in the command position. This causes zsh to try complete a command/alias/function/etc. The problem is that each system has a different set of commands in the path. As reader a of your message, I don't know what commands/etc zsh is trying to match "_f" with. When debugging matching spec problems, it is important to see what matches zsh is trying to apply the specs to. Though I did try to reproduce your problem on several of my machines, and some had no problem. Cygwin gave me this error: alternative:69: command not found: _suffix_alias_files I was able to reproduce the problem on a rh box within gdb and got this stack trace. (Note: _f worked fine for me, this is stack trace for completing "_x") #0 strncmp (s1=0x402cbbe4 "xmmap", s2=0x0, n=1) at ../sysdeps/generic/strncmp.c:65 #1 0x40246179 in cmp_anchors (o=0x402be3e8, n=0x402bc618, join=1) at compmatch.c:1393 #2 0x40247b8a in join_clines (o=0x402bc618, n=0x402be3e8) at compmatch.c:2088 #3 0x40240dc1 in add_match_data (alt=0, str=0x402cbc08 "gkb_xmmap", orig=0x402abf28 "gkb_xmmap", line=0x402be3e8, ipre=0x40017428 "", ripre=0x0, isuf=0x40017430 "", pre=0x0, prpre=0x0, ppre=0x0, pline=0x0, psuf=0x0, sline=0x0, suf=0x0, flags=0, exact=0) at compcore.c:2488 #4 0x4023faa2 in addmatches (dat=0xbfff9910, argv=0x402a21ec) at compcore.c:2113 #5 0x40236f51 in bin_compadd (name=0x40299478 "compadd", argv=0xbfff99a4, ops=0xbfff99f0, func=0) at complete.c:636 #6 0x08053086 in execbuiltin (args=0x402993e8, bn=0x40250530) at builtin.c:439 Hope that helps if anyone wants to take a look. > % cat zsh.exe.stackdump > Exception: STATUS_ACCESS_VIOLATION at eip=610D3BE2 > eax=0000005F ebx=00000000 ecx=00000000 edx=0A1016C3 esi=0A1016C3 --- rest deleted This stackdump you provided sheds little or no light on the problem. You should only a send stack dump/trace if it can provide a stack trace with function names (with line numbers, arguments, etc would be even nicer.) A stack trace full of register values and a hexdump doesn't provide much, if anything. Someone tracking the problem would be more productive looking at the source code, than trying to decode a bunch of numbers. See the stack trace I've included for an example of one that is more informative. You may not have a debug version of zsh, so it would be impossible for you to provide a good trace. You should report you are seeing a crash like you did. I should have been a little clearer, when asking for the trace. --- Peter Stephenson <pws@csr.com> wrote: > Nobody is really supporting the core completion code at present, so the > hopeful tone suggesting somebody might look at this is possibly > misplaced. However, it could well be simply a NULL pointer which needs That's too bad. Though, folks, like Oliver, have been fixing completion problems. So I'm sorry if I gave the misimpression that any bugs would be fixed. Though having a reproducible case would make it a lot easier for anyone who wanted to try. This mail is archived, so if there is someone later, they could try. -FR. __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh 4.2.0 dumping core on completion attempt 2004-05-28 5:40 ` Felix Rosencrantz @ 2004-05-28 9:37 ` Oliver Kiddle 2004-05-28 9:43 ` Oliver Kiddle 2004-06-01 7:16 ` Felix Rosencrantz 0 siblings, 2 replies; 11+ messages in thread From: Oliver Kiddle @ 2004-05-28 9:37 UTC (permalink / raw) To: Felix Rosencrantz; +Cc: zsh-workers [ removed zsh-users ] Felix Rosencrantz wrote: > had no problem. Cygwin gave me this error: > alternative:69: command not found: _suffix_alias_files Looks like either _suffix_alias_files is missing or the upgrade from an older zsh is only partial. > I was able to reproduce the problem on a rh box within gdb and got this stack > trace. (Note: _f worked fine for me, this is stack trace for completing "_x") > #0 strncmp (s1=0x402cbbe4 "xmmap", s2=0x0, n=1) > at ../sysdeps/generic/strncmp.c:65 > #1 0x40246179 in cmp_anchors (o=0x402be3e8, n=0x402bc618, join=1) > at compmatch.c:1393 It probably just needs: (!o->word || !strncmp(o->word, n->word, o->wlen))) || changing to: (!o->word || !n->word || !strncmp(o->word, n->word, o->wlen))) || We've got o->word == "xmmap", n->word == NULL and o->wlen == n->wlen. So it might be a bug elsewhere that allows n->word == NULL or it might be an omission that it isn't checked. Presumably n->wlen == 0 but is that a length or an initial value? Could you perhaps have a more detailed look from the debugger. At least see what n->wlen is and ideally trace back to where o->word, n->word and n->wlen are set (or not set). Does that change result in it completing the right thing? Unfortunately, I can't reproduce the problem on any system I have access to. If we can't find a bug higher in the chain, this would at least avoid it crashing but I'd obviously prefer to understand what's going on. Oliver ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh 4.2.0 dumping core on completion attempt 2004-05-28 9:37 ` Oliver Kiddle @ 2004-05-28 9:43 ` Oliver Kiddle 2004-05-28 10:01 ` Peter Stephenson 2004-06-01 7:16 ` Felix Rosencrantz 1 sibling, 1 reply; 11+ messages in thread From: Oliver Kiddle @ 2004-05-28 9:43 UTC (permalink / raw) To: zsh-workers I wrote: > > We've got o->word == "xmmap", n->word == NULL and o->wlen == n->wlen. > So it might be a bug elsewhere that allows n->word == NULL or it might > be an omission that it isn't checked. Presumably n->wlen == 0 but is > that a length or an initial value? Sorry, we can of course see that n->word == 1. So we need to work out how we got n->word == NULL and n->wlen == 1 before it got to cmp_anchors(). Oliver ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh 4.2.0 dumping core on completion attempt 2004-05-28 9:43 ` Oliver Kiddle @ 2004-05-28 10:01 ` Peter Stephenson 0 siblings, 0 replies; 11+ messages in thread From: Peter Stephenson @ 2004-05-28 10:01 UTC (permalink / raw) To: zsh-workers Oliver Kiddle wrote: > I wrote: > > > > We've got o->word == "xmmap", n->word == NULL and o->wlen == n->wlen. > > So it might be a bug elsewhere that allows n->word == NULL or it might > > be an omission that it isn't checked. Presumably n->wlen == 0 but is > > that a length or an initial value? > > Sorry, we can of course see that n->word == 1. So we need to work out > how we got n->word == NULL and n->wlen == 1 before it got to > cmp_anchors(). I fixed a bug of a similar flavour recently where the Meta conversion was causing problems. It's possible the wlen comes from trying to metafy a zero-length string, or something. pws ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh 4.2.0 dumping core on completion attempt 2004-05-28 9:37 ` Oliver Kiddle 2004-05-28 9:43 ` Oliver Kiddle @ 2004-06-01 7:16 ` Felix Rosencrantz 2004-06-02 7:58 ` Felix Rosencrantz 1 sibling, 1 reply; 11+ messages in thread From: Felix Rosencrantz @ 2004-06-01 7:16 UTC (permalink / raw) To: Oliver Kiddle; +Cc: zsh-workers --- Oliver Kiddle <okiddle@yahoo.co.uk> wrote: > It probably just needs: > (!o->word || !strncmp(o->word, n->word, o->wlen))) || > changing to: > (!o->word || !n->word || !strncmp(o->word, n->word, o->wlen))) || I tried this change, and it prevents the core dump. > > We've got o->word == "xmmap", n->word == NULL and o->wlen == n->wlen. > So it might be a bug elsewhere that allows n->word == NULL or it might > be an omission that it isn't checked. Presumably n->wlen == 0 but is > that a length or an initial value? > > Could you perhaps have a more detailed look from the debugger. At least > see what n->wlen is and ideally trace back to where o->word, n->word and > n->wlen are set (or not set). Does that change result in it completing > the right thing? > > Unfortunately, I can't reproduce the problem on any system I have access > to. If we can't find a bug higher in the chain, this would at least > avoid it crashing but I'd obviously prefer to understand what's going on. I'm having problems with shared libs and gdb on my home system, so I'll have to try elsewhere to see if I can get you more info. I'd be happier if we can find the cause of the bug. I did run valgrind, and the only thing it reported was strncmp getting the NULL. -FR. __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh 4.2.0 dumping core on completion attempt 2004-06-01 7:16 ` Felix Rosencrantz @ 2004-06-02 7:58 ` Felix Rosencrantz 2004-06-02 9:29 ` Peter Stephenson 0 siblings, 1 reply; 11+ messages in thread From: Felix Rosencrantz @ 2004-06-02 7:58 UTC (permalink / raw) To: zsh-workers I think this is the patch to fix the problem, cmp_anchors causes the clines to become inconsistent. It eventually bites itself. -FR. --- compmatch.c Wed Jun 2 00:47:52 2004 *************** *** 1398,1404 **** if (line) { o->flags |= CLF_LINE; o->word = NULL; ! n->wlen = 0; } return 1; } --- 1398,1404 ---- if (line) { o->flags |= CLF_LINE; o->word = NULL; ! o->wlen = 0; } return 1; } __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh 4.2.0 dumping core on completion attempt 2004-06-02 7:58 ` Felix Rosencrantz @ 2004-06-02 9:29 ` Peter Stephenson 0 siblings, 0 replies; 11+ messages in thread From: Peter Stephenson @ 2004-06-02 9:29 UTC (permalink / raw) To: zsh-workers Felix Rosencrantz wrote: > I think this is the patch to fix the problem, cmp_anchors causes the > clines to become inconsistent. It eventually bites itself. It does look highly plausible, seeing the patch. Strange that it got like that. -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2004-06-02 9:30 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <3m5afmj8tzpu$.dlg@thorstenkampe.de> [not found] ` <20040525063239.19784.qmail@web51107.mail.yahoo.com> 2004-05-25 22:53 ` zsh 4.2.0 dumping core on completion attempt Thorsten Kampe 2004-05-25 23:46 ` Danek Duvall 2004-05-26 10:55 ` Peter Stephenson 2004-05-26 14:17 ` Danek Duvall 2004-05-28 5:40 ` Felix Rosencrantz 2004-05-28 9:37 ` Oliver Kiddle 2004-05-28 9:43 ` Oliver Kiddle 2004-05-28 10:01 ` Peter Stephenson 2004-06-01 7:16 ` Felix Rosencrantz 2004-06-02 7:58 ` Felix Rosencrantz 2004-06-02 9:29 ` Peter Stephenson
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).