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

[Kamil Dudka <kdudka@redhat.com>]

On Friday 20 February 2015 18:28:12 Bart Schaefer wrote:
> On Feb 19,  9:23am, Bart Schaefer wrote:
> }
> } In every case I can remember so far, when this happens it means that we
> } ought to be using the signal queuing macros at a scope outside the call
> } to the malloc library.
> }  [...]
> } So ... per my very first remark above, it's probably worth examining the
> } context in execcmd() to see if signal queuing is appropriate there, or
> } if we just need it in setunderscore().  But it may also make sense to
> } replace that one last malloc() and put queuing in zfree()/zsfree() too.
> 
> (Above edited for silly typo.)
> 
> There doesn't appear to be an appropriate scope for queuing signals in
> execcmd().  However, setunderscore() and all of the functions in text.c
> manipulate global state, so they should be considered non-reentrant.
> 
> The following patch does not yet put signal queuing into zfree(), but
> does wrap it around setunderscore() and the three non-static functions
> in text.c, as well as replace that one remaining malloc() with zalloc().
> Hopefully this doesn't slow down execution noticeably.

Thank you for the patch!  We will give it a try.

Kamil