another deadlock in free() called from a signal handler

another deadlock in free() called from a signal handler

[Kamil Dudka]

As already reported at <http://www.zsh.org/mla/workers/2015/msg00496.html>,
zsh may occasionally call free() from a signal handler, which causes deadlock.

The latest upstream fix for this issue now appears to be incomplete:

http://sourceforge.net/p/zsh/code/ci/a4ff8e69

Wouldn't it be safer to wrap [z]free() internally by the signal queuing macros?

Such an approach was already considered when applying the previous patch:

http://www.zsh.org/mla/workers/2015/msg00514.html

A backtrace of the deadlock (captured with zsh-4.3.11-3.el6) follows:

#0  __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97
#1  0x000000380167d0a0 in _L_lock_5189 () from /lib64/libc-2.12.so
#2  0x00000038016789fb in _int_free (av=0x380198fe80, p=0x1217d40, have_lock=0) at malloc.c:4959
#3  0x000000000044340d in freejob (jn=0x1200420, deleting=1) at jobs.c:1103
#4  0x000000000044464d in printjob (jn=0x1200420, lng=0, synch=0) at jobs.c:1066
#5  0x00000000004470ba in update_job (jn=0x1200420) at jobs.c:508
#6  0x000000000047354b in wait_for_processes () at signals.c:502
#7  0x0000000000473e15 in zhandler (sig=17) at signals.c:584
#8  <signal handler called>
#9  0x00000038016787cd in _int_free (av=0x380198fe80, p=0x1217c30, have_lock=0) at malloc.c:5013
#10 0x000000000044a339 in lexrestore () at lex.c:342
#11 0x000000000044aa68 in parse_subscript (s=<value optimized out>, sub=1, endchar=<value optimized out>) at lex.c:1679
#12 0x000000000045c2db in isident (s=0x7fc4402de570) at params.c:1016
#13 0x0000000000460279 in assignsparam (s=0x7fc4402de570, val=0x1217b10 "true", flags=0) at params.c:2583
#14 0x0000000000424154 in addvars (state=<value optimized out>, pc=<value optimized out>, addflags=<value optimized out>) at exec.c:2204
#15 0x0000000000424321 in execsimple (state=<value optimized out>) at exec.c:1061
#16 0x000000000042c023 in execlist (state=0x7fff4a707070, dont_change_job=1, exiting=0) at exec.c:1175
#17 0x000000000044b212 in execif (state=0x7fff4a707070, do_exec=0) at loop.c:515
#18 0x0000000000429d04 in execcmd (state=<value optimized out>, input=0, output=0, how=0, last1=2) at exec.c:3124
#19 0x000000000042ad56 in execpline2 (state=0x7fff4a707070, pcode=<value optimized out>, how=18, input=0, output=0, last1=0) at exec.c:1640
#20 0x000000000042b118 in execpline (state=0x7fff4a707070, slcode=<value optimized out>, how=18, last1=0) at exec.c:1424
...
#101 0x000000000042b118 in execpline (state=0x7fff4a70d420, slcode=<value optimized out>, how=18, last1=0) at exec.c:1424
#102 0x000000000042c467 in execlist (state=0x7fff4a70d420, dont_change_job=0, exiting=0) at exec.c:1207
#103 0x000000000042c7b6 in execode (p=0x7fc4402e8818, dont_change_job=0, exiting=0, context=0x48e5be "toplevel") at exec.c:1025
#104 0x000000000043dae2 in loop (toplevel=1, justonce=0) at init.c:185
#105 0x000000000043f7de in zsh_main (argc=<value optimized out>, argv=<value optimized out>) at init.c:1508
#106 0x000000380161ed1d in __libc_start_main (main=0x40de30 <main>, argc=2, ...) at libc-start.c:226
#107 0x000000000040dd69 in _start ()

Re: another deadlock in free() called from a signal handler

[Bart Schaefer]

On May 13,  6:37pm, Kamil Dudka wrote:
}
} Wouldn't it be safer to wrap [z]free() internally by the signal
} queuing macros?

Sigh.  I'm somewhat resistant to that because if the problem exists with
free() then it probably also exists with other operations at the calling
scope and the farther down we put defensive programming the less likely
we are to get a reproducible bug report for the higher-level problem.

} A backtrace of the deadlock (captured with zsh-4.3.11-3.el6) follows:
} 
} #10 0x000000000044a339 in lexrestore () at lex.c:342

The entire lexrestore() function is gone now, and its replacement has
already got the signal queuing wrapped around it.  So I think the problem
you're reporting here was already fixed:

commit 8727049674b1f39a8926c02dc74e9f19bbd70289
Author: Barton E. Schaefer <schaefer@zsh.org>
Date:   Tue Sep 30 20:34:58 2014 -0700

    33298: make lexrestore() more signal-safe

Re: another deadlock in free() called from a signal handler

[Kamil Dudka]

On Wednesday, May 13, 2015 11:01:35 Bart Schaefer wrote:
> On May 13,  6:37pm, Kamil Dudka wrote:
> }
> } Wouldn't it be safer to wrap [z]free() internally by the signal
> } queuing macros?
> 
> Sigh.  I'm somewhat resistant to that because if the problem exists with
> free() then it probably also exists with other operations at the calling
> scope and the farther down we put defensive programming the less likely
> we are to get a reproducible bug report for the higher-level problem.

True.

> } A backtrace of the deadlock (captured with zsh-4.3.11-3.el6) follows:
> }
> } #10 0x000000000044a339 in lexrestore () at lex.c:342
> 
> The entire lexrestore() function is gone now, and its replacement has
> already got the signal queuing wrapped around it.  So I think the problem
> you're reporting here was already fixed:
> 
> commit 8727049674b1f39a8926c02dc74e9f19bbd70289
> Author: Barton E. Schaefer <schaefer@zsh.org>
> Date:   Tue Sep 30 20:34:58 2014 -0700
> 
>     33298: make lexrestore() more signal-safe

Thank you for pointing out the commit!  I will have a look if there is more
of them...

Kamil