From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3109 invoked by alias); 31 Mar 2011 21:11:38 -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: 28966 Received: (qmail 2387 invoked from network); 31 Mar 2011 21:11:35 -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: pass (ns1.primenet.com.au: SPF record at ntlworld.com designates 81.103.221.56 as permitted sender) Date: Thu, 31 Mar 2011 20:56:42 +0100 From: Peter Stephenson To: zsh workers Subject: Re: completion crash Message-ID: <20110331205642.78bfc851@pws-pc.ntlworld.com> In-Reply-To: References: <237967ef0808211855o61795746l90b08dac912f9455@mail.gmail.com> <110330095723.ZM746@torch.brasslantern.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g= c=1 sm=0 a=kj9zAlcOel0A:10 a=pGLkceISAAAA:8 a=HYshxDoSAAAA:8 a=NLZqzBF-AAAA:8 a=D3nnzn7z6lK_5gB_eeUA:9 a=CjuIK1q_8ugA:10 a=it1y3y4XctMA:10 a=hkmW805tbE4A:10 a=RzIp4IhHamEA:10 a=MSl-tDqOz04A:10 a=_dQi-Dcv4p4A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 On Wed, 30 Mar 2011 20:34:46 +0200 Mikael Magnusson wrote: > 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. The nearest fix I can see to code of this kind is zsh-workers/22565, http://www.zsh.org/mla/workers/2006/msg00452.html though there may be others in that neighbourhood; I'm certainly vaguely aware of one that smelled similar over the last few years and the commit log for compcore.c suggests it's probably that (though I don't know the one I'm thinking of was fixed in compcore.c). It's all down to the fact that the place is full of global variables that are tied to a particular memory allocation state without any guide to the programmer or debugger of how. So you end up having to guess where it is or isn't appropriate to use, ignore or clear those variables. zsh-workers/23478, http://www.zsh.org/mla/workers/2007/msg00399.html is also similar; that was in compresult.c, also 20150, http://www.zsh.org/mla/workers/2004/msg00803.html -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/