From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27223 invoked by alias); 19 Feb 2015 17:24:07 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 34574 Received: (qmail 18816 invoked from network); 19 Feb 2015 17:24:04 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=Ko/6AtSI c=1 sm=1 tr=0 a=FT8er97JFeGWzr5TCOCO5w==:117 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=oR5dmqMzAAAA:8 a=-9mUelKeXuEA:10 a=0HtSIViG9nkA:10 a=HYshxDoSAAAA:8 a=VCHDa8ogfeRKjO5je2cA:9 a=CjuIK1q_8ugA:10 a=KqiPKKOXyRoA:10 From: Bart Schaefer Message-id: <150219092329.ZM17912@torch.brasslantern.com> Date: Thu, 19 Feb 2015 09:23:29 -0800 In-reply-to: <37490085.zXPQGCoLTl@kdudka.brq.redhat.com> Comments: In reply to Kamil Dudka "deadlock in free() called from a signal handler" (Feb 19, 12:06pm) References: <37490085.zXPQGCoLTl@kdudka.brq.redhat.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Kamil Dudka , zsh-workers@zsh.org Subject: Re: deadlock in free() called from a signal handler MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Feb 19, 12:06pm, Kamil Dudka wrote: } Subject: deadlock in free() called from a signal handler } } We have a bug report about deadlock in zsh due to a call to free() from } a signal handler. 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. } I have discovered a similar issue here on the list: } } http://www.zsh.org/mla/workers/2014/msg01402.html } } However, the above comment does not sound correct to me. zfree() contains } calls to do signal queueing, only if zsh is compiled with ZSH_MEM, which } is not the default configuration. Yes, I believe this eventually got noted in another thread (or another branch of that thread) because we later came upon a couple of other cases where signal queuing was needed around some global state updates. } Is this on purpose? It's not by accident, but it's been that way forever, so the reasoning is lost in time. I believe that at one point there was no zfree() and ZSH_MEM simply redefined free() directly, so the other branch may at one time have been empty and was only filled in with the minimal code when the zfree symbol was introduced. } Would it make sense to surround also the plain free() wrapper by the } signal queueing macros? I would be happy to provide a patch... I was going to say no, it's not, because we don't wrap malloc() calls similarly ... but on a quick examination there is only one direct call to malloc() left in the source anywhere outside of mem.c, and mem.c does wrap queue_signals() around all calls to malloc(). 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's may also make sense to replace that one last malloc() and put queuing in zfree()/zsfree() too.