From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 636 invoked by alias); 30 Mar 2011 16:57:50 -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: 28954 Received: (qmail 2757 invoked from network); 30 Mar 2011 16:57:39 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <110330095723.ZM746@torch.brasslantern.com> Date: Wed, 30 Mar 2011 09:57:23 -0700 In-reply-to: Comments: In reply to Mikael Magnusson "Re: completion crash" (Mar 30, 6:26pm) References: <237967ef0808211855o61795746l90b08dac912f9455@mail.gmail.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh workers Subject: Re: completion crash MIME-version: 1.0 Content-type: text/plain; charset=us-ascii 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.