Re: odd completion behavior

Re: odd completion behavior

[Sven Wischnowsky]

Bart Schaefer wrote:

> If I had to guess, I'd say that the stack is getting trashed because
> the VARARR() at exec.c:3019 is not allocating the right number of bytes.

I suspected the VARARR()s, too, but...

> That wouldn't show up in any of the zsh memory testing stuff because it
> is using alloca() or the equivalent to create space on the stack, and
> it would explain how the bogus frame #8 got stuck in there.
> 
> Could the global underscorelen be messed up at that point?

for this one there was only a small chance with a combination of
checkmailpath() being invoked and a mail prompt that needed to be
singsub()ed, I think.

And now that I looked again, I saw that the one in `complist' may be
wrong allocated with the wrong size. This could only cause problems if 
menu-selection was used and none of the `ZLS_*' parameters was
set. (Btw., Clint, does it complete something after the
`--pretty-print=' or are there no possible completions?)

All other VARARR()s look OK, as far as I can tell.


If only we knew at which version this started to misbehave...


Bye
 Sven

diff -u os/utils.c Src/utils.c
--- os/utils.c	Mon Sep 20 13:06:20 1999
+++ Src/utils.c	Mon Sep 20 13:17:08 1999
@@ -752,9 +752,14 @@
 		    fprintf(shout, "You have new mail.\n");
 		    fflush(shout);
 		} else {
-		    char *usav = underscore;
+		    VARARR(char, usav, underscorelen);
+		    int sl = strlen(*s);
 
-		    underscore = *s;
+		    if (sl >= underscorelen) {
+			zfree(underscore, underscorelen);
+			underscore = (char *) zalloc(underscorelen = sl + 32);
+		    }
+		    strcpy(underscore, *s);
 		    HEAPALLOC {
 			u = dupstring(u);
 			if (! parsestr(u)) {
@@ -763,8 +768,8 @@
 			    fputc('\n', shout);
 			    fflush(shout);
 			}
-			underscore = usav;
 		    } LASTALLOC;
+		    strcpy(underscore, usav);
 		}
 	    }
 	    if (isset(MAILWARNING) && st.st_atime > st.st_mtime &&
diff -u os/Zle/complist.c Src/Zle/complist.c
--- os/Zle/complist.c	Mon Sep 20 13:06:26 1999
+++ Src/Zle/complist.c	Mon Sep 20 13:25:49 1999
@@ -217,6 +217,10 @@
 	    c->cols[COL_MA] = "";
 	else
 	    c->cols[COL_EC] = tcstr[TCSTANDOUTEND];
+	lr_caplen = 0;
+	if ((max_caplen = strlen(c->cols[COL_MA])) <
+	    (l = strlen(c->cols[COL_EC])))
+	    max_caplen = l;
 	return;
     }
     /* We have one of the parameters, use it. */
@@ -230,7 +234,7 @@
     for (i = 0; i < NUM_COLS; i++) {
 	if (!c->cols[i])
 	    c->cols[i] = defcols[i];
-	if ((l = (c->cols[i] ? strlen(c->cols[i]) : 0)) > max_caplen)
+	if (c->cols[i] && (l = strlen(c->cols[i])) > max_caplen)
 	    max_caplen = l;
     }
     lr_caplen = strlen(c->cols[COL_LC]) + strlen(c->cols[COL_RC]);

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

Re: odd completion behavior

[Clint Adams]

> set. (Btw., Clint, does it complete something after the
> `--pretty-print=' or are there no possible completions?)

It completes nothing at all.

Re: odd completion behavior

[Bart Schaefer]

On Sep 17,  1:01pm, Sven Wischnowsky wrote:
} Subject: Re: odd completion behavior
}
} (gdb) where
} #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
} 
} 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'.

If I had to guess, I'd say that the stack is getting trashed because
the VARARR() at exec.c:3019 is not allocating the right number of bytes.

That wouldn't show up in any of the zsh memory testing stuff because it
is using alloca() or the equivalent to create space on the stack, and
it would explain how the bogus frame #8 got stuck in there.

Could the global underscorelen be messed up at that point?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: odd completion behavior

[Sven Wischnowsky]

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

Re: odd completion behavior

[Clint Adams]

> No and I can't reproduce it. Can you get this error with `zsh -f' or
> could you tell us more about your environment?

Src/zsh is compiled with
--enable-zsh-debug --enable-zsh-mem-debug --enable-zsh-mem-warning \
--enable-zsh-secure-free --enable-zsh-hash-debug

zsh 381 % Src/zsh -f
ghanima% autoload -U compinit
ghanima% compinit
ghanima% compconf completer=_complete:_correct:_approximate
ghanima% setopt nobeep       
ghanima% a2ps --pretty-print=
_main_complete: bad pattern: (^L"^HPs^T@^P [92]
ghanima% a2ps --pretty-print=
_main_complete: bad pattern: h<-^HPs^T@^P [92]
ghanima% a2ps --pretty-print=
_main_complete: bad pattern: (\M-^]/^HPs^T@^P [92]
ghanima% a2ps --pretty-print=
_main_complete: bad pattern: (;x^HPs^T@^P [92]
ghanima% a2ps --pretty-print=
_main_complete: bad set of key/value pairs for associative array [92]
ghanima% a2ps --pretty-print=
_main_complete: bad pattern: Hw(^HPs^T@^P [92]
ghanima% a2ps --pretty-print=
ghanima% ldd Src/zsh
        libdl.so.2 => /lib/libdl.so.2 (0x40005000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x40008000)
        libncurses.so.4 => /lib/libncurses.so.4 (0x4001e000)
        libc.so.6 => /lib/libc.so.6 (0x4005f000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)

Again, I typed a2ps --pre and then began hitting TAB at various
frequencies.

> The error message irritates me because line 92 in `_main_complete' is
> just `_lastcomp=( "${(@kv)compstate}" )' and the error message is only 
> emitted if the number of elements in the `(...)' is odd (err, an odd
> number of...). And `${(kv)foo}' should never give an odd number of
> strings for an associative array, I think.

> And what's that `bad pattern' message, there is no pattern. Hm.

What shall I try next?

Re: odd completion behavior

[Sven Wischnowsky]

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.
> 
> Anyone know what's going on here?

No and I can't reproduce it. Can you get this error with `zsh -f' or
could you tell us more about your environment?

The error message irritates me because line 92 in `_main_complete' is
just `_lastcomp=( "${(@kv)compstate}" )' and the error message is only 
emitted if the number of elements in the `(...)' is odd (err, an odd
number of...). And `${(kv)foo}' should never give an odd number of
strings for an associative array, I think.

And what's that `bad pattern' message, there is no pattern. Hm.

Bye
 Sven


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

odd completion behavior

[Clint Adams]

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.

Anyone know what's going on here?