From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23066 invoked from network); 10 Jun 2000 19:31:10 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 Jun 2000 19:31:10 -0000 Received: (qmail 1124 invoked by alias); 10 Jun 2000 19:31:03 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11856 Received: (qmail 1117 invoked from network); 10 Jun 2000 19:31:01 -0000 From: "Bart Schaefer" Message-Id: <1000610192839.ZM29060@candle.brasslantern.com> Date: Sat, 10 Jun 2000 19:28:38 +0000 In-Reply-To: <1000610185645.ZM29035@candle.brasslantern.com> Comments: In reply to "Bart Schaefer" "Re: More trap-handling crashes" (Jun 10, 6:56pm) References: <1000610182255.ZM28376@candle.brasslantern.com> <1000610185645.ZM29035@candle.brasslantern.com> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: More trap-handling crashes MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 10, 6:56pm, Bart Schaefer wrote: } } On Jun 10, 6:22pm, Bart Schaefer wrote: } } I suspect this is related to the (root cause of the) TRAPEXIT crash } } that Clint patched recently. } } I'm now completely convinced that the two are connected, and that testing } for (st->list != NULL) is not a sufficient fix. I've traced this to the point where parse.c:bld_eprog() does something horribly wrong when handed a parse consisting of nothing but NULLTOK, and now I'm beyond my understanding of what's supposed to be going on. However, it sure looks like a bad interaction between the trap scoping mechanism and eprogs for functions with empty bodies. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net