From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14508 invoked by alias); 30 Mar 2011 18:34:55 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28955 Received: (qmail 2754 invoked from network); 30 Mar 2011 18:34:51 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.google.com designates 209.85.220.171 as permitted sender) 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= MIME-Version: 1.0 In-Reply-To: <110330095723.ZM746@torch.brasslantern.com> References: <237967ef0808211855o61795746l90b08dac912f9455@mail.gmail.com> <110330095723.ZM746@torch.brasslantern.com> Date: Wed, 30 Mar 2011 20:34:46 +0200 Message-ID: Subject: Re: completion crash From: Mikael Magnusson To: zsh workers Content-Type: text/plain; charset=UTF-8 On 30 March 2011 18:57, Bart Schaefer 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
, orig = 0x99000074
, ipre = 0x726f772f616e6164
, ripre = 0x99003a6b
, isuf = 0x7f2f69be4138 "\350A\276i/\177", ppre = 0xffffffff00000000
, psuf = 0x0, prpre = 0x7f2f00000001
, pre = 0x7f2f69be407c "/work:", suf = 0x1
, disp = 0x0, autoq = 0x0, flags = 1774076128, brpl = 0x0, brsl = 0x500000005, rems = 0x0, remf = 0x645f746900000000
, 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
, 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