From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4732 invoked by alias); 13 May 2015 18:01:41 -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: 35112 Received: (qmail 14590 invoked from network); 13 May 2015 18:01:40 -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=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=PgBC8M/wk0nTk3nmrzXg5TLHxbSLN2H36NhdTcfMnoQ=; b=QFWu8eBsEfje3kjPcFlMuJSfBSZMk8pXeQ2NBNf5AhKrHSN97sMaDEgw/AxhwFVcTt HbbHB/enpIcbDYWF8H1GHhvrDLLsQK+pdkt5vHyEZIwUQuXwmcTka0T+GcdGtjJePG3x axekY6S48IhTg/S0OmzH9xS2fZFIgMvpfgtEtqzjTDYnaTkVx0env5Fhx+Bsbv0ZtGk4 EAwHbdZKYi2+VIqxZ7lExYJ1oucQtxYf9wK4C/nwuSGOyzKfY6ekLDYSAXw0yZZV8Gaq YriarPf8Na0si0qX6JjooKc2Zvyf+l2gLOzAGngp1Mc9KUQXUULvojGiB30G6rbta1Ir oepg== X-Gm-Message-State: ALoCoQnRuFjccrenmsjKfqRGCZ0lHoIpxZek4J3NTXmaE2Jg38DIN8Wnkt/w18LE80UQ3s1UBijn X-Received: by 10.202.56.67 with SMTP id f64mr137750oia.16.1431540098518; Wed, 13 May 2015 11:01:38 -0700 (PDT) From: Bart Schaefer Message-Id: <150513110135.ZM28258@torch.brasslantern.com> Date: Wed, 13 May 2015 11:01:35 -0700 In-Reply-To: <1650705.NsQYeMnTDs@kdudka.brq.redhat.com> Comments: In reply to Kamil Dudka "another deadlock in free() called from a signal handler" (May 13, 6:37pm) References: <1650705.NsQYeMnTDs@kdudka.brq.redhat.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Kamil Dudka , zsh-workers@zsh.org Subject: Re: another deadlock in free() called from a signal handler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Date: Tue Sep 30 20:34:58 2014 -0700 33298: make lexrestore() more signal-safe