From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22165 invoked by alias); 8 Jan 2011 20:11:25 -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: 28597 Received: (qmail 3653 invoked from network); 8 Jan 2011 20:11:12 -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.47 as permitted sender) Date: Sat, 8 Jan 2011 20:10:53 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Certain pattern causing shell to crash Message-ID: <20110108201053.1f8267ff@pws-pc.ntlworld.com> In-Reply-To: <20110107203507.GA98237@redoubt.spodhuis.org> References: <20110106160802.GA4655@Xye> <20110106182201.27da4de9@pwslap01u.europe.root.pri> <20110106185134.GA10630@alpha.rzhou.org> <20110106195427.03ab19a9@pws-pc.ntlworld.com> <20110107203507.GA98237@redoubt.spodhuis.org> 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=JvdXmxIgLJv2/GthKqHpGJEEHukvLcvELVXUanXFreg= c=1 sm=0 a=p-0xN7MJ6KkA:10 a=kj9zAlcOel0A:10 a=q34bkTyjAAAA:8 a=21c8c_67AAAA:8 a=NLZqzBF-AAAA:8 a=G1x-UdeKZyvTBPWLiF0A:9 a=5vnYgF9RGvHGDPQCO9qy7p-Cfl4A:4 a=CjuIK1q_8ugA:10 a=hB6TBpPrBZUA:10 a=t_b4wO5MBi4A:10 a=_dQi-Dcv4p4A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 On Fri, 7 Jan 2011 15:35:07 -0500 Phil Pennock wrote: > On 2011-01-06 at 19:54 +0000, Peter Stephenson wrote: > > On Thu, 6 Jan 2011 13:51:35 -0500 > > Ricky Zhou wrote: > > > For what it's worth, I did a git bisect, and the segfault was introduced > > > in d234059b1c6493e5eefb6c28aa2b8a021d894d51. Hopefully this can be of > > > use to somebody more familiar with how this code works. > > > > (Ah, so I need to use > > > > git diff d234059b1c6493e5eefb6c28aa2b8a021d894d51^\! > > > > to look at it. Obvious.) > > > > Yes, that narrows it down a lot, thanks. > > Oh dear, it was me fixing another problem? I'm sorry. > > So in that change, I was avoiding shoving junk into the parse tree; was > that junk protecting us somehow? Did my original =~ feature manage > to introduce parallel code/decode bugs and the =~ code bug-fix exposed > the decode bug? I think what happened is that = and =~ were originally implemented similarly, then you discovered that wasn't appropriate, but missed one of the consequences. It's inevitable that changing the way the wordcode is structured changes how you need to decode it to turn it back into text, but actually keeping the two consistent is a bit obscure, so this isn't the first time this has happened. The code in text.c is consequent on what happens elsewhere, not the other way round, so this latest bug doesn't imply any major structural problem. -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/