From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17429 invoked by alias); 27 Sep 2013 19:50:24 -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: 31775 Received: (qmail 8971 invoked from network); 27 Sep 2013 19:50:10 -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=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=vrKTCl7BfjLhE/el0KGSfLE4jbhYiWqToIR6tZCL8+0=; b=KhYvEOC3He9/H5wptwr9XbUf9YvihXpz/OZTrakk1CNIz6UCwVc6aqVd4nlvkFXURx 1TquVSdLzr/S4Ccr2/zj0FICNcofA9vcFvbU72sA2tn9atdBv/qRLgJIkhWXCAr0WcSc Vw9KDC8U/ZGQ/Y4df+FCQFcEitjwHsYHsy5woctSyOrNwbyjLMU2Wu5nZvz+jn+2Yo7P /c+OIPNP23DTXhYTANWFmQpVD6FmR05RHvJXtPMZmG541Ms4i2Kv1GRce9lrNydMwpGq HhACdUYiFWK0IqDcTg8LlB8W9VHU7d3H7oMBXWtjksjAqFxvVL4xo7xOEOBdAoNtE7J6 wE2g== X-Gm-Message-State: ALoCoQnCEWUCKcEbhXtkuHXvuJQyQR9aFty8BOPO6gNBdh/5dYxYjscjKWGvEYWfJhtbdAYhqXLT MIME-Version: 1.0 X-Received: by 10.152.30.74 with SMTP id q10mr7005742lah.27.1380311403197; Fri, 27 Sep 2013 12:50:03 -0700 (PDT) In-Reply-To: <20130927165043.3b23c6f9@pws-pc.ntlworld.com> References: <130926204956.ZM23921@torch.brasslantern.com> <130926212036.ZM29497@torch.brasslantern.com> <20130927165043.3b23c6f9@pws-pc.ntlworld.com> Date: Fri, 27 Sep 2013 12:50:03 -0700 Message-ID: Subject: Re: coredump on C-c From: Bart Schaefer To: Zsh hackers list Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 27, 2013 at 8:50 AM, Peter Stephenson wrote: > > 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. This particular instance is a special case, where the internal SIGINT handler is calling the "after_hook" function installed by the ZLE modules, and (if I'm interpreting things correctly) the result is that the special scope for ZLE parameters is ended twice. There may be a different way to end the ZLE scope when the editor is INTerrupted, which would also avoid this problem. > 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)? Yes, we're using signal masks that way, it's the strategy we adopted to fix some SIGWINCH bugs, but this case involves a place where we need to be responsive to SIGINT (lest a runaway widget lock up the shell). > 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. I think user-defined traps that might run arbitrary shell code are deferred to "safe" places in most cases. In this special case, though, it's an internally-defined trap gone rogue, and given that similar rogues could come in from other loadable modules, some defensive programming in the core shell seems a good idea.