zsh 4.2.0 dumping core on completion attempt

zsh 4.2.0 dumping core on completion attempt

[Thorsten Kampe]

zsh 4.2.0 dumps core under Cygwin and Linux with these lines in my
.zshrc:

autoload -U compinit; compinit -C   # completion system
# case-insensitive and partial-word then substring
zstyle ':completion:*' matcher-list 'm:{a-zA-Z}={A-Za-z} m:[-._]=[-._] r:|[-./_]=** r:|=*' '+l:|=*'

More precisely it's the "m:[-._]=[-._] r:|[-./_]=**" part.

(These are variations from "6.7 Matching control and controlling where
things are inserted" of the User's Guide)

Surpringly ".f<TAB>" and "_f<TAB>" make zsh dump core while "-f<TAB>"
and "/f<TAB>" do not. The "f" letter can be in fact any *lower case*
letter while "_F<TAB>" or ".H<TAB>" don't make zsh dump core.

Thorsten

Re: zsh 4.2.0 dumping core on completion attempt

[Felix Rosencrantz]

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.   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
touch a_f .foo .bar_foo .foo_bar bar.foo.fez
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.

Also, there could be other things in your .zshrc that are related to this bug. 
The "-f" flag will prevent your .zshrc from being read.

If you can reproduce it with a "zsh -f" script, then others will too.

Thanks
-FR.


--- Thorsten Kampe <thorsten@thorstenkampe.de> wrote:
> zsh 4.2.0 dumps core under Cygwin and Linux with these lines in my
> .zshrc:
> 
> autoload -U compinit; compinit -C   # completion system
> # case-insensitive and partial-word then substring
> zstyle ':completion:*' matcher-list 'm:{a-zA-Z}={A-Za-z} m:[-._]=[-._]
> r:|[-./_]=** r:|=*' '+l:|=*'
> 
> More precisely it's the "m:[-._]=[-._] r:|[-./_]=**" part.
> 
> (These are variations from "6.7 Matching control and controlling where
> things are inserted" of the User's Guide)
> 
> Surpringly ".f<TAB>" and "_f<TAB>" make zsh dump core while "-f<TAB>"
> and "/f<TAB>" do not. The "f" letter can be in fact any *lower case*
> letter while "_F<TAB>" or ".H<TAB>" don't make zsh dump core.
> 
> Thorsten
> 


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

Re: zsh 4.2.0 dumping core on completion attempt

[Thorsten Kampe]

* 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

Re: zsh 4.2.0 dumping core on completion attempt

[Felix Rosencrantz]

--- 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/