Re: coredump on C-c

[Bart Schaefer <schaefer@brasslantern.com>]

On Fri, Sep 27, 2013 at 8:50 AM, Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
>
> On Thu, 26 Sep 2013 21:20:36 -0700
> Bart Schaefer <schaefer@brasslantern.com> 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.