Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56172
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.213.42 cause and error)
Message-ID: <4EB96B3F.9060705@lerdorf.com>
Date: Tue, 08 Nov 2011 09:47:43 -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: Stas Malyshev <smalyshev@sugarcrm.com>
CC: PHP Internals <internals@lists.php.net>
References: <4EB8BCC2.6040900@sugarcrm.com> <4EB8F8E2.3010208@anderiasch.de> <4EB904B4.2060504@lerdorf.com> <4EB96A04.2040703@sugarcrm.com>
In-Reply-To: <4EB96A04.2040703@sugarcrm.com>
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 09:42 AM, Stas Malyshev wrote:
> Hi!
> 
>> 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.
>> 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.
> 
> Why it isn't an option? I.e. suppose by some reason - valgrind,
> debugger, profiler, etc. - sigaction fails and we can't defer certain
> signals. 99.9% of cases of running PHP never need it, why we much have
> E_ERROR in this case? I understand that removing the override altogether
> would be pointless, but why we can't just avoid hard failure there?
> Would anything break (except theoretical race condition) there?

Like I said, we can't remove it, but I am ok changing that E_ERROR to an
E_WARNING.

Valgrind should also have a way to turn off grabbing SIGUSR2. What if
you are valgrinding something that actually needs it for something real?
Are you out of luck?

-Rasmus