Re: [PHP-DEV] PHP CLI + Valgrind = FAIL
On 11/08/2011 10:43 AM, Rasmus Lerdorf wrote: 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI + Valgrind = FAIL
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==6346563465== 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==6346563465== 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==6346563465== 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==6347363473== 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 yohg...@ohgaki.net On Tue, Nov 8, 2011 at 6:00 PM, Antony Dovgal t...@daylessday.org wrote: On 11/08/2011 10:43 AM, Rasmus Lerdorf wrote: 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI + Valgrind = FAIL
It seems copypaste 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 yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI + Valgrind = FAIL
On 11/08/2011 06:23 AM, Stas Malyshev wrote:
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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI + Valgrind = FAIL
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI + Valgrind = FAIL
On 11/08/2011 11:30 AM, Rasmus Lerdorf wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI + Valgrind = FAIL
On Tue, Nov 8, 2011 at 7:39 PM, Florian Anderiasch m...@anderiasch.de wrote: On 11/08/2011 11:30 AM, Rasmus Lerdorf wrote: 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 yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI + Valgrind = FAIL
On Tue, Nov 8, 2011 at 7:54 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: 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 yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI + Valgrind = FAIL
On 11/08/2011 10:34 AM, Yasuo Ohgaki wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI + Valgrind = FAIL
Hi! On 11/8/11 1:34 AM, Yasuo Ohgaki wrote: It seems copypaste 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI + Valgrind = FAIL
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? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI + Valgrind = FAIL
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI + Valgrind = FAIL
On 08.11.2011 18:47, Rasmus Lerdorf wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI + Valgrind = FAIL
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 yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI + Valgrind = FAIL
I think it is a new thing in Valgrind 3.7 On 11/08/2011 02:23 PM, Yasuo Ohgaki wrote: 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 yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI + Valgrind = FAIL
2011/11/9 Rasmus Lerdorf ras...@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 yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI + Valgrind = FAIL
On 11/07/2011 09:23 PM, Stas Malyshev wrote: 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
