From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17102 invoked from network); 17 Sep 1999 11:02:10 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 17 Sep 1999 11:02:10 -0000 Received: (qmail 17940 invoked by alias); 17 Sep 1999 11:01:57 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7909 Received: (qmail 17932 invoked from network); 17 Sep 1999 11:01:55 -0000 Date: Fri, 17 Sep 1999 13:01:47 +0200 (MET DST) Message-Id: <199909171101.NAA02384@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk Subject: Re: odd completion behavior 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 > 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