From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8394 invoked by alias); 1 Oct 2014 09:00:46 -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: 33301 Received: (qmail 45 invoked from network); 1 Oct 2014 09:00:42 -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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 X-AuditID: cbfec7f4-b7f156d0000063c7-95-542bc2b24749 Date: Wed, 01 Oct 2014 10:00:33 +0100 From: Peter Stephenson To: Zsh hackers list Subject: Re: zsh 5.0.6 hanged in freejob from TRAPCHLD Message-id: <20141001100033.0e10a30c@pwslap01u.europe.root.pri> In-reply-to: References: <20140930172125.GA2703@xvii.vinc17.org> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42I5/e/4Fd1Nh7RDDC51q1ocbH7I5MDoserg B6YAxigum5TUnMyy1CJ9uwSujFVnbzEWbGWvWDf7MHsD42/WLkZODgkBE4k1jx4wQ9hiEhfu rWfrYuTiEBJYyijRfPkxE4SznEmiec4RNpAqFgFVieUNF8FsNgFDiambZjOC2CICWhI7Tp5k ArGFBcwkvq84wtLFyMHBK2AvMeeiIUiYUyBY4vGzk2DLhASqJCadncQCYvML6Etc/fuJCeII e4mZV86AjeQVEJT4MfkeWA0z0PjN25pYIWx5ic1r3jJPYBSYhaRsFpKyWUjKFjAyr2IUTS1N LihOSs811CtOzC0uzUvXS87P3cQICcEvOxgXH7M6xCjAwajEw6uQoB0ixJpYVlyZe4hRgoNZ SYQ3+wBQiDclsbIqtSg/vqg0J7X4ECMTB6dUA6Pmdsl0lyeLjp5Qzrbrjt72Zd81XWtd+UZd kfNlOl7fOJt1Qy6Xuyn8OuG4seHHB6mo9x/zn2+W7Yyo16+TP8ssukNia5bKscex+rNl175g mlikuXGuWM+129rbO6LEHrmfd7l8zqh4xb6Q42zpRfzrd01JKHGzVlt3QyLi2avFLhPXfs/M u6DEUpyRaKjFXFScCADjFUeFHwIAAA== On Tue, 30 Sep 2014 16:18:43 -0700 Bart Schaefer wrote: > On Sep 30, 2014 10:30 AM, "Vincent Lefevre" wrote: > > > > I typed: > > > > ps -aef|gr pulseaudio > > > > and zsh hanged. > > The stack trace seems to indicate that the problem likely originates in > lexrestore() which calls free() directly (without the signal-safe zfree() > wrapper). There's a corresponding problem in lexsave() with a direct call > to malloc(). The CHLD signal interrupts the free, leading to internal > deadlock when another free is called (correctly via zfree this time, though > it is optimized out of the backtrace). The queue_signals() is presumably important. I don't see that zfree() makes a practical difference here, though --- the backtrace suggests malloc() isn't from zsh, in which case zfree() is surely just a simple front end to free() that checks the pointer isn't NULL? pws