FAQ
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

Search Discussions

  • Rasmus Lerdorf at Nov 8, 2011 at 6:43 am

    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
  • Antony Dovgal at Nov 8, 2011 at 9:00 am

    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
  • Yasuo Ohgaki at Nov 8, 2011 at 9:31 am
    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


    On Tue, Nov 8, 2011 at 6:00 PM, Antony Dovgal 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
  • Yasuo Ohgaki at Nov 8, 2011 at 9:35 am
    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
  • Florian Anderiasch at Nov 8, 2011 at 12:09 pm

    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
  • Stas Malyshev at Nov 8, 2011 at 5:37 pm
    Hi!
    On 11/8/11 1:34 AM, Yasuo Ohgaki wrote:
    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
  • Florian Anderiasch at Nov 8, 2011 at 9:39 am

    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
  • Rasmus Lerdorf at Nov 8, 2011 at 10:30 am

    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
  • Florian Anderiasch at Nov 8, 2011 at 10:39 am

    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
  • Yasuo Ohgaki at Nov 8, 2011 at 10:55 am

    On Tue, Nov 8, 2011 at 7:39 PM, Florian Anderiasch 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
    yohgaki@ohgaki.net
  • Yasuo Ohgaki at Nov 8, 2011 at 11:11 am

    On Tue, Nov 8, 2011 at 7:54 PM, Yasuo Ohgaki 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
    yohgaki@ohgaki.net
  • Stas Malyshev at Nov 8, 2011 at 5:42 pm
    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
  • Rasmus Lerdorf at Nov 8, 2011 at 5:47 pm

    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
  • Florian Anderiasch at Nov 8, 2011 at 6:24 pm

    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
  • Yasuo Ohgaki at Nov 8, 2011 at 10:24 pm
    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
  • Rasmus Lerdorf at Nov 8, 2011 at 10:27 pm
    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
    yohgaki@ohgaki.net
  • Yasuo Ohgaki at Nov 8, 2011 at 10:45 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedNov 8, '11 at 5:23a
activeNov 8, '11 at 10:45p
posts18
users6
websitephp.net

People

Translate

site design / logo © 2022 Grokbase