Re: coredump on C-c

[Bart Schaefer <schaefer@brasslantern.com>]

[-- Attachment #1: Type: text/plain, Size: 2375 bytes --]

On Thu, Sep 26, 2013 at 10:52 AM, Eitan Adler <lists@eitanadler.com> wrote:

> Sometimes, when pressing Ctrl-c to exit a program I get a coredump.  I
> have not been able to isolate the exact case when this happens.
>
> #12 0x000000000053ded6 in zleaftertrap (dummy=0x87ea50 <zshhooks+80>,
> dat=0x0) at zle_main.c:1856

...

> name=0x800930040 "_main_complete") at exec.c:4854
>


If this is an accurate backtrace, and you've accurately described the
circumstances in which you pressed ctrl-c, then it indicates that you've
invoked completion, which then started an external program, which you then
killed with ctrl-c.  This is causing the hook function set by zle to
attempt to delete the scope for the special completion variables from
inside the signal handler, which fails because (if I'm not mistaken) that
parameter scope has already begun to be deleted before the signal handler
was called.

A first question is, is the first sentence of the previous paragraph
correct?  And if so, what are you doing invoking a program that you might
have to kill off with ctrl-c from inside a completion widget?  I'd say that
particular widget is in need of a rewrite.

However, from the "it still shouldn't crash" perspective, there's some kind
of a race condition, the gist of which is that  somewhere in this chain ...

#17 0x000000000049389b in zhandler (sig=0x2) at signals.c:603
#18 0x000000000045ed67 in zfree (p=0x98fbc8, sz=0x0) at mem.c:1481
#19 0x000000000046cc10 in freeparamnode (hn=0x98fbc8) at params.c:4761
#20 0x0000000000435c43 in resizehashtable (ht=0x98d938, newsize=0x110)
at hashtable.c:491
#21 0x0000000000435bcb in emptyhashtable (ht=0x98d938) at hashtable.c:516
#22 0x0000000000434f05 in deletehashtable (ht=0x98d938) at hashtable.c:126
#23 0x000000000046d6ea in deleteparamtable (t=0x98d938) at params.c:516
#24 0x000000000046c931 in hashsetfn (pm=0x988ec0, x=0x0) at params.c:3197
#25 0x000000000046c483 in stdunsetfn (pm=0x988ec0, exp=0x0) at params.c:3076
#26 0x000000000047749c in unsetparam_pm (pm=0x988ec0, altflag=0x0,
exp=0x0) at params.c:2983

... we should be queuing signals.  zfree() does it internally, but that's
not enough to stop corruption in freeparamnode() if the signal arrives
before all the parts of the node are cleaned p, and we probably ought to be
queuing signals around the entire "free all the nodes" loop in
resizehashtable().