Re: odd completion behavior

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4082 bytes --]


Clint Adams wrote:

> pws-4:
> 
> zsh 5 % a2ps --pretty-print=  
> _main_complete: bad pattern: (\M-T^Q^HPs^T@^P [92]
> zsh 5 % a2ps --pretty-print=
> _main_complete: bad pattern: (\n1^HPs^T@^P [92]
> zsh 5 % a2ps --pretty-print=
> _main_complete: bad set of key/value pairs for associative array [92]
> zsh 5 % 
> 
> These were achieved by typing a2ps --pre<TAB to complete until the =>
> then between 3 to 40 TABs until the error occurred.

Line 92 in `_main_complete' is: _lastcomp=( "${(@kv)compstate}" )


I've had some private discussion with Clint about this and am now
completely confused.

I asked him if he could give me a debugger stack trace when zsh
reaches the zerr(). Here it is:


zsh/2 1 % a2ps --pretty-print=
Breakpoint 1, zerr (fmt=0x82aae40 "`®*\b\210µ*\b\231", 
    str=0x82ab300 " ³*\bà²*\bð²*\bÿÿÿÿlist_max", num=0) at utils.c:44
44      {
(gdb) 
Display all 113 possibilities? (y or n)
(gdb) where
#0  zerr (fmt=0x82aae40 "`®*\b\210µ*\b\231", 
    str=0x82ab300 " ³*\bà²*\bð²*\bÿÿÿÿlist_max", num=0) at utils.c:44
#1  0x809609b in globlist (list=0x82aae40) at subst.c:221
#2  0x805f170 in addvars (l=0x816bd30, export=0) at exec.c:1356
#3  0x805fb44 in execcmd (cmd=0x816bd08, input=0, output=0, how=2, last1=2)
    at exec.c:1566
#4  0x805e43e in execpline2 (pline=0x816bcf0, how=2, input=0, output=0, 
    last1=0) at exec.c:1060
#5  0x805d915 in execpline (l=0x816bcd8, how=2, last1=0) at exec.c:875
#6  0x805d48a in execlist (list=0x816bcc0, dont_change_job=1, exiting=0)
    at exec.c:744
#7  0x8063d4b in runshfunc (list=0x816ae30, wrap=0x0, 
    name=0x81559a8 "_main_complete") at exec.c:3032
#8  0x40198481 in comp_setunset () from /usr/lib/zsh/3.1.6-debian/compctl.so
#9  0x8063cc8 in runshfunc (list=0x816ae30, wrap=0x4019a784, 
    name=0x81559a8 "_main_complete") at exec.c:3019
#10 0x8063b23 in doshfunc (name=0x81559a8 "_main_complete", list=0x816ae30, 
    doshargs=0x0, flags=0, noreturnval=0) at exec.c:2969
#11 0x4017d73e in getcpat () from /usr/lib/zsh/3.1.6-debian/zle.so
#12 0x4017de0d in getcpat () from /usr/lib/zsh/3.1.6-debian/zle.so
#13 0x4017c919 in getcpat () from /usr/lib/zsh/3.1.6-debian/zle.so
#14 0x40175b2b in acceptandmenucomplete ()
   from /usr/lib/zsh/3.1.6-debian/zle.so
#15 0x401747ee in expandorcomplete () from /usr/lib/zsh/3.1.6-debian/zle.so
#16 0x401744bf in completecall () from /usr/lib/zsh/3.1.6-debian/zle.so
#17 0x4016cda5 in execzlefunc () from /usr/lib/zsh/3.1.6-debian/zle.so
#18 0x4016ca80 in zleread () from /usr/lib/zsh/3.1.6-debian/zle.so
#19 0x8073455 in inputline () at input.c:265
#20 0x807333d in ingetc () at input.c:210
#21 0x806ccc8 in ihgetc () at hist.c:242
#22 0x8078868 in gettok () at lex.c:545
#23 0x807816a in yylex () at lex.c:308
#24 0x808acdf in parse_event () at parse.c:105
#25 0x8070f27 in loop (toplevel=1, justonce=0) at init.c:113
#26 0x8050d2c in main (argc=1, argv=0xbffffbe4) at ./main.c:89


We can't really trust this because it shows (inter alia) the same
problem as the one from 7673: #8->#7 is impossible.

The weird strings made me think that this is a memory allocation
problem with `compstate'. But I then asked Clint if he could sent me
the output of a loop printing its keys and values before line 92 and
they look ok (well, at least not completely garbled and zsh didn't
barf -- it's just that the `unambiguous_cursor' key had a value of `1'
at one point where I think it shouldn't).

So I still think this is a memory problem (not detected by the
debugging and security code in zsh, Clint said he used
--enable-zsh-debug --enable-zsh-mem-debug --enable-zsh-mem-warning
--enable-zsh-secure-free --enable-zsh-hash-debug). But I couldn't
reproduce it on my Linux box or on this Alpha here and I've spent most 
of the last night staring at different pieces of the code without
seeing any light, so... anyone have any idea? Can anyone reproduce
this? Does anyone have a memory allocation checker and can try this?

Bye
 Sven

P.S.: My brain hurts (where's that knotted handkerchief...)

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de