Re: coredump on C-c

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

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.  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