Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: completion crash
- X-seq: zsh-workers 28955
- From: Mikael Magnusson <mikachu@xxxxxxxxx>
- To: zsh workers <zsh-workers@xxxxxxx>
- Subject: Re: completion crash
- Date: Wed, 30 Mar 2011 20:34:46 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=7qhl9XNdKv32Mkt5PBY9lO9slDe4pNdTlbsd2CTXHjQ=; b=P6Vbo1xMq5xo/xLUGmkpcuc2kDAOYLhQRaJij6M1veRJzBmAPM9/e0kixkzirh1GX7 44cTVB1+BXpDlHnA7TGCHqjE/Psj0OkPpRpc98J6vK+I/tuRhKu08PsfTZ1Vh/yff4wy 8XMMHLXrr3/WCHnrzJZPMrM+QeoNRqNMO1YtU=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=T7ynwi12I2IgVOp0VPK0HKlJeo0c6kuC63zK2yDofqWUQ1G4Wswl0pwGQnnwvXepjO EcD9j9PnqrrVvNpi7ni9YWQw5QnNDRVdwQ48m7yHpIgIi52kY6Qlbu0hXV/z2EkVOHod TfYCdu3qwqko9NcaqfWXbuKMyl17j0n1LtVpk=
- In-reply-to: <110330095723.ZM746@torch.brasslantern.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <237967ef0808211855o61795746l90b08dac912f9455@mail.gmail.com> <AANLkTi=V6W57TUFppL9OjBGh3Zm75=tMBiwUm7bZFDbm@mail.gmail.com> <110330095723.ZM746@torch.brasslantern.com>
On 30 March 2011 18:57, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Mar 30, 6:26pm, Mikael Magnusson wrote:
> } Subject: Re: completion crash
> }
> } I've tracked this down to something calling popheap() when it
> } shouldn't, because putting "return;" at the top of popheap() makes the
> } crash go away, also, at one point during all this, in
> } parse.c:ecgetstr(), char *r gets a string assigned to it that has the
> } same address as amatches->matches, which is subsequently overwritten
> } by an strcpy. I'm not exactly sure if it's this corruption that causes
> } the crash, what eventually crashes is an access to
> } amatches->matches->prpre which is broken.
> } (gdb) print amatches->matches
> } $5 = (Cmatch *) 0x7ffff7fe3fa0
> } #1 0x000000000048008c in dupstring (s=0x6bd8fc "-s") at string.c:40
> } 40 strcpy(t, s);
> } (gdb) print t
> } $7 = 0x7ffff7fe3fa0 "-"
> }
> } This is presumably not good. Any ideas?
>
> If you're in dupstring() when that strcpy() happens, then I strongly
> suspect that what's happening is that amatches->matches points to
> freed memory which is being re-allocated in dupstring().
>
> This could be because popheap() is being called improperly, or it may
> instead be that amatches or amatches->matches is not being reset to
> zero at some point where the memory it points to is correctly freed.
> I believe we've had that latter come up before.
>
> Or it could be amatches should never point into heap memory and there
> is a dupstring() or zhalloc() in a spot that should be a ztrdup() or
> zalloc() instead. Most likely you're goig to need to find the place
> where amatches->matches is being set, rather than the spot where it is
> already pointing at garbage.
So I'm in permmatches, [1], and after this makearray call, the prpre
pointer is off, I have never looked at this code before though, so I
don't really know where this mlist array is coming from. At this
point, this is the second time the breakpoint gets hit though, only
one element in mlist (== amatches->lmatches) seems to be set,
(gdb) print **(Cmatch*)amatches->lmatches->node->next->dat
$3 = {str = 0x726174736f747561 <Address 0x726174736f747561 out of bounds>,
orig = 0x99000074 <Address 0x99000074 out of bounds>,
ipre = 0x726f772f616e6164 <Address 0x726f772f616e6164 out of bounds>,
ripre = 0x99003a6b <Address 0x99003a6b out of bounds>,
isuf = 0x7f2f69be4138 "\350A\276i/\177",
ppre = 0xffffffff00000000 <Address 0xffffffff00000000 out of
bounds>, psuf = 0x0,
prpre = 0x7f2f00000001 <Address 0x7f2f00000001 out of bounds>,
pre = 0x7f2f69be407c "/work:", suf = 0x1 <Address 0x1 out of
bounds>, disp = 0x0,
autoq = 0x0, flags = 1774076128, brpl = 0x0, brsl = 0x500000005, rems = 0x0,
remf = 0x645f746900000000 <Address 0x645f746900000000 out of
bounds>, qipl = 0, qisl = 0,
rnum = 4, gnum = 0, mode = 1774076024, modec = 47 '/', fmode = 4,
fmodec = 47 '/'}
If I do this
if (g->matches && *g->matches) (*g->matches)->prpre = NULL;
the crash goes away and I get the correct completion, but if I try to
zero out the prpre in the mlist entry, it still crashes, so I'm
obviously a bit confused about what's going on. This is g->matches
right after the makearray() call,
(gdb) print **g->matches
$5 = {str = 0x7f2f69be4068 "autostart", orig = 0x7f2f69be4340 "autostart",
ipre = 0x7f2f69be4010 "dana/work:", ripre = 0x0, isuf = 0x0,
ppre = 0x7f2f69be4038 "data/", psuf = 0x0,
prpre = 0x7f2f6ad6c8c8 <Address 0x7f2f6ad6c8c8 out of bounds>, pre =
0x0, suf = 0x0,
disp = 0x0, autoq = 0x0, flags = 1, brpl = 0x0, brsl = 0x0, rems =
0x0, remf = 0x0,
qipl = 0, qisl = 0, rnum = 0, gnum = 0, mode = 16877, modec = 47
'/', fmode = 16877,
fmodec = 47 '/'}
So I feel like I'm somehow not looking at the right mlist entry since
this has more correct stuff than the element I looked at above. (The
commandline I'm completing is "git show dana/work:data/au").
--
Mikael Magnusson
[1]
Breakpoint 1, permmatches (last=0) at compcore.c:3305
3305 g->matches = makearray(mlist, 1, g->flags, &nn, &nl, &ll);
(gdb) bt
#0 permmatches (last=0) at compcore.c:3305
#1 0x00007f2f68b2d8e2 in get_nmatches (pm=0x16d30e0) at complete.c:1267
#2 0x000000000046413d in getstrvalue (v=0x7fffeed14670) at params.c:1938
#3 0x000000000046226c in getarg (str=0x7fffeed144c0,
inv=0x7fffeed144cc, v=0x7fffeed14670,
a2=0, w=0x7fffeed144b8, prevcharlen=0x7fffeed144ac,
nextcharlen=0x7fffeed144a8)
at params.c:1282
#4 0x0000000000463750 in getindex (pptr=0x7fffeed14550,
v=0x7fffeed14670, flags=256)
at params.c:1670
#5 0x0000000000463e95 in fetchvalue (v=0x7fffeed14670,
pptr=0x7fffeed146b0, bracks=1,
flags=256) at params.c:1886
#6 0x0000000000484bff in paramsubst (l=0x7fffeed14cc0, n=0x7fffeed14ca0,
str=0x7fffeed14a20, qt=1, ssub=4) at subst.c:2188
#7 0x0000000000480df0 in stringsubst (list=0x7fffeed14cc0,
node=0x7fffeed14ca0, ssub=4,
asssub=0) at subst.c:214
#8 0x0000000000480580 in prefork (list=0x7fffeed14cc0, flags=4) at subst.c:77
#9 0x00000000004813da in singsub (s=0x7fffeed14d88) at subst.c:369
#10 0x0000000000423ce4 in evalcond (state=0x7fffeed156b0,
fromtest=0x0) at cond.c:186
#11 0x000000000042ea24 in execcond (state=0x7fffeed156b0, do_exec=0)
at exec.c:4046
#12 0x0000000000426ec3 in execsimple (state=0x7fffeed156b0) at exec.c:1068
#13 0x00000000004271d6 in execlist (state=0x7fffeed156b0,
dont_change_job=1, exiting=0)
at exec.c:1175
#14 0x0000000000452656 in execif (state=0x7fffeed156b0, do_exec=0) at loop.c:515
#15 0x000000000042cbc8 in execcmd (state=0x7fffeed156b0, input=0,
output=0, how=18, last1=2)
at exec.c:3129
#16 0x00000000004286f3 in execpline2 (state=0x7fffeed156b0,
pcode=20035, how=18, input=0,
output=0, last1=0) at exec.c:1640
#17 0x0000000000427ba9 in execpline (state=0x7fffeed156b0,
slcode=1296386, how=18, last1=0)
at exec.c:1424
#18 0x000000000042733d in execlist (state=0x7fffeed156b0,
dont_change_job=1, exiting=0)
at exec.c:1207
#19 0x0000000000426d5f in execode (p=0x1757e30, dont_change_job=1, exiting=0,
context=0x49a156 "shfunc") at exec.c:1028
#20 0x000000000042fffe in runshfunc (prog=0x1757e30, wrap=0x0,
name=0x7f2f6ad82af0 "_arguments") at exec.c:4646
#21 0x00007f2f68b2df65 in comp_wrapper (prog=0x1757e30, w=0x0,
name=0x7f2f6ad82af0 "_arguments") at complete.c:1455
#22 0x000000000042ff64 in runshfunc (prog=0x1757e30, wrap=0x7f2f68d4bda0,
name=0x7f2f6ad82af0 "_arguments") at exec.c:4631
Messages sorted by:
Reverse Date,
Date,
Thread,
Author