Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56156 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 38225 invoked from network); 8 Nov 2011 10:30:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Nov 2011 10:30:20 -0000 Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.210.44 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 209.85.210.44 mail-pz0-f44.google.com Received: from [209.85.210.44] ([209.85.210.44:47714] helo=mail-pz0-f44.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 23/B0-34278-AB409BE4 for ; Tue, 08 Nov 2011 05:30:19 -0500 Received: by pzk32 with SMTP id 32so1889799pzk.3 for ; Tue, 08 Nov 2011 02:30:16 -0800 (PST) Received: by 10.68.28.133 with SMTP id b5mr6734277pbh.28.1320748216163; Tue, 08 Nov 2011 02:30:16 -0800 (PST) Received: from [192.168.200.5] (c-50-131-44-225.hsd1.ca.comcast.net. [50.131.44.225]) by mx.google.com with ESMTPS id a4sm3254382pbd.7.2011.11.08.02.30.13 (version=SSLv3 cipher=OTHER); Tue, 08 Nov 2011 02:30:14 -0800 (PST) Message-ID: <4EB904B4.2060504@lerdorf.com> Date: Tue, 08 Nov 2011 02:30:12 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Florian Anderiasch CC: Stas Malyshev , PHP Internals References: <4EB8BCC2.6040900@sugarcrm.com> <4EB8F8E2.3010208@anderiasch.de> In-Reply-To: <4EB8F8E2.3010208@anderiasch.de> X-Enigmail-Version: 1.4a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] PHP CLI + Valgrind = FAIL From: rasmus@lerdorf.com (Rasmus Lerdorf) On 11/08/2011 01:39 AM, Florian Anderiasch wrote: > So it looks like only FPM uses it for more than the default behaviour of > "terminate", from a quick glance. Well, it is part of the new 5.4 signal handling code that defers these signals, including SIGUSR2, when inside a critical section. In order to determine where it is used you have to look at the environment PHP is running in. You can't figure this out just by looking at the PHP code. Not deferring SIGUSR2 just because valgrind on OSX doesn't like it isn't really an option here. We could make debug builds on OSX not defer it, I suppose. -Rasmus