Re: BUG: doinsert() in NextStep/OpenStep 4.2

[Brian Boonstra <boonstb@xxxxxxxxxxxxx>]

Bart wrote:
> So did you attach after zsh was hung (as in your first example)?  Or did
> you attach first and then try to get zsh to hang?  And did it hang, or
> did you get a crash of some kind?  I can't be sure from your gdb trace.

Sorry if I was unclear.  Perhaps the following snippet will be more  
informative (I'm still trying to work out what is relevant).   I attached  
before any kind of hang, continued, then typed the letter "l", which from  
previous experience gave a memory exception at line 54:

(gdb) att 22701
Dynamic Linkeditor at 0x12000000 offset 0x0
Executable at 0x2000 offset 0x0
/NextLibrary/Frameworks/System.framework/Versions/A/System at 0x5000000 offset 0x0
0x507a4c8 in _read ()
(gdb) c

Breakpoint 1, doinsert (str=0xbfffeea8 "l") at zle_misc.c:54
54                  line[cs++] = *s == Meta ? *++s ^ 32 : *s;
(gdb) p s
$4 = 0xbfffeea8 "l"
(gdb) p m
$5 = 0
(gdb) p zshcs
$6 = 0
(gdb) p line
$7 = (unsigned char *) 0xd0fbc "|"
(gdb) p *s
$8 = 108 'l'
(gdb) s
Program generated(1): Memory access exception on address 0x0 (protection failure).
0x8b517 in doinsert (str=0xbfffeea8 "l") at zle_misc.c:54
54                  line[cs++] = *s == Meta ? *++s ^ 32 : *s;



I have to say that I can't see why this line is failing.  Since zshcs==0,  
and *s!=Meta, this should just be setting line[0]="l" with no problem.  Is  
there something unusual I misunderstand about attaching debuggers to shells?

Lacking xterm, I did not try to use your shell code

> xterm -title GDBterm -e sh -c 'exec xterm -e gdb --tty=`tty` '"$*"

especially because I don't think my gdb accepts a --tty argument.

> } 3.0.x does not compile
>
> Not even 3.0.7?  What's the failure, again?

I hadn't tested 3.0.7 before, actually.  I just took a look at it, and it  
does compile, but gives a different kind of problem.  Any command (even  
"exit") ends up in the mini-editor until you Ctrl-C out of it, like this:

wo1203 % ls                                                /Cache/zsh/zsh-3.0.7
>
>
wo1203 % exit                                              /Cache/zsh/zsh-3.0.7
>
>
wo1203 %                                                   /Cache/zsh/zsh-3.0.7



It doesn't crash, though...and gdb given no indication of errors.  For  
grins, I tried the same breakpoint as for bart7, but (and this is kind of  
interesting) I never hit it at all.


Incidentally, for this email, both builds were configured with


CC=/bin/cc ./configure --enable-zsh-debug --enable-zsh-mem-debug  
--enable-zsh-mem-warning --enable-zsh-secure-free --enable-zsh-hash-debug



I'm ready to check out anything else about what's going on here -- just let  
me know what to look at!


	Best Regards,

		Brian