Re: PHP CLI + Valgrind = FAIL
| From: | Rasmus Lerdorf | Date: | Tue, 08 Nov 2011 17:47:43 +0000 |
| Subject: | Re: PHP CLI + Valgrind = FAIL | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-56172@lists.php.net to get a copy of this message | ||
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