Hi!
I've noticed that if I run PHP 5.4 under Valgrind on my Mac, I get this:
Fatal error: Error installing signal handler for 31 in Unknown on line 0
Could not startup.
Indeed, valgrind says:
==47112== Warning: ignored attempt to set SIGUSR2 handler in sigaction();
==47112== the SIGUSR2 signal is used internally by Valgrind
So it looks like it won't allow PHP to override signal handlers. The
questions here are - does anybody sees same problem (on Mac or other
systems) and should PHP really fail in this scenario? Not having the
possibility to run PHP under valgrind kind of sucks.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I've noticed that if I run PHP 5.4 under Valgrind on my Mac, I get this:
Fatal error: Error installing signal handler for 31 in Unknown on line 0
Could not startup.Indeed, valgrind says:
==47112== Warning: ignored attempt to set SIGUSR2 handler in sigaction();
==47112== the SIGUSR2 signal is used internally by ValgrindSo it looks like it won't allow PHP to override signal handlers. The
questions here are - does anybody sees same problem (on Mac or other
systems) and should PHP really fail in this scenario? Not having the
possibility to run PHP under valgrind kind of sucks.
That seems like a problem unique to OSX then. I've been using Valgrind
on 5.4 CLI for months without any issues on Linux and I just tested it
again now on the current code and I don't see that problem. Or perhaps
it is unique to your version of Valgrind? Mine is valgrind-3.6.1-Debian
-Rasmus
Indeed, valgrind says:
==47112== Warning: ignored attempt to set SIGUSR2 handler in sigaction();
==47112== the SIGUSR2 signal is used internally by ValgrindSo it looks like it won't allow PHP to override signal handlers. The
questions here are - does anybody sees same problem (on Mac or other
systems) and should PHP really fail in this scenario? Not having the
possibility to run PHP under valgrind kind of sucks.
Yeah, definitely looks like some Valgrind + OSX problem.
I use Valgrind with PHP for years on Linux 32bit/64bit and it works just perfectly.
Mine is 3.6.1, too.
--
Wbr,
Antony Dovgal
http://pinba.org - realtime profiling for PHP
Sorry I replied to wrong thread. I haven't used to new gmail UI...
It seems working on my MacBook.I just tried php-src-5.4 with
$ uname -aDarwin esi-yasmc1.esi.local 10.8.0 Darwin Kernel Version
10.8.0: TueJun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386
i386$./configure && make
and got following result.
$ USE_ZEND_ALLOC=0 valgrind ./sapi/cli/php -v==63465== Memcheck, a
memory error detector==63465== Copyright (C) 2002-2010, and GNU GPL'd,
by Julian Seward et al.==63465== Using Valgrind-3.6.1 and LibVEX;
rerun with -h for copyright info==63465== Command: ./sapi/cli/php
-v==63465==--63465-- ./sapi/cli/php:--63465-- dSYM directory is
missing; consider using --dsymutil=yesPHP 5.4.0RC1-dev (cli) (built:
Nov 8 2011 18:19:07)Copyright (c) 1997-2011 The PHP GroupZend Engine
v2.4.0, Copyright (c) 1998-2011 Zend Technologies==63465====63465==
HEAP SUMMARY:==63465== in use at exit: 104,661 bytes in 8
blocks==63465== total heap usage: 13,688 allocs, 13,680 frees,
2,936,131bytes allocated==63465====63465== LEAK SUMMARY:==63465==
definitely lost: 0 bytes in 0 blocks==63465== indirectly lost: 0
bytes in 0 blocks==63465== possibly lost: 0 bytes in 0
blocks==63465== still reachable: 104,661 bytes in 8 blocks==63465==
suppressed: 0 bytes in 0 blocks==63465== Rerun with
--leak-check=full to see details of leaked memory==63465====63465==
For counts of detected and suppressed errors, rerun with: -v==63465==
ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
However, I got this with bash
$ valgrind bash==63473== Memcheck, a memory error detector==63473==
Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et
al.==63473== Using Valgrind-3.6.1 and LibVEX; rerun with -h for
copyright info==63473== Command: bash==63473====63473== Warning:
ignored attempt to set SIGUSR2 handler in sigaction();==63473==
the SIGUSR2 signal is used internally by Valgrind--63473:0:syswrap-
WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK
);--63473:0:syswrap- WARNING: Ignoring sigreturn( ...,
UC_RESET_ALT_STACK );
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Indeed, valgrind says:
==47112== Warning: ignored attempt to set SIGUSR2 handler in
sigaction();
==47112== the SIGUSR2 signal is used internally by ValgrindSo it looks like it won't allow PHP to override signal handlers. The
questions here are - does anybody sees same problem (on Mac or other
systems) and should PHP really fail in this scenario? Not having the
possibility to run PHP under valgrind kind of sucks.Yeah, definitely looks like some Valgrind + OSX problem.
I use Valgrind with PHP for years on Linux 32bit/64bit and it works just
perfectly.
Mine is 3.6.1, too.--
Wbr,
Antony Dovgalhttp://pinba.org - realtime profiling for PHP
It seems copy&paste from a message don't work well.
yohgaki@esi-yasmc1$ uname -a
Darwin esi-yasmc1.esi.local 10.8.0 Darwin Kernel Version 10.8.0: Tue
Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
yohgaki@esi-yasmc1$ ./sapi/cli/php -v
PHP 5.4.0RC1-dev (cli) (built: Nov 8 2011 18:19:07)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies
yohgaki@esi-yasmc1$ USE_ZEND_ALLOC=0 valgrind ./sapi/cli/php -v
==63465== Memcheck, a memory error detector
==63465== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==63465== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==63465== Command: ./sapi/cli/php -v
==63465==
--63465-- ./sapi/cli/php:
--63465-- dSYM directory is missing; consider using --dsymutil=yes
PHP 5.4.0RC1-dev (cli) (built: Nov 8 2011 18:19:07)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies
==63465==
==63465== HEAP SUMMARY:
==63465== in use at exit: 104,661 bytes in 8 blocks
==63465== total heap usage: 13,688 allocs, 13,680 frees, 2,936,131
bytes allocated
==63465==
==63465== LEAK SUMMARY:
==63465== definitely lost: 0 bytes in 0 blocks
==63465== indirectly lost: 0 bytes in 0 blocks
==63465== possibly lost: 0 bytes in 0 blocks
==63465== still reachable: 104,661 bytes in 8 blocks
==63465== suppressed: 0 bytes in 0 blocks
==63465== Rerun with --leak-check=full to see details of leaked memory
==63465==
==63465== For counts of detected and suppressed errors, rerun with: -v
==63465== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
yohgaki@esi-yasmc1$ valgrind bash
==63473== Memcheck, a memory error detector
==63473== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==63473== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==63473== Command: bash
==63473==
==63473== Warning: ignored attempt to set SIGUSR2 handler in sigaction();
==63473== the SIGUSR2 signal is used internally by Valgrind
--63473:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK );
--63473:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK );
yohgaki@esi-yasmc1$
--
Yasuo Ohgaki
yohgaki@ohgaki.net
yohgaki@esi-yasmc1$ USE_ZEND_ALLOC=0 valgrind ./sapi/cli/php -v
==63465== Memcheck, a memory error detector
==63465== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==63465== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
I was testing with valgrind 3.7.0, self-compiled, on OS X and Debian - I
suppose this is what Stas used as well.
Greetings,
Florian
Hi!
It seems copy&paste from a message don't work well.
Try running some script, not -v. IIRC -v doesn't initialize request.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Indeed, valgrind says:
==47112== Warning: ignored attempt to set SIGUSR2 handler in sigaction();
==47112== the SIGUSR2 signal is used internally by ValgrindSo it looks like it won't allow PHP to override signal handlers. The
questions here are - does anybody sees same problem (on Mac or other
systems) and should PHP really fail in this scenario? Not having the
possibility to run PHP under valgrind kind of sucks.
Hi,
just poked around a bit on this.
In the valgrind 3.7 source, in tests/sigkill.c you can see that they
skip signal 32 and 33 on Linux, and SIGUSR2 seems to be different on
Darwin than on Linux.
We use SIGUSR2 in these parts of the 5.4 source:
% find . -name "*.[ch]" | xargs grep USR2
./Zend/zend_signal.c:
static int zend_sigs[] = { TIMEOUT_SIG, SIGHUP, SIGINT, SIGQUIT,
SIGTERM, SIGUSR1, SIGUSR2 };
./ext/pcntl/pcntl.c:
REGISTER_LONG_CONSTANT("SIGUSR2", (long) SIGUSR2, CONST_CS |
CONST_PERSISTENT);
./sapi/fpm/fpm/fpm_signals.c:
#ifdef SIGUSR2
[...]
./sapi/fpm/fpm/fpm_events.c:
case '2' : /* SIGUSR2 */
[...]
So it looks like only FPM uses it for more than the default behaviour of
"terminate", from a quick glance.
Greetings,
Florian
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
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.
I didn't want to imply we should change PHP behaviour in order to be
valgrindable :)
https://wiki.php.net/rfc/zendsignals is still listed as "Under
discussion", but at least the signals listed under "Startup" are already
registered it seems.
I just learned that the various signals on Linux on Darwin have totally
different numbers than on Linux, but
$ valgrind /bin/bash
shows the same behaviour as PHP, so I suspect it's really valgrind, as
seen in memcheck/tests/sigkill.stderr.exp-darwin,92 in valgrind 3.7 source.
I'm not directly able to see what they're doing different on OS X than
on Linux, and if it makes sense at all - that's for someone with more
expertise in C code review I guess :)
Greetings,
Florian
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.I didn't want to imply we should change PHP behaviour in order to be
valgrindable :)
I've been using valgrind with PHP 5.3 for sometime on my osx, and
didn't have problem.
As I just pasted the result with PHP 5.4, it seems working with my
configuration.
My MacPorts was old enough, so I'm currently updating to latest
version to see if there is
the same problem. If it is, the problem should be in port, but not in PHP.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
I've been using valgrind with PHP 5.3 for sometime on my osx, and
didn't have problem.
As I just pasted the result with PHP 5.4, it seems working with my
configuration.My MacPorts was old enough, so I'm currently updating to latest
version to see if there is
the same problem. If it is, the problem should be in port, but not in PHP.
I couldn't upgrade to current due to missing ports :(
That's the only reason that I don't upgrade to Lion.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
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?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
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_ERRORin 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
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?
According to the docs this might help:
http://valgrind.org/docs/manual/manual-core.html#manual-core.signals
If you're using signals in clever ways (for example, catching SIGSEGV,
modifying page state and restarting the instruction), you're probably
relying on precise exceptions. In this case, you will need to use
--vex-iropt-precise-memory-exns=yes.
But I've got no access to a mac until tomorrow to test it.
Greetings,
Florian
Hi Stats,
New gmail's, wordwrap and message display/sync, is killing me...
Anyway, I've been using valgrind on my osx 10.6 with PHP 5.3 for a
while and I don't have startup problem with PHP 5.4 like you did. It
sounds like valgrind configuration is different or osx version
differs. I'm using
yohgaki@esi-yasmc1$ sudo port installed valgrind
The following ports are currently installed:
valgrind @3.6.1_0 (active)
Using this version might help.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
I think it is a new thing in Valgrind 3.7
Hi Stats,
New gmail's, wordwrap and message display/sync, is killing me...
Anyway, I've been using valgrind on my osx 10.6 with PHP 5.3 for a
while and I don't have startup problem with PHP 5.4 like you did. It
sounds like valgrind configuration is different or osx version
differs. I'm usingyohgaki@esi-yasmc1$ sudo port installed valgrind
The following ports are currently installed:
valgrind @3.6.1_0 (active)Using this version might help.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
2011/11/9 Rasmus Lerdorf rasmus@lerdorf.com:
I think it is a new thing in Valgrind 3.7
When I upgraded from Leopard to Snow Leopard, I couldn't use valgrind
for a while. It was some kind of startup problem. Good to know if
there is problem with newer version. This is one reason that I'm
holding upgrade to Lion. (and ports)
--
Yasuo Ohgaki
yohgaki@ohgaki.net