From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 616 invoked by alias); 27 Sep 2013 15:56:32 -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: 31774 Received: (qmail 3652 invoked from network); 27 Sep 2013 15:56:18 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) 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.2 Received-SPF: pass (ns1.primenet.com.au: SPF record at ntlworld.com designates 80.0.253.69 as permitted sender) X-Originating-IP: [31.51.155.8] X-Spam: 0 X-Authority: v=2.0 cv=BfSAScR2 c=1 sm=1 a=3BWpU5VZxw7riCwclHOsWQ==:17 a=uObrxnre4hsA:10 a=kj9zAlcOel0A:10 a=NLZqzBF-AAAA:8 a=xaB2FYq-Mc8A:10 a=q2GGsy2AAAAA:8 a=29QwTI0YrOmYuLiYoYgA:9 a=CjuIK1q_8ugA:10 a=I6wTmPyJxzYA:10 a=3BWpU5VZxw7riCwclHOsWQ==:117 Date: Fri, 27 Sep 2013 16:50:43 +0100 From: Peter Stephenson To: Zsh hackers list Subject: Re: coredump on C-c Message-ID: <20130927165043.3b23c6f9@pws-pc.ntlworld.com> In-Reply-To: <130926212036.ZM29497@torch.brasslantern.com> References: <130926204956.ZM23921@torch.brasslantern.com> <130926212036.ZM29497@torch.brasslantern.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 26 Sep 2013 21:20:36 -0700 Bart Schaefer wrote: > It occurs to me, though, that queuing signals all over hashtable.c may > be an over-reaction. Maybe the problem is just with re-entering the > endparamscope() routine, and that's where queue_signals() is needed. Really, we should be doing as little from signals as possible. The fact that the trap (immediately down (numerically) the backtrace from the bit you quoted) is running an arbitrary function while anything else can be happening outside the handler is a bit worrying. I have a feeling we decided at one time that it would be a good strategy only to have trap handlers run at certain safe points (i.e. the reverse strategy from blocking them at dangerous points)? endparamscope() certainly seems an unobjectionable place to queue signals, though. If it turns out to be doing good, maybe the next thing is to look through the next higher function, runshfunc(), for other similar points. But presumably there's nothing to prevent the shell from doing any of the hashtable things you looked at before, except caused by actions in the function rather than change of scope, at the point where the SIGINT arrives and the trap gets run. pws