# PHP CLI + Valgrind = FAIL - Thread: https://externals.io/message/56141 - Original archive: https://news-web.php.net/php.internals/56141 - Started by Stas Malyshev on 2011-11-08T05:23:14+00:00 - Messages: 18 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #56141 — Stas Malyshev — 2011-11-08T05:23:14+00:00 URL: https://externals.io/message/56141#56141 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 --- ## #56142 — Rasmus Lerdorf — 2011-11-08T06:43:51+00:00 URL: https://externals.io/message/56141#56142 · In reply to: #56141 > 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 --- ## #56148 — Antony Dovgal — 2011-11-08T09:00:45+00:00 URL: https://externals.io/message/56141#56148 · In reply to: #56142 > > […] 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 --- ## #56152 — Yasuo Ohgaki — 2011-11-08T09:30:40+00:00 URL: https://externals.io/message/56141#56152 · In reply to: #56148 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 > > > […] > > 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 --- ## #56153 — Yasuo Ohgaki — 2011-11-08T09:34:57+00:00 URL: https://externals.io/message/56141#56153 · In reply to: #56152 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 --- ## #56154 — Florian Anderiasch — 2011-11-08T09:39:46+00:00 URL: https://externals.io/message/56141#56154 · In reply to: #56141 > 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 --- ## #56156 — Rasmus Lerdorf — 2011-11-08T10:30:12+00:00 URL: https://externals.io/message/56141#56156 · In reply to: #56154 > 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 --- ## #56158 — Florian Anderiasch — 2011-11-08T10:39:29+00:00 URL: https://externals.io/message/56141#56158 · In reply to: #56156 > 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 --- ## #56160 — Yasuo Ohgaki — 2011-11-08T10:54:00+00:00 URL: https://externals.io/message/56141#56160 · In reply to: #56158 > > > […] > > 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 --- ## #56162 — Yasuo Ohgaki — 2011-11-08T11:11:14+00:00 URL: https://externals.io/message/56141#56162 · In reply to: #56160 > 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 --- ## #56163 — Florian Anderiasch — 2011-11-08T12:09:41+00:00 URL: https://externals.io/message/56141#56163 · In reply to: #56153 > 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 --- ## #56169 — Stas Malyshev — 2011-11-08T17:37:45+00:00 URL: https://externals.io/message/56141#56169 · In reply to: #56153 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 --- ## #56171 — Stas Malyshev — 2011-11-08T17:42:28+00:00 URL: https://externals.io/message/56141#56171 · In reply to: #56156 Hi! > > > […] > 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 --- ## #56172 — Rasmus Lerdorf — 2011-11-08T17:47:43+00:00 URL: https://externals.io/message/56141#56172 · In reply to: #56171 > Hi! > > > […] > > 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 --- ## #56174 — Florian Anderiasch — 2011-11-08T18:23:46+00:00 URL: https://externals.io/message/56141#56174 · In reply to: #56172 > 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 --- ## #56177 — Yasuo Ohgaki — 2011-11-08T22:23:46+00:00 URL: https://externals.io/message/56141#56177 · In reply to: #56141 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 --- ## #56178 — Rasmus Lerdorf — 2011-11-08T22:27:16+00:00 URL: https://externals.io/message/56141#56178 · In reply to: #56177 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 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 --- ## #56179 — Yasuo Ohgaki — 2011-11-08T22:45:07+00:00 URL: https://externals.io/message/56141#56179 · In reply to: #56178 2011/11/9 Rasmus Lerdorf : > 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