FAQ
Under CLI ZTS build, when loading a PHP-GTK 2 .dll built against anything
this side of PHP 5.1.2 release, I'm seeing an 'access violation' crash on
reaching:

if (resource_types_table && !resource_types_table[j].done &&
resource_types_table[j].dtor) {
resource_types_table[j].dtor(p->storage[j], &p->storage);
}

Similar code is also used in:

tsrm_free_interpreter_context()
ts_free_thread()
ts_free_worker_threads()
ts_free_id()

I thought ts_free_thread() was crashing at that line too at first, but that
turned out to be because there's no 'done' check there, i.e. double dtors
are possible via some functions. It's still vaguely possible there's a
double flypast causing the crash I'm seeing, but I have everything I know
about protected now. (On my laptop that is.)

Eventually I found the resource id for PHP-GTK - the only extension I'm
loading during runtime, via php.ini - is 32nd out of a possible 32.
"Eventually", because that means I can't use ts_free_id() to avoid the crash
as advised by Frank (and Tony, and Dmitry, and anyone else who ever used
that MSHUTDOWN workaround for CLI). Interesting too, because the resource
that causes the crash appears to be something completely other. Tracking
down resource id #5 - and that's all I know about it apart from it crashes -
is a barrel of laughs, I'll let y'all know if I ever find out which of the
many possible extensions/files in ext/standard or core it is.

Short version: One line is problematic, and only in one function, and
presumably only under CLI SAPI. (CGI already doesn't call tsrm_shutdown(),
thanks to similar issues some 3 years ago).

The question is whether to take 'the Zeev approach' and simply comment out
the tsrm_shutdown() call at the end of sapi/cli/php_cli.c, or whether to
spend time knitting up a fine-grained approach to prevent the one bad line
in the function from being called in single-threaded environments? I think
I've given up on the idea of actually resolving the bug now...

Thoughts?

- oh, and don't make one of them 'chicken-and-egg' - this is definitively
NOT related to the shutdown order in main.c!!!!!

- Steph

Search Discussions

  • Xuefer at May 28, 2006 at 2:58 am
    i can confirm this on other extension.
    something like this
    grep free_id */*.c -B1 -A3
    mbstring/mbstring.c-#ifdef ZTS
    mbstring/mbstring.c: ts_free_id(mbstring_globals_id);
    mbstring/mbstring.c-#else
    mbstring/mbstring.c- _php_mb_globals_dtor(&mbstring_globals TSRMLS_CC);
    mbstring/mbstring.c-#endif
    have no problem with it
    while some modules like
    $ grep 'ndef ZTS' */*.c -A2
    apc/php_apc.c:#ifndef ZTS
    apc/php_apc.c- php_apc_shutdown_globals(&apc_globals);
    apc/php_apc.c-#endif
    -
    eaccelerator/eaccelerator.c:#ifndef ZTS
    eaccelerator/eaccelerator.c-
    eaccelerator_globals_dtor(&eaccelerator_globals TSRMLS_CC);
    eaccelerator/eaccelerator.c-#endif
    when compiled as shared module, will crash
    eaccelerator(mmcache) workaround it by disabling the dtor.
    /*??? FIXME
    ZEND_INIT_MODULE_GLOBALS(eaccelerator, eaccelerator_init_globals,
    eaccelerator_globals_dtor);
    */
    ZEND_INIT_MODULE_GLOBALS(eaccelerator, eaccelerator_init_globals, NULL);
  • Steph Fox at May 28, 2006 at 3:06 am
    Thanks Xuefer...

    This bug's been extant for a long time, and I only found out why when I
    spent two days/nights trying to track down its history and mechanics.

    It's a pig.

    - Steph

    ----- Original Message -----
    From: "Xuefer" <xuefer@gmail.com>
    To: "Steph Fox" <steph@zend.com>
    Cc: "internals" <internals@lists.php.net>
    Sent: Sunday, May 28, 2006 4:58 AM
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    i can confirm this on other extension.
    something like this
    grep free_id */*.c -B1 -A3
    mbstring/mbstring.c-#ifdef ZTS
    mbstring/mbstring.c: ts_free_id(mbstring_globals_id);
    mbstring/mbstring.c-#else
    mbstring/mbstring.c- _php_mb_globals_dtor(&mbstring_globals TSRMLS_CC);
    mbstring/mbstring.c-#endif
    have no problem with it
    while some modules like
    $ grep 'ndef ZTS' */*.c -A2
    apc/php_apc.c:#ifndef ZTS
    apc/php_apc.c- php_apc_shutdown_globals(&apc_globals);
    apc/php_apc.c-#endif
    -
    eaccelerator/eaccelerator.c:#ifndef ZTS
    eaccelerator/eaccelerator.c-
    eaccelerator_globals_dtor(&eaccelerator_globals TSRMLS_CC);
    eaccelerator/eaccelerator.c-#endif
    when compiled as shared module, will crash
    eaccelerator(mmcache) workaround it by disabling the dtor.
    /*??? FIXME
    ZEND_INIT_MODULE_GLOBALS(eaccelerator, eaccelerator_init_globals,
    eaccelerator_globals_dtor);
    */
    ZEND_INIT_MODULE_GLOBALS(eaccelerator, eaccelerator_init_globals, NULL);
  • Andi Gutmans at May 31, 2006 at 4:23 am
    Without looking to deeply into this reincarnation my guess would be
    that for CLI, Zeev's approach makes good sense.

    Andi
    At 08:04 PM 5/27/2006, Steph Fox wrote:
    Thanks Xuefer...

    This bug's been extant for a long time, and I only found out why
    when I spent two days/nights trying to track down its history and mechanics.

    It's a pig.

    - Steph

    ----- Original Message ----- From: "Xuefer" <xuefer@gmail.com>
    To: "Steph Fox" <steph@zend.com>
    Cc: "internals" <internals@lists.php.net>
    Sent: Sunday, May 28, 2006 4:58 AM
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    i can confirm this on other extension.
    something like this
    grep free_id */*.c -B1 -A3
    mbstring/mbstring.c-#ifdef ZTS
    mbstring/mbstring.c: ts_free_id(mbstring_globals_id);
    mbstring/mbstring.c-#else
    mbstring/mbstring.c- _php_mb_globals_dtor(&mbstring_globals TSRMLS_CC);
    mbstring/mbstring.c-#endif
    have no problem with it
    while some modules like
    $ grep 'ndef ZTS' */*.c -A2
    apc/php_apc.c:#ifndef ZTS
    apc/php_apc.c- php_apc_shutdown_globals(&apc_globals);
    apc/php_apc.c-#endif
    -
    eaccelerator/eaccelerator.c:#ifndef ZTS
    eaccelerator/eaccelerator.c-
    eaccelerator_globals_dtor(&eaccelerator_globals TSRMLS_CC);
    eaccelerator/eaccelerator.c-#endif
    when compiled as shared module, will crash
    eaccelerator(mmcache) workaround it by disabling the dtor.
    /*??? FIXME
    ZEND_INIT_MODULE_GLOBALS(eaccelerator, eaccelerator_init_globals,
    eaccelerator_globals_dtor);
    */
    ZEND_INIT_MODULE_GLOBALS(eaccelerator, eaccelerator_init_globals, NULL);
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Steph Fox at May 31, 2006 at 7:30 am
    Fixing the config so that ZE doesn't think it's PHP might actually make Zend
    more stable too...

    I think I _know_ why other extension people are seeing a crash on
    ts_free_id(), but my biggest priority at present is getting the PHP-GTK
    crash out of the way.

    - Steph
    Without looking to deeply into this reincarnation my guess would be that
    for CLI, Zeev's approach makes good sense.

    Andi
    At 08:04 PM 5/27/2006, Steph Fox wrote:
    Thanks Xuefer...

    This bug's been extant for a long time, and I only found out why when I
    spent two days/nights trying to track down its history and mechanics.

    It's a pig.

    - Steph

    ----- Original Message ----- From: "Xuefer" <xuefer@gmail.com>
    To: "Steph Fox" <steph@zend.com>
    Cc: "internals" <internals@lists.php.net>
    Sent: Sunday, May 28, 2006 4:58 AM
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    i can confirm this on other extension.
    something like this
    grep free_id */*.c -B1 -A3
    mbstring/mbstring.c-#ifdef ZTS
    mbstring/mbstring.c: ts_free_id(mbstring_globals_id);
    mbstring/mbstring.c-#else
    mbstring/mbstring.c- _php_mb_globals_dtor(&mbstring_globals
    TSRMLS_CC);
    mbstring/mbstring.c-#endif
    have no problem with it
    while some modules like
    $ grep 'ndef ZTS' */*.c -A2
    apc/php_apc.c:#ifndef ZTS
    apc/php_apc.c- php_apc_shutdown_globals(&apc_globals);
    apc/php_apc.c-#endif
    -
    eaccelerator/eaccelerator.c:#ifndef ZTS
    eaccelerator/eaccelerator.c-
    eaccelerator_globals_dtor(&eaccelerator_globals TSRMLS_CC);
    eaccelerator/eaccelerator.c-#endif
    when compiled as shared module, will crash
    eaccelerator(mmcache) workaround it by disabling the dtor.
    /*??? FIXME
    ZEND_INIT_MODULE_GLOBALS(eaccelerator, eaccelerator_init_globals,
    eaccelerator_globals_dtor);
    */
    ZEND_INIT_MODULE_GLOBALS(eaccelerator, eaccelerator_init_globals,
    NULL);
    --
    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


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
  • Steph Fox at May 31, 2006 at 10:40 am
    C:\sandbox\php5\Zend>grep -l -drecurse "HAVE_LIBDL" *.*
    ChangeLog
    zend.h
    Zend.m4
    zend_API.c
    zend_config.nw.h
    zend_config.w32.h

    Zend assumes Windows builds don't have HAVE_LIBDL defined. PHP - which only
    uses it in dl.c - assumes they do, and sets it during win32 config.

    ZEND_MODULE_DTOR - used in the module_registry hash - is defined as
    module_destructor(), which lives in zend_API.c and contains the following
    block.

    #if HAVE_LIBDL || defined(HAVE_MACH_O_DYLD_H)
    #if !(defined(NETWARE) && defined(APACHE_1_BUILD))
    if (module->handle) {
    DL_UNLOAD(module->handle);
    }
    #endif
    #endif

    So PHP-GTK's 'crime' is that it includes zend_API.h. Nice, eh?

    A better fix for Dmitry's initial win32 memory-setting issue would be to
    kill the HAVE_LIBDL line in config.w32.h.in (or replace it with #undef) and
    alter dl.c to deal with PHP_WIN32 directly.

    Dmitry, if you want to go through Zend's codebase and check the side-effects
    of every single setting in config.w32.h.in that wasn't in zend_config.w32.h
    before March 14th, that's groovy. But be warned, it takes a long time to
    test them...!

    - Steph


    ----- Original Message -----
    From: "Steph Fox" <steph@zend.com>
    To: "Xuefer" <xuefer@gmail.com>; "Andi Gutmans" <andi@zend.com>
    Cc: "internals" <internals@lists.php.net>
    Sent: Wednesday, May 31, 2006 9:28 AM
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    Fixing the config so that ZE doesn't think it's PHP might actually make
    Zend more stable too...

    I think I _know_ why other extension people are seeing a crash on
    ts_free_id(), but my biggest priority at present is getting the PHP-GTK
    crash out of the way.

    - Steph
    Without looking to deeply into this reincarnation my guess would be that
    for CLI, Zeev's approach makes good sense.

    Andi
    At 08:04 PM 5/27/2006, Steph Fox wrote:
    Thanks Xuefer...

    This bug's been extant for a long time, and I only found out why when I
    spent two days/nights trying to track down its history and mechanics.

    It's a pig.

    - Steph

    ----- Original Message ----- From: "Xuefer" <xuefer@gmail.com>
    To: "Steph Fox" <steph@zend.com>
    Cc: "internals" <internals@lists.php.net>
    Sent: Sunday, May 28, 2006 4:58 AM
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    i can confirm this on other extension.
    something like this
    grep free_id */*.c -B1 -A3
    mbstring/mbstring.c-#ifdef ZTS
    mbstring/mbstring.c: ts_free_id(mbstring_globals_id);
    mbstring/mbstring.c-#else
    mbstring/mbstring.c- _php_mb_globals_dtor(&mbstring_globals
    TSRMLS_CC);
    mbstring/mbstring.c-#endif
    have no problem with it
    while some modules like
    $ grep 'ndef ZTS' */*.c -A2
    apc/php_apc.c:#ifndef ZTS
    apc/php_apc.c- php_apc_shutdown_globals(&apc_globals);
    apc/php_apc.c-#endif
    -
    eaccelerator/eaccelerator.c:#ifndef ZTS
    eaccelerator/eaccelerator.c-
    eaccelerator_globals_dtor(&eaccelerator_globals TSRMLS_CC);
    eaccelerator/eaccelerator.c-#endif
    when compiled as shared module, will crash
    eaccelerator(mmcache) workaround it by disabling the dtor.
    /*??? FIXME
    ZEND_INIT_MODULE_GLOBALS(eaccelerator, eaccelerator_init_globals,
    eaccelerator_globals_dtor);
    */
    ZEND_INIT_MODULE_GLOBALS(eaccelerator, eaccelerator_init_globals,
    NULL);
    --
    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


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
  • Dmitry Stogov at May 31, 2006 at 11:20 am
    Oh well, now I see the difference.
    With my patch PHP starts call FreeLibrary() for dll extension.
    I am wonder why it wasn't called before. :)

    Probably some other bug that is the reason of the crash was masked by
    omitting FreeLibrary().
    I know Tony fixed some kind of such bugs in ext/tidy and ext/sybase.

    Probably php-gtk needs similar fix.

    All other systems except win32 already used common config file, and I don't
    see any reason for this exceptions.
    Especially because it was the reason of bug, and masked other bugs that may
    be reproduced on linux with ZTS.

    Thanks. Dmitry.

    -----Original Message-----
    From: Steph Fox
    Sent: Wednesday, May 31, 2006 2:38 PM
    To: Xuefer; Andi Gutmans; Dmitry Stogov
    Cc: internals
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    C:\sandbox\php5\Zend>grep -l -drecurse "HAVE_LIBDL" *.*
    ChangeLog zend.h Zend.m4 zend_API.c zend_config.nw.h zend_config.w32.h

    Zend assumes Windows builds don't have HAVE_LIBDL defined.
    PHP - which only
    uses it in dl.c - assumes they do, and sets it during win32 config.

    ZEND_MODULE_DTOR - used in the module_registry hash - is defined as
    module_destructor(), which lives in zend_API.c and contains
    the following
    block.

    #if HAVE_LIBDL || defined(HAVE_MACH_O_DYLD_H)
    #if !(defined(NETWARE) && defined(APACHE_1_BUILD))
    if (module->handle) {
    DL_UNLOAD(module->handle);
    }
    #endif
    #endif

    So PHP-GTK's 'crime' is that it includes zend_API.h. Nice, eh?

    A better fix for Dmitry's initial win32 memory-setting issue
    would be to
    kill the HAVE_LIBDL line in config.w32.h.in (or replace it
    with #undef) and
    alter dl.c to deal with PHP_WIN32 directly.

    Dmitry, if you want to go through Zend's codebase and check
    the side-effects
    of every single setting in config.w32.h.in that wasn't in
    zend_config.w32.h
    before March 14th, that's groovy. But be warned, it takes a
    long time to
    test them...!

    - Steph


    ----- Original Message -----
    From: "Steph Fox" <steph@zend.com>
    To: "Xuefer" <xuefer@gmail.com>; "Andi Gutmans" <andi@zend.com>
    Cc: "internals" <internals@lists.php.net>
    Sent: Wednesday, May 31, 2006 9:28 AM
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    Fixing the config so that ZE doesn't think it's PHP might actually
    make
    Zend more stable too...

    I think I _know_ why other extension people are seeing a crash on
    ts_free_id(), but my biggest priority at present is getting
    the PHP-GTK
    crash out of the way.

    - Steph
    Without looking to deeply into this reincarnation my guess
    would be
    that
    for CLI, Zeev's approach makes good sense.

    Andi
    At 08:04 PM 5/27/2006, Steph Fox wrote:
    Thanks Xuefer...

    This bug's been extant for a long time, and I only found
    out why when
    I
    spent two days/nights trying to track down its history and
    mechanics.
    It's a pig.

    - Steph

    ----- Original Message ----- From: "Xuefer" <xuefer@gmail.com>
    To: "Steph Fox" <steph@zend.com>
    Cc: "internals" <internals@lists.php.net>
    Sent: Sunday, May 28, 2006 4:58 AM
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    i can confirm this on other extension.
    something like this
    grep free_id */*.c -B1 -A3
    mbstring/mbstring.c-#ifdef ZTS
    mbstring/mbstring.c: ts_free_id(mbstring_globals_id);
    mbstring/mbstring.c-#else
    mbstring/mbstring.c- _php_mb_globals_dtor(&mbstring_globals
    TSRMLS_CC);
    mbstring/mbstring.c-#endif
    have no problem with it
    while some modules like
    $ grep 'ndef ZTS' */*.c -A2
    apc/php_apc.c:#ifndef ZTS
    apc/php_apc.c- php_apc_shutdown_globals(&apc_globals);
    apc/php_apc.c-#endif
    -
    eaccelerator/eaccelerator.c:#ifndef ZTS
    eaccelerator/eaccelerator.c-
    eaccelerator_globals_dtor(&eaccelerator_globals TSRMLS_CC);
    eaccelerator/eaccelerator.c-#endif
    when compiled as shared module, will crash
    eaccelerator(mmcache) workaround it by disabling the dtor. /*???
    FIXME
    ZEND_INIT_MODULE_GLOBALS(eaccelerator,
    eaccelerator_init_globals,
    eaccelerator_globals_dtor); */
    ZEND_INIT_MODULE_GLOBALS(eaccelerator,
    eaccelerator_init_globals,
    NULL);
    --
    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


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

  • Antony Dovgal at May 31, 2006 at 11:24 am

    On 31.05.2006 15:19, Dmitry Stogov wrote:
    Oh well, now I see the difference.
    With my patch PHP starts call FreeLibrary() for dll extension.
    I am wonder why it wasn't called before. :)

    Probably some other bug that is the reason of the crash was masked by
    omitting FreeLibrary().
    I know Tony fixed some kind of such bugs in ext/tidy and ext/sybase.
    See http://cvs.php.net/viewcvs.cgi/php-src/ext/sybase_ct/php_sybase_ct.c?r1=1.110&r2=1.111
    and http://cvs.php.net/viewcvs.cgi/php-src/ext/tidy/tidy.c?r1=1.85&r2=1.86
    Probably php-gtk needs similar fix.

    All other systems except win32 already used common config file, and I don't
    see any reason for this exceptions.
    Especially because it was the reason of bug, and masked other bugs that may
    be reproduced on linux with ZTS.
    --
    Wbr,
    Antony Dovgal
  • Steph Fox at May 31, 2006 at 11:30 am

    Oh well, now I see the difference.
    With my patch PHP starts call FreeLibrary() for dll extension.
    I am wonder why it wasn't called before. :)
    Pure luck, by the look of it :)
    Probably some other bug that is the reason of the crash was masked by
    omitting FreeLibrary().
    I know Tony fixed some kind of such bugs in ext/tidy and ext/sybase.
    Yes, he gave those extensions the ts_free_id() workaround I mentioned a
    looooooooooong time ago when I first started looking into this.
    Probably php-gtk needs similar fix.
    That workaround didn't work for PHP-GTK. I tried that first. That's why I
    need you to fix this bug rather than me just cover it up. The only thing
    that works for PHP-GTK is to either avoid tsrm_shutdown() completely (via
    Zeev's suggestion of commenting out the call in php_cli.c), or to fix the
    bug that makes reaching it a problem.
    All other systems except win32 already used common config file, and I
    don't
    see any reason for this exceptions.
    I don't know or care what other systems do... how's that even relevant?
    Especially because it was the reason of bug, and masked other bugs that
    may
    be reproduced on linux with ZTS.
    Sorry, I didn't parse that... can you rephrase?
    Thanks. Dmitry.
    Cheers,
    - Steph
  • Dmitry Stogov at May 31, 2006 at 12:56 pm
    Steph,

    Commenting tsrm_shutdown() or FreeLibrary() is just hidding real bugs.
    Of course this is a solution, but not excellent.

    Right now I haven't enough time even for ZE and PHP themself, so I don't
    like spent it looking into php-gtk on windows.
    (I don't know GTK at all).

    Do you know any other extension from PHP distribution that cause the same
    crash?
    Could you provide instruction how to reproduce it?

    Thanks. Dmitry.
    -----Original Message-----
    From: Steph Fox
    Sent: Wednesday, May 31, 2006 3:28 PM
    To: Dmitry Stogov; 'Xuefer'; 'Andi Gutmans'
    Cc: 'internals'; Antony Dovgal
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    Oh well, now I see the difference.
    With my patch PHP starts call FreeLibrary() for dll extension. I am
    wonder why it wasn't called before. :)
    Pure luck, by the look of it :)
    Probably some other bug that is the reason of the crash was masked by
    omitting FreeLibrary(). I know Tony fixed some kind of such bugs in
    ext/tidy and ext/sybase.
    Yes, he gave those extensions the ts_free_id() workaround I
    mentioned a
    looooooooooong time ago when I first started looking into this.
    Probably php-gtk needs similar fix.
    That workaround didn't work for PHP-GTK. I tried that first.
    That's why I
    need you to fix this bug rather than me just cover it up. The
    only thing
    that works for PHP-GTK is to either avoid tsrm_shutdown()
    completely (via
    Zeev's suggestion of commenting out the call in php_cli.c),
    or to fix the
    bug that makes reaching it a problem.
    All other systems except win32 already used common config
    file, and I
    don't
    see any reason for this exceptions.
    I don't know or care what other systems do... how's that even
    relevant?
    Especially because it was the reason of bug, and masked other bugs
    that
    may
    be reproduced on linux with ZTS.
    Sorry, I didn't parse that... can you rephrase?
    Thanks. Dmitry.
    Cheers,
    - Steph

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

  • Steph Fox at May 31, 2006 at 1:00 pm
    At the moment I'm seeing it with Tidy under 5_2. Just about to get Tony to
    check.

    ----- Original Message -----
    From: "Dmitry Stogov" <dmitry@zend.com>
    To: "'Steph Fox'" <steph@zend.com>; "'Xuefer'" <xuefer@gmail.com>; "'Andi
    Gutmans'" <andi@zend.com>
    Cc: "'internals'" <internals@lists.php.net>; "'Antony Dovgal'"
    <antony@zend.com>
    Sent: Wednesday, May 31, 2006 2:55 PM
    Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    Steph,

    Commenting tsrm_shutdown() or FreeLibrary() is just hidding real bugs.
    Of course this is a solution, but not excellent.

    Right now I haven't enough time even for ZE and PHP themself, so I don't
    like spent it looking into php-gtk on windows.
    (I don't know GTK at all).

    Do you know any other extension from PHP distribution that cause the same
    crash?
    Could you provide instruction how to reproduce it?

    Thanks. Dmitry.
    -----Original Message-----
    From: Steph Fox
    Sent: Wednesday, May 31, 2006 3:28 PM
    To: Dmitry Stogov; 'Xuefer'; 'Andi Gutmans'
    Cc: 'internals'; Antony Dovgal
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    Oh well, now I see the difference.
    With my patch PHP starts call FreeLibrary() for dll extension. I am
    wonder why it wasn't called before. :)
    Pure luck, by the look of it :)
    Probably some other bug that is the reason of the crash was masked by
    omitting FreeLibrary(). I know Tony fixed some kind of such bugs in
    ext/tidy and ext/sybase.
    Yes, he gave those extensions the ts_free_id() workaround I
    mentioned a
    looooooooooong time ago when I first started looking into this.
    Probably php-gtk needs similar fix.
    That workaround didn't work for PHP-GTK. I tried that first.
    That's why I
    need you to fix this bug rather than me just cover it up. The
    only thing
    that works for PHP-GTK is to either avoid tsrm_shutdown()
    completely (via
    Zeev's suggestion of commenting out the call in php_cli.c),
    or to fix the
    bug that makes reaching it a problem.
    All other systems except win32 already used common config
    file, and I
    don't
    see any reason for this exceptions.
    I don't know or care what other systems do... how's that even
    relevant?
    Especially because it was the reason of bug, and masked other bugs
    that
    may
    be reproduced on linux with ZTS.
    Sorry, I didn't parse that... can you rephrase?
    Thanks. Dmitry.
    Cheers,
    - Steph

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php



    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
  • Andi Gutmans at Jun 1, 2006 at 4:24 am

    At 04:28 AM 5/31/2006, Steph Fox wrote:
    Probably some other bug that is the reason of the crash was masked by
    omitting FreeLibrary().
    I know Tony fixed some kind of such bugs in ext/tidy and ext/sybase.
    Yes, he gave those extensions the ts_free_id() workaround I
    mentioned a looooooooooong time ago when I first started looking into this.
    I'm a bit behind so sorry if this has been answered already. I don't
    think ts_free_id() is a workaround but it's actually correct. We
    should free the resources of the extension during MSHUTDOWN and
    that's the way to do it in ZTS. Good chance that the crash is
    actually a bug which needs fixing although there could also be a bug lurking.

    Andi
  • Steph Fox at Jun 1, 2006 at 4:50 am

    I'm a bit behind so sorry if this has been answered already. I don't think
    ts_free_id() is a workaround but it's actually correct.
    ts_free_id() would be a correct workaround if it came from zend_shutdown().
    How's it right to suddenly force EVERY extension author to add it to their
    code individually?

    We
    should free the resources of the extension during MSHUTDOWN and that's the
    way to do it in ZTS. Good chance that the crash is actually a bug which
    needs fixing although there could also be a bug lurking.

    Andi
  • Dmitry Stogov at Jun 1, 2006 at 8:21 am
    I agree.
    I'll try to make it work from inside zend_shudown() but probably it will
    requre modification of EVERY extension that uses module_globals in any case.

    Thanks. Dmitry.
    -----Original Message-----
    From: Steph Fox
    Sent: Thursday, June 01, 2006 8:48 AM
    To: Dmitry Stogov; 'Xuefer'; Andi Gutmans
    Cc: 'internals'; Antony Dovgal
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    I'm a bit behind so sorry if this has been answered
    already. I don't
    think
    ts_free_id() is a workaround but it's actually correct.
    ts_free_id() would be a correct workaround if it came from
    zend_shutdown().
    How's it right to suddenly force EVERY extension author to
    add it to their
    code individually?

    We
    should free the resources of the extension during MSHUTDOWN
    and that's
    the
    way to do it in ZTS. Good chance that the crash is actually
    a bug which
    needs fixing although there could also be a bug lurking.

    Andi
  • Steph Fox at Jun 1, 2006 at 5:21 pm
    I already wasted several hours on that :)

    I agree that making it work from inside zend_shutdown would be the smart
    approach, but don't see why you think it will need any extension mods
    (although it might need minor TSRM mods to flag 'done' table entries in all
    cases). The sane thing would be to call ts_free_id() from the
    module_destructor function somehow... but.... the globals_id field isn't
    populated in the zend_module_entry struct currently, and my attempts to
    populate it haven't been successful to date.

    ----- Original Message -----
    From: "Dmitry Stogov" <dmitry@zend.com>
    To: "'Steph Fox'" <steph@zend.com>; "'Xuefer'" <xuefer@gmail.com>; "'Andi
    Gutmans'" <andi@zend.com>
    Cc: "'internals'" <internals@lists.php.net>; "'Antony Dovgal'"
    <antony@zend.com>
    Sent: Thursday, June 01, 2006 8:34 AM
    Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    I agree.
    I'll try to make it work from inside zend_shudown() but probably it will
    requre modification of EVERY extension that uses module_globals in any case.

    Thanks. Dmitry.
    -----Original Message-----
    From: Steph Fox
    Sent: Thursday, June 01, 2006 8:48 AM
    To: Dmitry Stogov; 'Xuefer'; Andi Gutmans
    Cc: 'internals'; Antony Dovgal
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    I'm a bit behind so sorry if this has been answered
    already. I don't
    think
    ts_free_id() is a workaround but it's actually correct.
    ts_free_id() would be a correct workaround if it came from
    zend_shutdown().
    How's it right to suddenly force EVERY extension author to
    add it to their
    code individually?

    We
    should free the resources of the extension during MSHUTDOWN
    and that's
    the
    way to do it in ZTS. Good chance that the crash is actually
    a bug which
    needs fixing although there could also be a bug lurking.

    Andi


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
  • Dmitry Stogov at Jun 2, 2006 at 6:11 am
    I am working in this way, but this willnot help you with php-gtk for php-5.1

    Dmitry.
    -----Original Message-----
    From: Steph Fox
    Sent: Thursday, June 01, 2006 9:19 PM
    To: Dmitry Stogov; 'Xuefer'; 'Andi Gutmans'
    Cc: 'internals'; 'Antony Dovgal'
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    I already wasted several hours on that :)

    I agree that making it work from inside zend_shutdown would
    be the smart
    approach, but don't see why you think it will need any extension mods
    (although it might need minor TSRM mods to flag 'done' table
    entries in all
    cases). The sane thing would be to call ts_free_id() from the
    module_destructor function somehow... but.... the globals_id
    field isn't
    populated in the zend_module_entry struct currently, and my
    attempts to
    populate it haven't been successful to date.

    ----- Original Message -----
    From: "Dmitry Stogov" <dmitry@zend.com>
    To: "'Steph Fox'" <steph@zend.com>; "'Xuefer'"
    <xuefer@gmail.com>; "'Andi
    Gutmans'" <andi@zend.com>
    Cc: "'internals'" <internals@lists.php.net>; "'Antony Dovgal'"
    <antony@zend.com>
    Sent: Thursday, June 01, 2006 8:34 AM
    Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    I agree.
    I'll try to make it work from inside zend_shudown() but
    probably it will requre modification of EVERY extension that
    uses module_globals in any case.

    Thanks. Dmitry.
    -----Original Message-----
    From: Steph Fox
    Sent: Thursday, June 01, 2006 8:48 AM
    To: Dmitry Stogov; 'Xuefer'; Andi Gutmans
    Cc: 'internals'; Antony Dovgal
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    I'm a bit behind so sorry if this has been answered
    already. I don't
    think
    ts_free_id() is a workaround but it's actually correct.
    ts_free_id() would be a correct workaround if it came from
    zend_shutdown(). How's it right to suddenly force EVERY extension
    author to add it to their
    code individually?

    We
    should free the resources of the extension during MSHUTDOWN
    and that's
    the
    way to do it in ZTS. Good chance that the crash is actually
    a bug which
    needs fixing although there could also be a bug lurking.

    Andi


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com


  • Steph Fox at Jun 2, 2006 at 6:23 am
    Did you see my patch?

    ----- Original Message -----
    From: "Dmitry Stogov" <dmitry@zend.com>
    To: "'Steph Fox'" <steph@zend.com>; "'Xuefer'" <xuefer@gmail.com>; "'Andi
    Gutmans'" <andi@zend.com>
    Cc: "'internals'" <internals@lists.php.net>; "'Antony Dovgal'"
    <antony@zend.com>
    Sent: Friday, June 02, 2006 8:11 AM
    Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    I am working in this way, but this willnot help you with php-gtk for
    php-5.1

    Dmitry.
    -----Original Message-----
    From: Steph Fox
    Sent: Thursday, June 01, 2006 9:19 PM
    To: Dmitry Stogov; 'Xuefer'; 'Andi Gutmans'
    Cc: 'internals'; 'Antony Dovgal'
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    I already wasted several hours on that :)

    I agree that making it work from inside zend_shutdown would
    be the smart
    approach, but don't see why you think it will need any extension mods
    (although it might need minor TSRM mods to flag 'done' table
    entries in all
    cases). The sane thing would be to call ts_free_id() from the
    module_destructor function somehow... but.... the globals_id
    field isn't
    populated in the zend_module_entry struct currently, and my
    attempts to
    populate it haven't been successful to date.

    ----- Original Message -----
    From: "Dmitry Stogov" <dmitry@zend.com>
    To: "'Steph Fox'" <steph@zend.com>; "'Xuefer'"
    <xuefer@gmail.com>; "'Andi
    Gutmans'" <andi@zend.com>
    Cc: "'internals'" <internals@lists.php.net>; "'Antony Dovgal'"
    <antony@zend.com>
    Sent: Thursday, June 01, 2006 8:34 AM
    Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    I agree.
    I'll try to make it work from inside zend_shudown() but
    probably it will requre modification of EVERY extension that
    uses module_globals in any case.

    Thanks. Dmitry.
    -----Original Message-----
    From: Steph Fox
    Sent: Thursday, June 01, 2006 8:48 AM
    To: Dmitry Stogov; 'Xuefer'; Andi Gutmans
    Cc: 'internals'; Antony Dovgal
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    I'm a bit behind so sorry if this has been answered
    already. I don't
    think
    ts_free_id() is a workaround but it's actually correct.
    ts_free_id() would be a correct workaround if it came from
    zend_shutdown(). How's it right to suddenly force EVERY extension
    author to add it to their
    code individually?

    We
    should free the resources of the extension during MSHUTDOWN
    and that's
    the
    way to do it in ZTS. Good chance that the crash is actually
    a bug which
    needs fixing although there could also be a bug lurking.

    Andi


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com




    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
  • Steph Fox at May 29, 2006 at 9:42 am
    Hi all,

    I've spent a fun weekend debugging TSRM and bits of ZE2, having finally
    figured that the zend_compiler_globals dtor was the point of failure here.

    TSRM needs to mark resources as 'done' following a free and doesn't in most
    cases, but that's actually not the main problem we have in PHP-GTK (although
    fixing it may well solve everybody else's, I'll check that on my travels).

    Dmitry's "Optimized cleanup loops on request shutdown" commit(s) spanning
    the 13th and 14th March broke Andrei's 'EG(full_tables_cleanup) = 1' ruse
    (we needed user classes to be cleaned and internal classes to stay), but it
    also broke TSRM shutdown completely for us. PHP-GTK classes are recognized
    as being internal, but only the first one ever reaches the dtor - even when
    there are no user-defined classes.

    zend_hash_reverse_apply() is called at that point, so I'm guessing there's a
    reentrancy issue behind my access violation crash.

    I'll get back to this when I get some time, in the meantime if anyone
    (Dmitry?) wants to play with this you need to know that I can't put the 5_2
    compat stuff into CVS until Andrei OKs it, so PHP-GTK HEAD has to be built
    against PHP_5_1 branch at present (anything after March 14th will do).

    - Steph

    Under CLI ZTS build, when loading a PHP-GTK 2 .dll built against anything
    this side of PHP 5.1.2 release, I'm seeing an 'access violation' crash on
    reaching:

    if (resource_types_table && !resource_types_table[j].done &&
    resource_types_table[j].dtor) {
    resource_types_table[j].dtor(p->storage[j], &p->storage);
    }

    Similar code is also used in:

    tsrm_free_interpreter_context()
    ts_free_thread()
    ts_free_worker_threads()
    ts_free_id()

    I thought ts_free_thread() was crashing at that line too at first, but
    that turned out to be because there's no 'done' check there, i.e. double
    dtors are possible via some functions. It's still vaguely possible there's
    a double flypast causing the crash I'm seeing, but I have everything I
    know about protected now. (On my laptop that is.)

    Eventually I found the resource id for PHP-GTK - the only extension I'm
    loading during runtime, via php.ini - is 32nd out of a possible 32.
    "Eventually", because that means I can't use ts_free_id() to avoid the
    crash as advised by Frank (and Tony, and Dmitry, and anyone else who ever
    used that MSHUTDOWN workaround for CLI). Interesting too, because the
    resource that causes the crash appears to be something completely other.
    Tracking down resource id #5 - and that's all I know about it apart from
    it crashes - is a barrel of laughs, I'll let y'all know if I ever find out
    which of the many possible extensions/files in ext/standard or core it is.

    Short version: One line is problematic, and only in one function, and
    presumably only under CLI SAPI. (CGI already doesn't call tsrm_shutdown(),
    thanks to similar issues some 3 years ago).

    The question is whether to take 'the Zeev approach' and simply comment out
    the tsrm_shutdown() call at the end of sapi/cli/php_cli.c, or whether to
    spend time knitting up a fine-grained approach to prevent the one bad line
    in the function from being called in single-threaded environments? I think
    I've given up on the idea of actually resolving the bug now...

    Thoughts?

    - oh, and don't make one of them 'chicken-and-egg' - this is definitively
    NOT related to the shutdown order in main.c!!!!!

    - Steph

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
  • Edin Kadribasic at May 29, 2006 at 10:43 am
    Hi,

    Yes, something broke while we were at 5.1.3-dev.

    It would be really nice if Dmitry could have a look at this. We have
    many reports that things have gotten much more ustable on Windows since
    5.1.2.

    Edin


    Steph Fox wrote:
    Hi all,

    I've spent a fun weekend debugging TSRM and bits of ZE2, having finally
    figured that the zend_compiler_globals dtor was the point of failure here.

    TSRM needs to mark resources as 'done' following a free and doesn't in
    most cases, but that's actually not the main problem we have in PHP-GTK
    (although fixing it may well solve everybody else's, I'll check that on
    my travels).

    Dmitry's "Optimized cleanup loops on request shutdown" commit(s)
    spanning the 13th and 14th March broke Andrei's 'EG(full_tables_cleanup)
    = 1' ruse (we needed user classes to be cleaned and internal classes to
    stay), but it also broke TSRM shutdown completely for us. PHP-GTK
    classes are recognized as being internal, but only the first one ever
    reaches the dtor - even when there are no user-defined classes.

    zend_hash_reverse_apply() is called at that point, so I'm guessing
    there's a reentrancy issue behind my access violation crash.

    I'll get back to this when I get some time, in the meantime if anyone
    (Dmitry?) wants to play with this you need to know that I can't put the
    5_2 compat stuff into CVS until Andrei OKs it, so PHP-GTK HEAD has to be
    built against PHP_5_1 branch at present (anything after March 14th will
    do).

    - Steph

    Under CLI ZTS build, when loading a PHP-GTK 2 .dll built against
    anything this side of PHP 5.1.2 release, I'm seeing an 'access
    violation' crash on reaching:

    if (resource_types_table && !resource_types_table[j].done &&
    resource_types_table[j].dtor) {
    resource_types_table[j].dtor(p->storage[j], &p->storage);
    }

    Similar code is also used in:

    tsrm_free_interpreter_context()
    ts_free_thread()
    ts_free_worker_threads()
    ts_free_id()

    I thought ts_free_thread() was crashing at that line too at first, but
    that turned out to be because there's no 'done' check there, i.e.
    double dtors are possible via some functions. It's still vaguely
    possible there's a double flypast causing the crash I'm seeing, but I
    have everything I know about protected now. (On my laptop that is.)

    Eventually I found the resource id for PHP-GTK - the only extension
    I'm loading during runtime, via php.ini - is 32nd out of a possible
    32. "Eventually", because that means I can't use ts_free_id() to avoid
    the crash as advised by Frank (and Tony, and Dmitry, and anyone else
    who ever used that MSHUTDOWN workaround for CLI). Interesting too,
    because the resource that causes the crash appears to be something
    completely other. Tracking down resource id #5 - and that's all I know
    about it apart from it crashes - is a barrel of laughs, I'll let y'all
    know if I ever find out which of the many possible extensions/files in
    ext/standard or core it is.

    Short version: One line is problematic, and only in one function, and
    presumably only under CLI SAPI. (CGI already doesn't call
    tsrm_shutdown(), thanks to similar issues some 3 years ago).

    The question is whether to take 'the Zeev approach' and simply comment
    out the tsrm_shutdown() call at the end of sapi/cli/php_cli.c, or
    whether to spend time knitting up a fine-grained approach to prevent
    the one bad line in the function from being called in single-threaded
    environments? I think I've given up on the idea of actually resolving
    the bug now...

    Thoughts?

    - oh, and don't make one of them 'chicken-and-egg' - this is
    definitively NOT related to the shutdown order in main.c!!!!!

    - Steph

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
  • Dmitry Stogov at May 29, 2006 at 3:55 pm
    Hi Steph,

    I have no idea what is wrong with optimized class/functions tables cleanup.
    In case if EG(full_tables_cleanup) is set, the behavior should be exactly
    the same as before patch.
    PHP uses EG(full_table_cleanup) only for dl(), but I do't know how php-gtk
    uses it.

    Thanks. Dmitry.
    -----Original Message-----
    From: Steph Fox
    Sent: Monday, May 29, 2006 1:40 PM
    To: internals
    Cc: PHP-GTK dev; Dmitry Stogov
    Subject: [PHP-DEV] Ides of March [WAS: tsrm_shutdown() and
    the CLI SAPI]


    Hi all,

    I've spent a fun weekend debugging TSRM and bits of ZE2,
    having finally
    figured that the zend_compiler_globals dtor was the point of
    failure here.

    TSRM needs to mark resources as 'done' following a free and
    doesn't in most
    cases, but that's actually not the main problem we have in
    PHP-GTK (although
    fixing it may well solve everybody else's, I'll check that on
    my travels).

    Dmitry's "Optimized cleanup loops on request shutdown"
    commit(s) spanning
    the 13th and 14th March broke Andrei's
    'EG(full_tables_cleanup) = 1' ruse
    (we needed user classes to be cleaned and internal classes to
    stay), but it
    also broke TSRM shutdown completely for us. PHP-GTK classes
    are recognized
    as being internal, but only the first one ever reaches the
    dtor - even when
    there are no user-defined classes.

    zend_hash_reverse_apply() is called at that point, so I'm
    guessing there's a
    reentrancy issue behind my access violation crash.

    I'll get back to this when I get some time, in the meantime if anyone
    (Dmitry?) wants to play with this you need to know that I
    can't put the 5_2
    compat stuff into CVS until Andrei OKs it, so PHP-GTK HEAD
    has to be built
    against PHP_5_1 branch at present (anything after March 14th will do).

    - Steph

    Under CLI ZTS build, when loading a PHP-GTK 2 .dll built against
    anything
    this side of PHP 5.1.2 release, I'm seeing an 'access
    violation' crash on
    reaching:

    if (resource_types_table && !resource_types_table[j].done &&
    resource_types_table[j].dtor) {
    resource_types_table[j].dtor(p->storage[j], &p->storage);
    }

    Similar code is also used in:

    tsrm_free_interpreter_context()
    ts_free_thread()
    ts_free_worker_threads()
    ts_free_id()

    I thought ts_free_thread() was crashing at that line too at
    first, but
    that turned out to be because there's no 'done' check
    there, i.e. double
    dtors are possible via some functions. It's still vaguely
    possible there's
    a double flypast causing the crash I'm seeing, but I have
    everything I
    know about protected now. (On my laptop that is.)

    Eventually I found the resource id for PHP-GTK - the only extension
    I'm
    loading during runtime, via php.ini - is 32nd out of a possible 32.
    "Eventually", because that means I can't use ts_free_id()
    to avoid the
    crash as advised by Frank (and Tony, and Dmitry, and anyone
    else who ever
    used that MSHUTDOWN workaround for CLI). Interesting too,
    because the
    resource that causes the crash appears to be something
    completely other.
    Tracking down resource id #5 - and that's all I know about
    it apart from
    it crashes - is a barrel of laughs, I'll let y'all know if
    I ever find out
    which of the many possible extensions/files in ext/standard
    or core it is.
    Short version: One line is problematic, and only in one
    function, and
    presumably only under CLI SAPI. (CGI already doesn't call
    tsrm_shutdown(),
    thanks to similar issues some 3 years ago).

    The question is whether to take 'the Zeev approach' and
    simply comment
    out
    the tsrm_shutdown() call at the end of sapi/cli/php_cli.c,
    or whether to
    spend time knitting up a fine-grained approach to prevent
    the one bad line
    in the function from being called in single-threaded
    environments? I think
    I've given up on the idea of actually resolving the bug now...

    Thoughts?

    - oh, and don't make one of them 'chicken-and-egg' - this is
    definitively
    NOT related to the shutdown order in main.c!!!!!

    - Steph

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

  • Steph Fox at May 29, 2006 at 9:32 pm
    Hi Dmitry,

    Finally cracked it, and you're right it had nothing to do with the suspected
    optimizations. There was a win32 memory fix where you included the PHP win32
    config file in the Zend one, confusing heck out of TSRM's totally
    independent (until it meets Zend) alloca definition, which is some way
    before Zend meets PHP's. They all need to match.

    Can you find some other way to fix #36568 pliz?

    I'll take another look at those flags in TSRM itself for the work-aroundable
    shutdown issues when I've caught up with the weeklies...

    - Steph

    ps I knew it had to be you - nobody else did anything major in core that
    week ;)


    Hi Steph,

    I have no idea what is wrong with optimized class/functions tables
    cleanup.
    In case if EG(full_tables_cleanup) is set, the behavior should be exactly
    the same as before patch.
    PHP uses EG(full_table_cleanup) only for dl(), but I do't know how php-gtk
    uses it.

    Thanks. Dmitry.
    -----Original Message-----
    From: Steph Fox
    Sent: Monday, May 29, 2006 1:40 PM
    To: internals
    Cc: PHP-GTK dev; Dmitry Stogov
    Subject: [PHP-DEV] Ides of March [WAS: tsrm_shutdown() and
    the CLI SAPI]


    Hi all,

    I've spent a fun weekend debugging TSRM and bits of ZE2,
    having finally
    figured that the zend_compiler_globals dtor was the point of
    failure here.

    TSRM needs to mark resources as 'done' following a free and
    doesn't in most
    cases, but that's actually not the main problem we have in
    PHP-GTK (although
    fixing it may well solve everybody else's, I'll check that on
    my travels).

    Dmitry's "Optimized cleanup loops on request shutdown"
    commit(s) spanning
    the 13th and 14th March broke Andrei's
    'EG(full_tables_cleanup) = 1' ruse
    (we needed user classes to be cleaned and internal classes to
    stay), but it
    also broke TSRM shutdown completely for us. PHP-GTK classes
    are recognized
    as being internal, but only the first one ever reaches the
    dtor - even when
    there are no user-defined classes.

    zend_hash_reverse_apply() is called at that point, so I'm
    guessing there's a
    reentrancy issue behind my access violation crash.

    I'll get back to this when I get some time, in the meantime if anyone
    (Dmitry?) wants to play with this you need to know that I
    can't put the 5_2
    compat stuff into CVS until Andrei OKs it, so PHP-GTK HEAD
    has to be built
    against PHP_5_1 branch at present (anything after March 14th will do).

    - Steph

    Under CLI ZTS build, when loading a PHP-GTK 2 .dll built against
    anything
    this side of PHP 5.1.2 release, I'm seeing an 'access
    violation' crash on
    reaching:

    if (resource_types_table && !resource_types_table[j].done &&
    resource_types_table[j].dtor) {
    resource_types_table[j].dtor(p->storage[j], &p->storage);
    }

    Similar code is also used in:

    tsrm_free_interpreter_context()
    ts_free_thread()
    ts_free_worker_threads()
    ts_free_id()

    I thought ts_free_thread() was crashing at that line too at
    first, but
    that turned out to be because there's no 'done' check
    there, i.e. double
    dtors are possible via some functions. It's still vaguely
    possible there's
    a double flypast causing the crash I'm seeing, but I have
    everything I
    know about protected now. (On my laptop that is.)

    Eventually I found the resource id for PHP-GTK - the only extension
    I'm
    loading during runtime, via php.ini - is 32nd out of a possible 32.
    "Eventually", because that means I can't use ts_free_id()
    to avoid the
    crash as advised by Frank (and Tony, and Dmitry, and anyone
    else who ever
    used that MSHUTDOWN workaround for CLI). Interesting too,
    because the
    resource that causes the crash appears to be something
    completely other.
    Tracking down resource id #5 - and that's all I know about
    it apart from
    it crashes - is a barrel of laughs, I'll let y'all know if
    I ever find out
    which of the many possible extensions/files in ext/standard
    or core it is.
    Short version: One line is problematic, and only in one
    function, and
    presumably only under CLI SAPI. (CGI already doesn't call
    tsrm_shutdown(),
    thanks to similar issues some 3 years ago).

    The question is whether to take 'the Zeev approach' and
    simply comment
    out
    the tsrm_shutdown() call at the end of sapi/cli/php_cli.c,
    or whether to
    spend time knitting up a fine-grained approach to prevent
    the one bad line
    in the function from being called in single-threaded
    environments? I think
    I've given up on the idea of actually resolving the bug now...

    Thoughts?

    - oh, and don't make one of them 'chicken-and-egg' - this is
    definitively
    NOT related to the shutdown order in main.c!!!!!

    - Steph

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
    --
    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


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
  • Dmitry Stogov at May 30, 2006 at 3:36 am
    Hi Steph,

    As I remember this patch modified "zend_config.w32.h". It made inclusion of
    "main/config.w32.h" in the same way as on all other systems.
    How it affects TSRM?
    May be I forgot something.

    Thanks. Dmitry.
    -----Original Message-----
    From: Steph Fox
    Sent: Tuesday, May 30, 2006 1:30 AM
    To: Dmitry Stogov
    Cc: 'PHP-GTK dev'; 'internals'
    Subject: Re: [PHP-DEV] Ides of March [WAS: tsrm_shutdown()
    and the CLI SAPI]


    Hi Dmitry,

    Finally cracked it, and you're right it had nothing to do
    with the suspected
    optimizations. There was a win32 memory fix where you
    included the PHP win32
    config file in the Zend one, confusing heck out of TSRM's totally
    independent (until it meets Zend) alloca definition, which is
    some way
    before Zend meets PHP's. They all need to match.

    Can you find some other way to fix #36568 pliz?

    I'll take another look at those flags in TSRM itself for the
    work-aroundable
    shutdown issues when I've caught up with the weeklies...

    - Steph

    ps I knew it had to be you - nobody else did anything major
    in core that
    week ;)


    Hi Steph,

    I have no idea what is wrong with optimized class/functions tables
    cleanup.
    In case if EG(full_tables_cleanup) is set, the behavior
    should be exactly
    the same as before patch.
    PHP uses EG(full_table_cleanup) only for dl(), but I do't
    know how php-gtk
    uses it.

    Thanks. Dmitry.
    -----Original Message-----
    From: Steph Fox
    Sent: Monday, May 29, 2006 1:40 PM
    To: internals
    Cc: PHP-GTK dev; Dmitry Stogov
    Subject: [PHP-DEV] Ides of March [WAS: tsrm_shutdown() and the CLI
    SAPI]


    Hi all,

    I've spent a fun weekend debugging TSRM and bits of ZE2, having
    finally figured that the zend_compiler_globals dtor was
    the point of
    failure here.

    TSRM needs to mark resources as 'done' following a free
    and doesn't
    in most cases, but that's actually not the main problem we have in
    PHP-GTK (although
    fixing it may well solve everybody else's, I'll check that on
    my travels).

    Dmitry's "Optimized cleanup loops on request shutdown"
    commit(s) spanning
    the 13th and 14th March broke Andrei's
    'EG(full_tables_cleanup) = 1' ruse
    (we needed user classes to be cleaned and internal classes
    to stay),
    but it also broke TSRM shutdown completely for us. PHP-GTK classes
    are recognized
    as being internal, but only the first one ever reaches the
    dtor - even when
    there are no user-defined classes.

    zend_hash_reverse_apply() is called at that point, so I'm guessing
    there's a reentrancy issue behind my access violation crash.

    I'll get back to this when I get some time, in the
    meantime if anyone
    (Dmitry?) wants to play with this you need to know that I
    can't put
    the 5_2 compat stuff into CVS until Andrei OKs it, so PHP-GTK HEAD
    has to be built
    against PHP_5_1 branch at present (anything after March
    14th will do).
    - Steph

    Under CLI ZTS build, when loading a PHP-GTK 2 .dll built against
    anything this side of PHP 5.1.2 release, I'm seeing an 'access
    violation' crash on
    reaching:

    if (resource_types_table && !resource_types_table[j].done &&
    resource_types_table[j].dtor) {
    resource_types_table[j].dtor(p->storage[j],
    &p->storage);
    }

    Similar code is also used in:

    tsrm_free_interpreter_context()
    ts_free_thread()
    ts_free_worker_threads()
    ts_free_id()

    I thought ts_free_thread() was crashing at that line too at
    first, but
    that turned out to be because there's no 'done' check
    there, i.e. double
    dtors are possible via some functions. It's still vaguely
    possible there's
    a double flypast causing the crash I'm seeing, but I have
    everything I
    know about protected now. (On my laptop that is.)

    Eventually I found the resource id for PHP-GTK - the
    only extension
    I'm loading during runtime, via php.ini - is 32nd out of
    a possible
    32. "Eventually", because that means I can't use ts_free_id()
    to avoid the
    crash as advised by Frank (and Tony, and Dmitry, and anyone
    else who ever
    used that MSHUTDOWN workaround for CLI). Interesting too,
    because the
    resource that causes the crash appears to be something
    completely other.
    Tracking down resource id #5 - and that's all I know about
    it apart from
    it crashes - is a barrel of laughs, I'll let y'all know if
    I ever find out
    which of the many possible extensions/files in ext/standard
    or core it is.
    Short version: One line is problematic, and only in one
    function, and
    presumably only under CLI SAPI. (CGI already doesn't call
    tsrm_shutdown(),
    thanks to similar issues some 3 years ago).

    The question is whether to take 'the Zeev approach' and
    simply comment
    out
    the tsrm_shutdown() call at the end of sapi/cli/php_cli.c,
    or whether to
    spend time knitting up a fine-grained approach to prevent
    the one bad line
    in the function from being called in single-threaded
    environments? I think
    I've given up on the idea of actually resolving the bug now...

    Thoughts?

    - oh, and don't make one of them 'chicken-and-egg' - this is
    definitively NOT related to the shutdown order in main.c!!!!!

    - Steph

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
    --
    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


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

  • Steph Fox at May 30, 2006 at 4:17 pm
    Short version:

    zend_config.w32.h

    #define USE_ZEND_ALLOC 1
    -#define HAVE_ALLOCA 1
    -#define HAVE_LIMITS_H 1
    +
    +#include <../main/config.w32.h>

    In theory that's OK because main/config.w32.h has '#define HAVE_ALLOCA 1'
    halfway down it.

    In practice, the order actually matters.

    - Steph

    ----- Original Message -----
    From: "Dmitry Stogov" <dmitry@zend.com>
    To: "'Steph Fox'" <steph@zend.com>
    Cc: "'PHP-GTK dev'" <php-gtk-dev@lists.php.net>; "'internals'"
    <internals@lists.php.net>
    Sent: Tuesday, May 30, 2006 5:36 AM
    Subject: RE: [PHP-DEV] Ides of March [WAS: tsrm_shutdown() and the CLI SAPI]

    Hi Steph,

    As I remember this patch modified "zend_config.w32.h". It made inclusion
    of
    "main/config.w32.h" in the same way as on all other systems.
    How it affects TSRM?
    May be I forgot something.

    Thanks. Dmitry.
    -----Original Message-----
    From: Steph Fox
    Sent: Tuesday, May 30, 2006 1:30 AM
    To: Dmitry Stogov
    Cc: 'PHP-GTK dev'; 'internals'
    Subject: Re: [PHP-DEV] Ides of March [WAS: tsrm_shutdown()
    and the CLI SAPI]


    Hi Dmitry,

    Finally cracked it, and you're right it had nothing to do
    with the suspected
    optimizations. There was a win32 memory fix where you
    included the PHP win32
    config file in the Zend one, confusing heck out of TSRM's totally
    independent (until it meets Zend) alloca definition, which is
    some way
    before Zend meets PHP's. They all need to match.

    Can you find some other way to fix #36568 pliz?

    I'll take another look at those flags in TSRM itself for the
    work-aroundable
    shutdown issues when I've caught up with the weeklies...

    - Steph

    ps I knew it had to be you - nobody else did anything major
    in core that
    week ;)


    Hi Steph,

    I have no idea what is wrong with optimized class/functions tables
    cleanup.
    In case if EG(full_tables_cleanup) is set, the behavior
    should be exactly
    the same as before patch.
    PHP uses EG(full_table_cleanup) only for dl(), but I do't
    know how php-gtk
    uses it.

    Thanks. Dmitry.
    -----Original Message-----
    From: Steph Fox
    Sent: Monday, May 29, 2006 1:40 PM
    To: internals
    Cc: PHP-GTK dev; Dmitry Stogov
    Subject: [PHP-DEV] Ides of March [WAS: tsrm_shutdown() and the CLI
    SAPI]


    Hi all,

    I've spent a fun weekend debugging TSRM and bits of ZE2, having
    finally figured that the zend_compiler_globals dtor was
    the point of
    failure here.

    TSRM needs to mark resources as 'done' following a free
    and doesn't
    in most cases, but that's actually not the main problem we have in
    PHP-GTK (although
    fixing it may well solve everybody else's, I'll check that on
    my travels).

    Dmitry's "Optimized cleanup loops on request shutdown"
    commit(s) spanning
    the 13th and 14th March broke Andrei's
    'EG(full_tables_cleanup) = 1' ruse
    (we needed user classes to be cleaned and internal classes
    to stay),
    but it also broke TSRM shutdown completely for us. PHP-GTK classes
    are recognized
    as being internal, but only the first one ever reaches the
    dtor - even when
    there are no user-defined classes.

    zend_hash_reverse_apply() is called at that point, so I'm guessing
    there's a reentrancy issue behind my access violation crash.

    I'll get back to this when I get some time, in the
    meantime if anyone
    (Dmitry?) wants to play with this you need to know that I
    can't put
    the 5_2 compat stuff into CVS until Andrei OKs it, so PHP-GTK HEAD
    has to be built
    against PHP_5_1 branch at present (anything after March
    14th will do).
    - Steph

    Under CLI ZTS build, when loading a PHP-GTK 2 .dll built against
    anything this side of PHP 5.1.2 release, I'm seeing an 'access
    violation' crash on
    reaching:

    if (resource_types_table && !resource_types_table[j].done &&
    resource_types_table[j].dtor) {
    resource_types_table[j].dtor(p->storage[j],
    &p->storage);
    }

    Similar code is also used in:

    tsrm_free_interpreter_context()
    ts_free_thread()
    ts_free_worker_threads()
    ts_free_id()

    I thought ts_free_thread() was crashing at that line too at
    first, but
    that turned out to be because there's no 'done' check
    there, i.e. double
    dtors are possible via some functions. It's still vaguely
    possible there's
    a double flypast causing the crash I'm seeing, but I have
    everything I
    know about protected now. (On my laptop that is.)

    Eventually I found the resource id for PHP-GTK - the
    only extension
    I'm loading during runtime, via php.ini - is 32nd out of
    a possible
    32. "Eventually", because that means I can't use ts_free_id()
    to avoid the
    crash as advised by Frank (and Tony, and Dmitry, and anyone
    else who ever
    used that MSHUTDOWN workaround for CLI). Interesting too,
    because the
    resource that causes the crash appears to be something
    completely other.
    Tracking down resource id #5 - and that's all I know about
    it apart from
    it crashes - is a barrel of laughs, I'll let y'all know if
    I ever find out
    which of the many possible extensions/files in ext/standard
    or core it is.
    Short version: One line is problematic, and only in one
    function, and
    presumably only under CLI SAPI. (CGI already doesn't call
    tsrm_shutdown(),
    thanks to similar issues some 3 years ago).

    The question is whether to take 'the Zeev approach' and
    simply comment
    out
    the tsrm_shutdown() call at the end of sapi/cli/php_cli.c,
    or whether to
    spend time knitting up a fine-grained approach to prevent
    the one bad line
    in the function from being called in single-threaded
    environments? I think
    I've given up on the idea of actually resolving the bug now...

    Thoughts?

    - oh, and don't make one of them 'chicken-and-egg' - this is
    definitively NOT related to the shutdown order in main.c!!!!!

    - Steph

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
    --
    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


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php



    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
  • Marcus Boerger at May 29, 2006 at 6:34 pm
    Hello Steph,

    can it be that the return value of the dtor functions are wrong? They
    have always been wrong and during last months we tried to sort things
    out. Actually i was planning to have HEAD and 5.2 both respect the APPLY
    values correct. Should i wait with those changes now until someone figures
    out this dtor issue or go ahead and we look then?

    best regards
    marcus

    Monday, May 29, 2006, 11:40:15 AM, you wrote:
    Hi all,
    I've spent a fun weekend debugging TSRM and bits of ZE2, having finally
    figured that the zend_compiler_globals dtor was the point of failure here.
    TSRM needs to mark resources as 'done' following a free and doesn't in most
    cases, but that's actually not the main problem we have in PHP-GTK (although
    fixing it may well solve everybody else's, I'll check that on my travels).
    Dmitry's "Optimized cleanup loops on request shutdown" commit(s) spanning
    the 13th and 14th March broke Andrei's 'EG(full_tables_cleanup) = 1' ruse
    (we needed user classes to be cleaned and internal classes to stay), but it
    also broke TSRM shutdown completely for us. PHP-GTK classes are recognized
    as being internal, but only the first one ever reaches the dtor - even when
    there are no user-defined classes.
    zend_hash_reverse_apply() is called at that point, so I'm guessing there's a
    reentrancy issue behind my access violation crash.
    I'll get back to this when I get some time, in the meantime if anyone
    (Dmitry?) wants to play with this you need to know that I can't put the 5_2
    compat stuff into CVS until Andrei OKs it, so PHP-GTK HEAD has to be built
    against PHP_5_1 branch at present (anything after March 14th will do).
    - Steph
    Under CLI ZTS build, when loading a PHP-GTK 2 .dll built against anything
    this side of PHP 5.1.2 release, I'm seeing an 'access violation' crash on
    reaching:

    if (resource_types_table && !resource_types_table[j].done &&
    resource_types_table[j].dtor) {
    resource_types_table[j].dtor(p->storage[j], &p->storage);
    }

    Similar code is also used in:

    tsrm_free_interpreter_context()
    ts_free_thread()
    ts_free_worker_threads()
    ts_free_id()

    I thought ts_free_thread() was crashing at that line too at first, but
    that turned out to be because there's no 'done' check there, i.e. double
    dtors are possible via some functions. It's still vaguely possible there's
    a double flypast causing the crash I'm seeing, but I have everything I
    know about protected now. (On my laptop that is.)

    Eventually I found the resource id for PHP-GTK - the only extension I'm
    loading during runtime, via php.ini - is 32nd out of a possible 32.
    "Eventually", because that means I can't use ts_free_id() to avoid the
    crash as advised by Frank (and Tony, and Dmitry, and anyone else who ever
    used that MSHUTDOWN workaround for CLI). Interesting too, because the
    resource that causes the crash appears to be something completely other.
    Tracking down resource id #5 - and that's all I know about it apart from
    it crashes - is a barrel of laughs, I'll let y'all know if I ever find out
    which of the many possible extensions/files in ext/standard or core it is.

    Short version: One line is problematic, and only in one function, and
    presumably only under CLI SAPI. (CGI already doesn't call tsrm_shutdown(),
    thanks to similar issues some 3 years ago).

    The question is whether to take 'the Zeev approach' and simply comment out
    the tsrm_shutdown() call at the end of sapi/cli/php_cli.c, or whether to
    spend time knitting up a fine-grained approach to prevent the one bad line
    in the function from being called in single-threaded environments? I think
    I've given up on the idea of actually resolving the bug now...

    Thoughts?

    - oh, and don't make one of them 'chicken-and-egg' - this is definitively
    NOT related to the shutdown order in main.c!!!!!

    - Steph

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com



    Best regards,
    Marcus
  • Steph Fox at May 29, 2006 at 6:39 pm
    I'm down to four possible changes - I'm just going back through them with a
    full build, one by one. (Takes ages here.)

    It could be anything at present... Dmitry, you're definitely off the hook
    over those optimizations though, promising though they seemed.

    /me was hoping for something relatively obvious


    Hello Steph,

    can it be that the return value of the dtor functions are wrong? They
    have always been wrong and during last months we tried to sort things
    out. Actually i was planning to have HEAD and 5.2 both respect the APPLY
    values correct. Should i wait with those changes now until someone figures
    out this dtor issue or go ahead and we look then?

    best regards
    marcus

    Monday, May 29, 2006, 11:40:15 AM, you wrote:
    Hi all,
    I've spent a fun weekend debugging TSRM and bits of ZE2, having finally
    figured that the zend_compiler_globals dtor was the point of failure
    here.
    TSRM needs to mark resources as 'done' following a free and doesn't in
    most
    cases, but that's actually not the main problem we have in PHP-GTK
    (although
    fixing it may well solve everybody else's, I'll check that on my
    travels).
    Dmitry's "Optimized cleanup loops on request shutdown" commit(s) spanning
    the 13th and 14th March broke Andrei's 'EG(full_tables_cleanup) = 1' ruse
    (we needed user classes to be cleaned and internal classes to stay), but
    it
    also broke TSRM shutdown completely for us. PHP-GTK classes are
    recognized
    as being internal, but only the first one ever reaches the dtor - even
    when
    there are no user-defined classes.
    zend_hash_reverse_apply() is called at that point, so I'm guessing
    there's a
    reentrancy issue behind my access violation crash.
    I'll get back to this when I get some time, in the meantime if anyone
    (Dmitry?) wants to play with this you need to know that I can't put the
    5_2
    compat stuff into CVS until Andrei OKs it, so PHP-GTK HEAD has to be
    built
    against PHP_5_1 branch at present (anything after March 14th will do).
    - Steph
    Under CLI ZTS build, when loading a PHP-GTK 2 .dll built against
    anything
    this side of PHP 5.1.2 release, I'm seeing an 'access violation' crash
    on
    reaching:

    if (resource_types_table && !resource_types_table[j].done &&
    resource_types_table[j].dtor) {
    resource_types_table[j].dtor(p->storage[j], &p->storage);
    }

    Similar code is also used in:

    tsrm_free_interpreter_context()
    ts_free_thread()
    ts_free_worker_threads()
    ts_free_id()

    I thought ts_free_thread() was crashing at that line too at first, but
    that turned out to be because there's no 'done' check there, i.e. double
    dtors are possible via some functions. It's still vaguely possible
    there's
    a double flypast causing the crash I'm seeing, but I have everything I
    know about protected now. (On my laptop that is.)

    Eventually I found the resource id for PHP-GTK - the only extension I'm
    loading during runtime, via php.ini - is 32nd out of a possible 32.
    "Eventually", because that means I can't use ts_free_id() to avoid the
    crash as advised by Frank (and Tony, and Dmitry, and anyone else who
    ever
    used that MSHUTDOWN workaround for CLI). Interesting too, because the
    resource that causes the crash appears to be something completely other.
    Tracking down resource id #5 - and that's all I know about it apart from
    it crashes - is a barrel of laughs, I'll let y'all know if I ever find
    out
    which of the many possible extensions/files in ext/standard or core it
    is.

    Short version: One line is problematic, and only in one function, and
    presumably only under CLI SAPI. (CGI already doesn't call
    tsrm_shutdown(),
    thanks to similar issues some 3 years ago).

    The question is whether to take 'the Zeev approach' and simply comment
    out
    the tsrm_shutdown() call at the end of sapi/cli/php_cli.c, or whether to
    spend time knitting up a fine-grained approach to prevent the one bad
    line
    in the function from being called in single-threaded environments? I
    think
    I've given up on the idea of actually resolving the bug now...

    Thoughts?

    - oh, and don't make one of them 'chicken-and-egg' - this is
    definitively
    NOT related to the shutdown order in main.c!!!!!

    - Steph

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com



    Best regards,
    Marcus

    --
    PHP-GTK Development Mailing List (http://gtk.php.net/)
    To unsubscribe, visit: http://www.php.net/unsub.php


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
  • Frank M. Kromann at May 31, 2006 at 2:58 pm
    tsrm_shutdown() is already comented out in the CGI version, most likely as
    a fix to the same kind of problem there. Perhaps enabling that again will
    show the same kind of problems?

    - Frank
    At the moment I'm seeing it with Tidy under 5_2. Just about to get Tony to
    check.

    ----- Original Message -----
    From: "Dmitry Stogov" <dmitry@zend.com>
    To: "'Steph Fox'" <steph@zend.com>; "'Xuefer'" <xuefer@gmail.com>; "'Andi
    Gutmans'" <andi@zend.com>
    Cc: "'internals'" <internals@lists.php.net>; "'Antony Dovgal'"
    <antony@zend.com>
    Sent: Wednesday, May 31, 2006 2:55 PM
    Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    Steph,

    Commenting tsrm_shutdown() or FreeLibrary() is just hidding real
    bugs.
    Of course this is a solution, but not excellent.

    Right now I haven't enough time even for ZE and PHP themself, so I
    don't
    like spent it looking into php-gtk on windows.
    (I don't know GTK at all).

    Do you know any other extension from PHP distribution that cause the
    same
    crash?
    Could you provide instruction how to reproduce it?

    Thanks. Dmitry.
    -----Original Message-----
    From: Steph Fox
    Sent: Wednesday, May 31, 2006 3:28 PM
    To: Dmitry Stogov; 'Xuefer'; 'Andi Gutmans'
    Cc: 'internals'; Antony Dovgal
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    Oh well, now I see the difference.
    With my patch PHP starts call FreeLibrary() for dll extension. I
    am
    wonder why it wasn't called before. :)
    Pure luck, by the look of it :)
    Probably some other bug that is the reason of the crash was masked by
    omitting FreeLibrary(). I know Tony fixed some kind of such bugs
    in
    ext/tidy and ext/sybase.
    Yes, he gave those extensions the ts_free_id() workaround I
    mentioned a
    looooooooooong time ago when I first started looking into this.
    Probably php-gtk needs similar fix.
    That workaround didn't work for PHP-GTK. I tried that first.
    That's why I
    need you to fix this bug rather than me just cover it up. The
    only thing
    that works for PHP-GTK is to either avoid tsrm_shutdown()
    completely (via
    Zeev's suggestion of commenting out the call in php_cli.c),
    or to fix the
    bug that makes reaching it a problem.
    All other systems except win32 already used common config
    file, and I
    don't
    see any reason for this exceptions.
    I don't know or care what other systems do... how's that even
    relevant?
    Especially because it was the reason of bug, and masked other bugs
    that
    may
    be reproduced on linux with ZTS.
    Sorry, I didn't parse that... can you rephrase?
    Thanks. Dmitry.
    Cheers,
    - Steph

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php



    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Steph Fox at May 31, 2006 at 3:26 pm
    Hi Frank,
    tsrm_shutdown() is already comented out in the CGI version, most likely as
    a fix to the same kind of problem there. Perhaps enabling that again will
    show the same kind of problems?
    Yes, it would, given the root cause - but would you really want to break the
    whole of PHP for an academic exercise?

    The more interesting thing is that none of this happens under CLI debug.
    I've still no clue why.

    I also think I've somehow corrupted something here with my debug lines, I'm
    crashing 'differently' now <sigh />.

    - Steph
    - Frank
  • Andi Gutmans at Jun 1, 2006 at 4:26 am

    At 08:23 AM 5/31/2006, Steph Fox wrote:
    Hi Frank,
    tsrm_shutdown() is already comented out in the CGI version, most likely as
    a fix to the same kind of problem there. Perhaps enabling that again will
    show the same kind of problems?
    Yes, it would, given the root cause - but would you really want to
    break the whole of PHP for an academic exercise?
    It's not really an academic exercise. If we know there's a bug
    someplace we should at least look into it and try and understand it.
    Then if we decide to remove the trsm_shutdown call for a good reason
    (circular dependency, blah blah blah) then we can do that and put a
    nice fat comment on why it's the right thing to do. But I do think
    it's benefical to try and understand what's happening.

    Andi

    The more interesting thing is that none of this happens under CLI
    debug. I've still no clue why.

    I also think I've somehow corrupted something here with my debug
    lines, I'm crashing 'differently' now <sigh />.

    - Steph
    - Frank
  • Steph Fox at Jun 1, 2006 at 4:53 am

    Yes, it would, given the root cause - but would you really want to break
    the whole of PHP for an academic exercise?
    It's not really an academic exercise. If we know there's a bug someplace
    we should at least look into it and try and understand it.
    Frank's referring to Zeev's three-years-ago decision to simply opt out of
    tsrm_shutdown() here... he's suggesting we revert it.
    Then if we decide to remove the trsm_shutdown call for a good reason
    (circular dependency, blah blah blah) then we can do that and put a nice
    fat comment on why it's the right thing to do. But I do think it's
    benefical to try and understand what's happening.
    Fine, but breaking working code while you're trying to understand what's
    happening is far from beneficial to our users. Can't we at least #0 it?
    Andi
  • Andi Gutmans at Jun 1, 2006 at 8:15 am
    As we are not planning to release a new version within the next
    couple of weeks, I suggest before jumping to conclusions we take a look at it.

    If you really need to comment out that line in the meanwhile that's OK with me.

    Andi
    At 09:50 PM 5/31/2006, Steph Fox wrote:
    Yes, it would, given the root cause - but would you really want to
    break the whole of PHP for an academic exercise?
    It's not really an academic exercise. If we know there's a bug
    someplace we should at least look into it and try and understand it.
    Frank's referring to Zeev's three-years-ago decision to simply opt
    out of tsrm_shutdown() here... he's suggesting we revert it.
    Then if we decide to remove the trsm_shutdown call for a good
    reason (circular dependency, blah blah blah) then we can do that
    and put a nice fat comment on why it's the right thing to do. But I
    do think it's benefical to try and understand what's happening.
    Fine, but breaking working code while you're trying to understand
    what's happening is far from beneficial to our users. Can't we at least #0 it?
    Andi
  • Dmitry Stogov at Jun 1, 2006 at 11:05 am
    Hi Stepth,

    I reproduced crash of php-gtk on linix with php-zts.
    I mean running "php -v" then php.ini contains "extension=gtk2.so".
    The crash occurs only then php compiled with --enable-debug.

    The reason of the crash is a bug in ZE that is activated by memory leaks in
    php-gtk.
    In case of "php -v" we don't do request startup/shutdown and as result we
    don't handle memory leaks on request shutdown.
    During tsrm_shutdown() shutdow_nmemory_manager() is called after
    sapi_shutdown() and as result we cannot access sapi_globals then trying to
    print information about memory leaks and crashes.

    The solution - don't print information about memory leaks during
    tsrm_shutdown().

    Patch for PHP_5_2 is attached, but it can be manually applied to any
    version.

    Steph, does you crash(es) go away with this patch?

    I am going to commit patch in 24h.
    Any objections?

    Thanks. Dmitry.
    -----Original Message-----
    From: Andi Gutmans
    Sent: Thursday, June 01, 2006 10:29 AM
    To: Steph Fox; Frank M. Kromann
    Cc: 'internals'; 'Antony Dovgal'; Dmitry Stogov; 'Xuefer'
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    As we are not planning to release a new version within the next
    couple of weeks, I suggest before jumping to conclusions we
    take a look at it.

    If you really need to comment out that line in the meanwhile
    that's OK with me.

    Andi
    At 09:50 PM 5/31/2006, Steph Fox wrote:
    Yes, it would, given the root cause - but would you really want to
    break the whole of PHP for an academic exercise?
    It's not really an academic exercise. If we know there's a bug
    someplace we should at least look into it and try and understand it.
    Frank's referring to Zeev's three-years-ago decision to simply opt
    out of tsrm_shutdown() here... he's suggesting we revert it.
    Then if we decide to remove the trsm_shutdown call for a good
    reason (circular dependency, blah blah blah) then we can do that
    and put a nice fat comment on why it's the right thing to do. But I
    do think it's benefical to try and understand what's happening.
    Fine, but breaking working code while you're trying to understand
    what's happening is far from beneficial to our users. Can't
    we at least #0 it?
    Andi
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

  • Steph Fox at Jun 1, 2006 at 5:06 pm
    Wrong crash. Mine doesn't happen in debug mode.

    ----- Original Message -----
    From: "Dmitry Stogov" <dmitry@zend.com>
    To: "'Andi Gutmans'" <andi@zend.com>; "'Steph Fox'" <steph@zend.com>;
    "'Frank M. Kromann'" <frank@kromann.info>
    Cc: "'internals'" <internals@lists.php.net>; "'Antony Dovgal'"
    <antony@zend.com>; "'Xuefer'" <xuefer@gmail.com>
    Sent: Thursday, June 01, 2006 1:05 PM
    Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    Hi Stepth,

    I reproduced crash of php-gtk on linix with php-zts.
    I mean running "php -v" then php.ini contains "extension=gtk2.so".
    The crash occurs only then php compiled with --enable-debug.

    The reason of the crash is a bug in ZE that is activated by memory leaks
    in
    php-gtk.
    In case of "php -v" we don't do request startup/shutdown and as result we
    don't handle memory leaks on request shutdown.
    During tsrm_shutdown() shutdow_nmemory_manager() is called after
    sapi_shutdown() and as result we cannot access sapi_globals then trying to
    print information about memory leaks and crashes.

    The solution - don't print information about memory leaks during
    tsrm_shutdown().

    Patch for PHP_5_2 is attached, but it can be manually applied to any
    version.

    Steph, does you crash(es) go away with this patch?

    I am going to commit patch in 24h.
    Any objections?

    Thanks. Dmitry.
    -----Original Message-----
    From: Andi Gutmans
    Sent: Thursday, June 01, 2006 10:29 AM
    To: Steph Fox; Frank M. Kromann
    Cc: 'internals'; 'Antony Dovgal'; Dmitry Stogov; 'Xuefer'
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    As we are not planning to release a new version within the next
    couple of weeks, I suggest before jumping to conclusions we
    take a look at it.

    If you really need to comment out that line in the meanwhile
    that's OK with me.

    Andi
    At 09:50 PM 5/31/2006, Steph Fox wrote:
    Yes, it would, given the root cause - but would you really want to
    break the whole of PHP for an academic exercise?
    It's not really an academic exercise. If we know there's a bug
    someplace we should at least look into it and try and understand it.
    Frank's referring to Zeev's three-years-ago decision to simply opt
    out of tsrm_shutdown() here... he's suggesting we revert it.
    Then if we decide to remove the trsm_shutdown call for a good
    reason (circular dependency, blah blah blah) then we can do that
    and put a nice fat comment on why it's the right thing to do. But I
    do think it's benefical to try and understand what's happening.
    Fine, but breaking working code while you're trying to understand
    what's happening is far from beneficial to our users. Can't
    we at least #0 it?
    Andi
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
  • Andi Gutmans at Jun 2, 2006 at 6:07 pm
    I don't understand this patch. Doesn't this completely remove
    printing memory leaks? We never fixed this bug but as it was only
    relevant to the debug version and dl() we were OK with it... Of
    course there's also the option of not calling DL_UNLOAD().

    Andi
    At 04:05 AM 6/1/2006, Dmitry Stogov wrote:
    Hi Stepth,

    I reproduced crash of php-gtk on linix with php-zts.
    I mean running "php -v" then php.ini contains "extension=gtk2.so".
    The crash occurs only then php compiled with --enable-debug.

    The reason of the crash is a bug in ZE that is activated by memory leaks in
    php-gtk.
    In case of "php -v" we don't do request startup/shutdown and as result we
    don't handle memory leaks on request shutdown.
    During tsrm_shutdown() shutdow_nmemory_manager() is called after
    sapi_shutdown() and as result we cannot access sapi_globals then trying to
    print information about memory leaks and crashes.

    The solution - don't print information about memory leaks during
    tsrm_shutdown().

    Patch for PHP_5_2 is attached, but it can be manually applied to any
    version.

    Steph, does you crash(es) go away with this patch?

    I am going to commit patch in 24h.
    Any objections?

    Thanks. Dmitry.
    -----Original Message-----
    From: Andi Gutmans
    Sent: Thursday, June 01, 2006 10:29 AM
    To: Steph Fox; Frank M. Kromann
    Cc: 'internals'; 'Antony Dovgal'; Dmitry Stogov; 'Xuefer'
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    As we are not planning to release a new version within the next
    couple of weeks, I suggest before jumping to conclusions we
    take a look at it.

    If you really need to comment out that line in the meanwhile
    that's OK with me.

    Andi
    At 09:50 PM 5/31/2006, Steph Fox wrote:
    Yes, it would, given the root cause - but would you really want to
    break the whole of PHP for an academic exercise?
    It's not really an academic exercise. If we know there's a bug
    someplace we should at least look into it and try and understand it.
    Frank's referring to Zeev's three-years-ago decision to simply opt
    out of tsrm_shutdown() here... he's suggesting we revert it.
    Then if we decide to remove the trsm_shutdown call for a good
    reason (circular dependency, blah blah blah) then we can do that
    and put a nice fat comment on why it's the right thing to do. But I
    do think it's benefical to try and understand what's happening.
    Fine, but breaking working code while you're trying to understand
    what's happening is far from beneficial to our users. Can't
    we at least #0 it?
    Andi
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

  • Steph Fox at Jun 2, 2006 at 6:14 pm
    Hi Andi,
    I don't understand this patch. Doesn't this completely remove printing
    memory leaks? We never fixed this bug but as it was only relevant to the
    debug version and dl() we were OK with it... Of course there's also the
    option of not calling DL_UNLOAD().
    Things got a bit crossed today :-\

    This patch fixes a completely different bug that Dmitry came across on his
    travels.

    - Steph
    Andi
    At 04:05 AM 6/1/2006, Dmitry Stogov wrote:
    Hi Stepth,

    I reproduced crash of php-gtk on linix with php-zts.
    I mean running "php -v" then php.ini contains "extension=gtk2.so".
    The crash occurs only then php compiled with --enable-debug.

    The reason of the crash is a bug in ZE that is activated by memory leaks
    in
    php-gtk.
    In case of "php -v" we don't do request startup/shutdown and as result we
    don't handle memory leaks on request shutdown.
    During tsrm_shutdown() shutdow_nmemory_manager() is called after
    sapi_shutdown() and as result we cannot access sapi_globals then trying to
    print information about memory leaks and crashes.

    The solution - don't print information about memory leaks during
    tsrm_shutdown().

    Patch for PHP_5_2 is attached, but it can be manually applied to any
    version.

    Steph, does you crash(es) go away with this patch?

    I am going to commit patch in 24h.
    Any objections?

    Thanks. Dmitry.
    -----Original Message-----
    From: Andi Gutmans
    Sent: Thursday, June 01, 2006 10:29 AM
    To: Steph Fox; Frank M. Kromann
    Cc: 'internals'; 'Antony Dovgal'; Dmitry Stogov; 'Xuefer'
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    As we are not planning to release a new version within the next
    couple of weeks, I suggest before jumping to conclusions we
    take a look at it.

    If you really need to comment out that line in the meanwhile
    that's OK with me.

    Andi
    At 09:50 PM 5/31/2006, Steph Fox wrote:
    Yes, it would, given the root cause - but would you really want to
    break the whole of PHP for an academic exercise?
    It's not really an academic exercise. If we know there's a bug
    someplace we should at least look into it and try and understand it.
    Frank's referring to Zeev's three-years-ago decision to simply opt
    out of tsrm_shutdown() here... he's suggesting we revert it.
    Then if we decide to remove the trsm_shutdown call for a good
    reason (circular dependency, blah blah blah) then we can do that
    and put a nice fat comment on why it's the right thing to do. But I
    do think it's benefical to try and understand what's happening.
    Fine, but breaking working code while you're trying to understand
    what's happening is far from beneficial to our users. Can't
    we at least #0 it?
    Andi
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
  • Dmitry Stogov at Jun 5, 2006 at 11:20 am
    Hi Steph,

    I finally found the reason of crash.
    It has nothing related to ZE bugs.

    You build php-gtk with "/MT" option.

    This is completely wrong, because you use two different libc and two
    different heaps.
    As result when ZE calls FreeLibrary(), one of heaps is destroyed and all
    pointers that were allocated from inside php-gtk.dll become inaccessible.

    Rebuilding php-gtk with "/MD" fixes the problem.

    Thanks. Dmitry.
    -----Original Message-----
    From: Steph Fox
    Sent: Friday, June 02, 2006 10:12 PM
    To: Dmitry Stogov; 'Frank M. Kromann'; Andi Gutmans
    Cc: 'internals'; 'Antony Dovgal'; 'Xuefer'
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    Hi Andi,
    I don't understand this patch. Doesn't this completely
    remove printing
    memory leaks? We never fixed this bug but as it was only
    relevant to the
    debug version and dl() we were OK with it... Of course
    there's also the
    option of not calling DL_UNLOAD().
    Things got a bit crossed today :-\

    This patch fixes a completely different bug that Dmitry came
    across on his
    travels.

    - Steph
    Andi
    At 04:05 AM 6/1/2006, Dmitry Stogov wrote:
    Hi Stepth,

    I reproduced crash of php-gtk on linix with php-zts.
    I mean running "php -v" then php.ini contains
    "extension=gtk2.so". The
    crash occurs only then php compiled with --enable-debug.

    The reason of the crash is a bug in ZE that is activated by memory
    leaks
    in
    php-gtk.
    In case of "php -v" we don't do request startup/shutdown
    and as result we
    don't handle memory leaks on request shutdown.
    During tsrm_shutdown() shutdow_nmemory_manager() is called after
    sapi_shutdown() and as result we cannot access sapi_globals
    then trying to
    print information about memory leaks and crashes.

    The solution - don't print information about memory leaks during
    tsrm_shutdown().

    Patch for PHP_5_2 is attached, but it can be manually
    applied to any
    version.

    Steph, does you crash(es) go away with this patch?

    I am going to commit patch in 24h.
    Any objections?

    Thanks. Dmitry.
    -----Original Message-----
    From: Andi Gutmans
    Sent: Thursday, June 01, 2006 10:29 AM
    To: Steph Fox; Frank M. Kromann
    Cc: 'internals'; 'Antony Dovgal'; Dmitry Stogov; 'Xuefer'
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    As we are not planning to release a new version within the next
    couple of weeks, I suggest before jumping to conclusions
    we take a
    look at it.

    If you really need to comment out that line in the
    meanwhile that's
    OK with me.

    Andi
    At 09:50 PM 5/31/2006, Steph Fox wrote:
    Yes, it would, given the root cause - but would you
    really want
    to break the whole of PHP for an academic exercise?
    It's not really an academic exercise. If we know there's a bug
    someplace we should at least look into it and try and
    understand
    it.
    Frank's referring to Zeev's three-years-ago decision to
    simply opt
    out of tsrm_shutdown() here... he's suggesting we revert it.
    Then if we decide to remove the trsm_shutdown call for a good
    reason (circular dependency, blah blah blah) then we
    can do that
    and put a nice fat comment on why it's the right thing
    to do. But
    I do think it's benefical to try and understand what's
    happening.
    Fine, but breaking working code while you're trying to
    understand
    what's happening is far from beneficial to our users. Can't
    we at least #0 it?
    Andi
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

  • Steph Fox at Jun 5, 2006 at 11:59 am
    Hi Dmitry,

    Hm yeah that forces it to use libcmt... that'd hurt :)

    Thank you for finding that! I'd looked through the debug build stuff (which
    is correct) when trying to find out why PHP-GTK didn't crash at the same
    point as Tidy - but I didn't check the release flags while I was there.

    Still, I wouldn't say it was a waste of time - we did at least find three
    other bugs through it, two of which are fixed already and one of which has
    two proposed fixes waiting for evaluation. So I guess the arguments for
    keeping DL_UNLOAD alive and well are proven good.

    - Steph

    ps Andrei - we're on for the weekend!



    Hi Steph,

    I finally found the reason of crash.
    It has nothing related to ZE bugs.

    You build php-gtk with "/MT" option.

    This is completely wrong, because you use two different libc and two
    different heaps.
    As result when ZE calls FreeLibrary(), one of heaps is destroyed and all
    pointers that were allocated from inside php-gtk.dll become inaccessible.

    Rebuilding php-gtk with "/MD" fixes the problem.

    Thanks. Dmitry.
    -----Original Message-----
    From: Steph Fox
    Sent: Friday, June 02, 2006 10:12 PM
    To: Dmitry Stogov; 'Frank M. Kromann'; Andi Gutmans
    Cc: 'internals'; 'Antony Dovgal'; 'Xuefer'
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    Hi Andi,
    I don't understand this patch. Doesn't this completely
    remove printing
    memory leaks? We never fixed this bug but as it was only
    relevant to the
    debug version and dl() we were OK with it... Of course
    there's also the
    option of not calling DL_UNLOAD().
    Things got a bit crossed today :-\

    This patch fixes a completely different bug that Dmitry came
    across on his
    travels.

    - Steph
    Andi
    At 04:05 AM 6/1/2006, Dmitry Stogov wrote:
    Hi Stepth,

    I reproduced crash of php-gtk on linix with php-zts.
    I mean running "php -v" then php.ini contains
    "extension=gtk2.so". The
    crash occurs only then php compiled with --enable-debug.

    The reason of the crash is a bug in ZE that is activated by memory
    leaks
    in
    php-gtk.
    In case of "php -v" we don't do request startup/shutdown
    and as result we
    don't handle memory leaks on request shutdown.
    During tsrm_shutdown() shutdow_nmemory_manager() is called after
    sapi_shutdown() and as result we cannot access sapi_globals
    then trying to
    print information about memory leaks and crashes.

    The solution - don't print information about memory leaks during
    tsrm_shutdown().

    Patch for PHP_5_2 is attached, but it can be manually
    applied to any
    version.

    Steph, does you crash(es) go away with this patch?

    I am going to commit patch in 24h.
    Any objections?

    Thanks. Dmitry.
    -----Original Message-----
    From: Andi Gutmans
    Sent: Thursday, June 01, 2006 10:29 AM
    To: Steph Fox; Frank M. Kromann
    Cc: 'internals'; 'Antony Dovgal'; Dmitry Stogov; 'Xuefer'
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    As we are not planning to release a new version within the next
    couple of weeks, I suggest before jumping to conclusions
    we take a
    look at it.

    If you really need to comment out that line in the
    meanwhile that's
    OK with me.

    Andi
    At 09:50 PM 5/31/2006, Steph Fox wrote:
    Yes, it would, given the root cause - but would you
    really want
    to break the whole of PHP for an academic exercise?
    It's not really an academic exercise. If we know there's a bug
    someplace we should at least look into it and try and
    understand
    it.
    Frank's referring to Zeev's three-years-ago decision to
    simply opt
    out of tsrm_shutdown() here... he's suggesting we revert it.
    Then if we decide to remove the trsm_shutdown call for a good
    reason (circular dependency, blah blah blah) then we
    can do that
    and put a nice fat comment on why it's the right thing
    to do. But
    I do think it's benefical to try and understand what's
    happening.
    Fine, but breaking working code while you're trying to
    understand
    what's happening is far from beneficial to our users. Can't
    we at least #0 it?
    Andi
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php



    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
  • Dmitry Stogov at Jun 5, 2006 at 6:30 am
    This patch fixes very specific bug.

    "php -v" calls RINIT() functions, php with php-gtk throws error from RINIT
    if we run php from telent/ssh session, because it cannot open DISPLAY. As
    result we don't go into request shutdown (shutdown_memory_manager() is
    called there) sequence and doing module shutdown and tsrm_shutdown().
    Because request_shutdown() wasn't done we didn't cleared emalloced memory,
    and trying to do it during tsrm_shutdown() but some globals (sapi globals)
    are destroyed in this time. As result we get a crash.

    Thanks. Dmitry.
    -----Original Message-----
    From: Andi Gutmans
    Sent: Friday, June 02, 2006 10:08 PM
    To: Dmitry Stogov; 'Steph Fox'; 'Frank M. Kromann'
    Cc: 'internals'; 'Antony Dovgal'; 'Xuefer'
    Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    I don't understand this patch. Doesn't this completely remove
    printing memory leaks? We never fixed this bug but as it was only
    relevant to the debug version and dl() we were OK with it... Of
    course there's also the option of not calling DL_UNLOAD().

    Andi
    At 04:05 AM 6/1/2006, Dmitry Stogov wrote:
    Hi Stepth,

    I reproduced crash of php-gtk on linix with php-zts.
    I mean running "php -v" then php.ini contains
    "extension=gtk2.so". The
    crash occurs only then php compiled with --enable-debug.

    The reason of the crash is a bug in ZE that is activated by memory
    leaks in php-gtk. In case of "php -v" we don't do request
    startup/shutdown and as result we don't handle memory leaks
    on request
    shutdown. During tsrm_shutdown() shutdow_nmemory_manager() is called
    after
    sapi_shutdown() and as result we cannot access sapi_globals
    then trying
    to print information about memory leaks and crashes.

    The solution - don't print information about memory leaks during
    tsrm_shutdown().

    Patch for PHP_5_2 is attached, but it can be manually applied to any
    version.

    Steph, does you crash(es) go away with this patch?

    I am going to commit patch in 24h.
    Any objections?

    Thanks. Dmitry.
    -----Original Message-----
    From: Andi Gutmans
    Sent: Thursday, June 01, 2006 10:29 AM
    To: Steph Fox; Frank M. Kromann
    Cc: 'internals'; 'Antony Dovgal'; Dmitry Stogov; 'Xuefer'
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    As we are not planning to release a new version within the next
    couple of weeks, I suggest before jumping to conclusions
    we take a
    look at it.

    If you really need to comment out that line in the
    meanwhile that's
    OK with me.

    Andi
    At 09:50 PM 5/31/2006, Steph Fox wrote:
    Yes, it would, given the root cause - but would you
    really want
    to break the whole of PHP for an academic exercise?
    It's not really an academic exercise. If we know there's a bug
    someplace we should at least look into it and try and
    understand
    it.
    Frank's referring to Zeev's three-years-ago decision to
    simply opt
    out of tsrm_shutdown() here... he's suggesting we revert it.
    Then if we decide to remove the trsm_shutdown call for a good
    reason (circular dependency, blah blah blah) then we
    can do that
    and put a nice fat comment on why it's the right thing
    to do. But
    I do think it's benefical to try and understand what's
    happening.
    Fine, but breaking working code while you're trying to
    understand
    what's happening is far from beneficial to our users. Can't
    we at least #0 it?
    Andi
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

  • Steph Fox at Jun 1, 2006 at 5:02 pm
    We were hoping to release ours...

    ----- Original Message -----
    From: "Andi Gutmans" <andi@zend.com>
    To: "Steph Fox" <steph@zend.com>; "Frank M. Kromann" <frank@kromann.info>
    Cc: "'internals'" <internals@lists.php.net>; "'Antony Dovgal'"
    <antony@zend.com>; "Dmitry Stogov" <dmitry@zend.com>; "'Xuefer'"
    <xuefer@gmail.com>
    Sent: Thursday, June 01, 2006 8:28 AM
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    As we are not planning to release a new version within the next couple of
    weeks, I suggest before jumping to conclusions we take a look at it.

    If you really need to comment out that line in the meanwhile that's OK
    with me.

    Andi
    At 09:50 PM 5/31/2006, Steph Fox wrote:
    Yes, it would, given the root cause - but would you really want to break
    the whole of PHP for an academic exercise?
    It's not really an academic exercise. If we know there's a bug someplace
    we should at least look into it and try and understand it.
    Frank's referring to Zeev's three-years-ago decision to simply opt out of
    tsrm_shutdown() here... he's suggesting we revert it.
    Then if we decide to remove the trsm_shutdown call for a good reason
    (circular dependency, blah blah blah) then we can do that and put a nice
    fat comment on why it's the right thing to do. But I do think it's
    benefical to try and understand what's happening.
    Fine, but breaking working code while you're trying to understand what's
    happening is far from beneficial to our users. Can't we at least #0 it?
    Andi

    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
  • Frank M. Kromann at May 31, 2006 at 3:40 pm
    Hi Steph,
    Yes, it would, given the root cause - but would you really want to break the
    whole of PHP for an academic exercise?
    Changing the code locally just to test and see if it gave another clude to
    the problem would be my approach :-)

    - Frank
  • Steph Fox at May 31, 2006 at 3:56 pm

    Hi Steph,
    Yes, it would, given the root cause - but would you really want to break the
    whole of PHP for an academic exercise?
    Changing the code locally just to test and see if it gave another clude to
    the problem would be my approach :-)
    I don't need to... the current problem's bleedin' obvious :) However, that
    wasn't the problem 3 years ago when that ifdef was put there. It will most
    likely have been caused by various SAPIs loading various PHP/Zend includes
    in various orders, so some of them had the prerequisite define for the
    DL_UNLOAD call and others didn't. Dmitry's just brought the whole mess out
    into the open - they _all_ have it defined now.

    Still waiting for that fresh checkout...
    - Frank
  • Frank M. Kromann at Jun 1, 2006 at 5:19 am
    I'm a bit behind so sorry if this has been answered already. I don't
    think
    ts_free_id() is a workaround but it's actually correct.
    ts_free_id() would be a correct workaround if it came from
    zend_shutdown().
    How's it right to suddenly force EVERY extension author to add it to their
    code individually?
    This was only reqiured in extensions registering custom dtor's like tidy
    and printer.

    - Frank
  • Steph Fox at Jun 1, 2006 at 5:38 pm

    ts_free_id() would be a correct workaround if it came from
    zend_shutdown().
    How's it right to suddenly force EVERY extension author to add it to their
    code individually?
    This was only reqiured in extensions registering custom dtor's like tidy
    and printer.
    Unfortunately that's not true. It's also required in the php-gtk module even
    though we don't declare a dtor - the DL_UNLOAD call is the first thing in
    the shutdown process, and if you _don't_ have free_ts_id() in MSHUTDOWN at
    present you'll be freeing the resource after the module's unloaded.
    DL_UNLOAD is called on anything loaded via dl() or the php.ini....

    This isn't our only problem though - the GLOBAL_CLASS_TABLE is being
    destroyed during CG dtor because it doesn't match the current
    CG->global_class_table. Because the CG dtor is run after the PHP-GTK module
    is unloaded, destroying that class table crashes the shutdown process.

    I've no idea why or how GTK classes end up in the CG global class table, but
    I guess that's what happening here. Any offers?

    - Steph
  • Frank M. Kromann at Jun 1, 2006 at 5:21 am
    Yes, it would, given the root cause - but would you really want to
    break
    the whole of PHP for an academic exercise?
    It's not really an academic exercise. If we know there's a bug
    someplace
    we should at least look into it and try and understand it.
    Frank's referring to Zeev's three-years-ago decision to simply opt out of
    tsrm_shutdown() here... he's suggesting we revert it.
    Then if we decide to remove the trsm_shutdown call for a good reason
    (circular dependency, blah blah blah) then we can do that and put a
    nice
    fat comment on why it's the right thing to do. But I do think it's
    benefical to try and understand what's happening.
    Fine, but breaking working code while you're trying to understand what's
    happening is far from beneficial to our users. Can't we at least #0 it?
    There is no need to break code. The shutdown function was commented out
    for a reason (crash) when that's fixed we can enable that code again.

    - Frank
  • Richard Lynch at Jun 1, 2006 at 8:08 pm

    On Thu, June 1, 2006 12:21 am, Frank M. Kromann wrote:
    Fine, but breaking working code while you're trying to understand
    what's
    happening is far from beneficial to our users. Can't we at least #0
    it?
    There is no need to break code. The shutdown function was commented
    out
    for a reason (crash) when that's fixed we can enable that code again.
    I believe this entire part of this thread stems from a suggestion to
    un-comment that on DEVELOPMENT MACHINES.

    The OP did only implied the DEVELOPMENT MACHINE, however.

    It was only a suggestion that debugging it in CGI would be easier than
    in CLI, or at least more common for development users to hit it enough
    to FIX it, instead of letting it fester.

    It's possible the OP meant to CVS commit such a change, but I would
    hope not...
  • Dmitry Stogov at Jun 1, 2006 at 11:25 am
    Patch was cutted.

    Dmitry.
    -----Original Message-----
    From: Dmitry Stogov
    Sent: Thursday, June 01, 2006 3:05 PM
    To: 'Andi Gutmans'; 'Steph Fox'; 'Frank M. Kromann'
    Cc: 'internals'; 'Antony Dovgal'; 'Xuefer'
    Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    Hi Stepth,

    I reproduced crash of php-gtk on linix with php-zts.
    I mean running "php -v" then php.ini contains
    "extension=gtk2.so". The crash occurs only then php compiled
    with --enable-debug.

    The reason of the crash is a bug in ZE that is activated by
    memory leaks in php-gtk. In case of "php -v" we don't do
    request startup/shutdown and as result we don't handle memory
    leaks on request shutdown. During tsrm_shutdown()
    shutdow_nmemory_manager() is called after sapi_shutdown() and
    as result we cannot access sapi_globals then trying to print
    information about memory leaks and crashes.

    The solution - don't print information about memory leaks
    during tsrm_shutdown().

    Patch for PHP_5_2 is attached, but it can be manually applied
    to any version.

    Steph, does you crash(es) go away with this patch?

    I am going to commit patch in 24h.
    Any objections?

    Thanks. Dmitry.
    -----Original Message-----
    From: Andi Gutmans
    Sent: Thursday, June 01, 2006 10:29 AM
    To: Steph Fox; Frank M. Kromann
    Cc: 'internals'; 'Antony Dovgal'; Dmitry Stogov; 'Xuefer'
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    As we are not planning to release a new version within the next
    couple of weeks, I suggest before jumping to conclusions we
    take a look at it.

    If you really need to comment out that line in the meanwhile
    that's OK with me.

    Andi
    At 09:50 PM 5/31/2006, Steph Fox wrote:
    Yes, it would, given the root cause - but would you
    really want to
    break the whole of PHP for an academic exercise?
    It's not really an academic exercise. If we know there's a bug
    someplace we should at least look into it and try and
    understand it.
    Frank's referring to Zeev's three-years-ago decision to simply opt
    out of tsrm_shutdown() here... he's suggesting we revert it.
    Then if we decide to remove the trsm_shutdown call for a
    good reason
    (circular dependency, blah blah blah) then we can do that
    and put a
    nice fat comment on why it's the right thing to do. But I
    do think
    it's benefical to try and understand what's happening.
    Fine, but breaking working code while you're trying to understand
    what's happening is far from beneficial to our users. Can't
    we at least #0 it?
    Andi
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

  • Steph Fox at Jun 1, 2006 at 7:46 pm
    Silencing the shutdown memory manager doesn't help 'my' bug, although it
    probably fixes yours :)

    You'd need to be on win32 to see the crash that was introduced by forcing
    the DL_UNLOAD call for win32.... unless you want to 'fake it' by adding ZTS
    to that 'if' list in the module_destructor.

    Thanks for looking though, I know it's a pain in the neck to set up PHP-GTK
    builds. Although it'd be easier to remove 'free_ts_id()' from tidy, the CG
    global table problem doesn't show up there...


    ----- Original Message -----
    From: "Dmitry Stogov" <dmitry@zend.com>
    To: "'Steph Fox'" <steph@zend.com>
    Cc: "'internals'" <internals@lists.php.net>
    Sent: Thursday, June 01, 2006 1:25 PM
    Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    Patch was cutted.

    Dmitry.
    -----Original Message-----
    From: Dmitry Stogov
    Sent: Thursday, June 01, 2006 3:05 PM
    To: 'Andi Gutmans'; 'Steph Fox'; 'Frank M. Kromann'
    Cc: 'internals'; 'Antony Dovgal'; 'Xuefer'
    Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    Hi Stepth,

    I reproduced crash of php-gtk on linix with php-zts.
    I mean running "php -v" then php.ini contains
    "extension=gtk2.so". The crash occurs only then php compiled
    with --enable-debug.

    The reason of the crash is a bug in ZE that is activated by
    memory leaks in php-gtk. In case of "php -v" we don't do
    request startup/shutdown and as result we don't handle memory
    leaks on request shutdown. During tsrm_shutdown()
    shutdow_nmemory_manager() is called after sapi_shutdown() and
    as result we cannot access sapi_globals then trying to print
    information about memory leaks and crashes.

    The solution - don't print information about memory leaks
    during tsrm_shutdown().

    Patch for PHP_5_2 is attached, but it can be manually applied
    to any version.

    Steph, does you crash(es) go away with this patch?

    I am going to commit patch in 24h.
    Any objections?

    Thanks. Dmitry.
    -----Original Message-----
    From: Andi Gutmans
    Sent: Thursday, June 01, 2006 10:29 AM
    To: Steph Fox; Frank M. Kromann
    Cc: 'internals'; 'Antony Dovgal'; Dmitry Stogov; 'Xuefer'
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    As we are not planning to release a new version within the next
    couple of weeks, I suggest before jumping to conclusions we
    take a look at it.

    If you really need to comment out that line in the meanwhile
    that's OK with me.

    Andi
    At 09:50 PM 5/31/2006, Steph Fox wrote:
    Yes, it would, given the root cause - but would you
    really want to
    break the whole of PHP for an academic exercise?
    It's not really an academic exercise. If we know there's a bug
    someplace we should at least look into it and try and
    understand it.
    Frank's referring to Zeev's three-years-ago decision to simply opt
    out of tsrm_shutdown() here... he's suggesting we revert it.
    Then if we decide to remove the trsm_shutdown call for a
    good reason
    (circular dependency, blah blah blah) then we can do that
    and put a
    nice fat comment on why it's the right thing to do. But I
    do think
    it's benefical to try and understand what's happening.
    Fine, but breaking working code while you're trying to understand
    what's happening is far from beneficial to our users. Can't
    we at least #0 it?
    Andi
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com

    --------------------------------------------------------------------------------

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com
  • Steph Fox at Jun 2, 2006 at 5:49 am
    Hi Dmitry,

    Have some diagnostics:

    1) zend_shutdown() is called before anything in TSRM. It invokes
    zend_hash_graceful_reverse_destroy(&module_registry);

    2) module_destructor() is invoked via the hash-destroyer (being part of the
    module_registry hash constructor). This performs the MSHUTDOWN routine for
    each registered module, which in several cases (now) includes a PHP-side
    call to ts_free_id(). The ts_free_id() call usually allows the next stage to
    be unproblematic; it also marks the module's entry in the resource table as
    'done', so that the final clearing loop won't try to double-free it.
    However, ts_free_id() doesn't check for 'done' itself before it frees
    resources.

    3) DL_UNLOAD (an alias for FreeLibrary, under doze) is then called on any
    module loaded via dl() or php.ini (checking for a module handle)... it looks
    like this stage might only have happened under Macs on CLI until
    mid-March...

    4) tsrm_shutdown() - the final clearing loop - is called via the end of the
    various SAPI source files (in this case, php_cli.c), and any resource that
    hasn't been freed explicitly by this point is freed there.

    It won't help our particular situation, but I think automatically calling
    ts_free_id() on dl-loaded modules would be better than either blanket
    avoidance of tsrm_shutdown() or requiring each module to call ts_free_id()
    explicitly during MINIT. Patch(es) to do that in PHP_5_2 branch attached.

    The problem in PHP-GTK is we're crashing when the compiler_globals dtor is
    called in tsrm_shutdown(), rather than when the gtk_globals dtor is called.
    I think this is a ZE problem rather than ours, but see what you think:
    somehow, in compiler_globals_dtor(),

    compiler_globals->class_table != GLOBAL_CLASS_TABLE

    and the compiler_globals->class_table is destroyed and freed because of
    that.

    - Steph

    ----- Original Message -----
    From: "Dmitry Stogov" <dmitry@zend.com>
    To: "'Steph Fox'" <steph@zend.com>
    Cc: "'internals'" <internals@lists.php.net>
    Sent: Thursday, June 01, 2006 1:25 PM
    Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

    Patch was cutted.

    Dmitry.
    -----Original Message-----
    From: Dmitry Stogov
    Sent: Thursday, June 01, 2006 3:05 PM
    To: 'Andi Gutmans'; 'Steph Fox'; 'Frank M. Kromann'
    Cc: 'internals'; 'Antony Dovgal'; 'Xuefer'
    Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    Hi Stepth,

    I reproduced crash of php-gtk on linix with php-zts.
    I mean running "php -v" then php.ini contains
    "extension=gtk2.so". The crash occurs only then php compiled
    with --enable-debug.

    The reason of the crash is a bug in ZE that is activated by
    memory leaks in php-gtk. In case of "php -v" we don't do
    request startup/shutdown and as result we don't handle memory
    leaks on request shutdown. During tsrm_shutdown()
    shutdow_nmemory_manager() is called after sapi_shutdown() and
    as result we cannot access sapi_globals then trying to print
    information about memory leaks and crashes.

    The solution - don't print information about memory leaks
    during tsrm_shutdown().

    Patch for PHP_5_2 is attached, but it can be manually applied
    to any version.

    Steph, does you crash(es) go away with this patch?

    I am going to commit patch in 24h.
    Any objections?

    Thanks. Dmitry.
    -----Original Message-----
    From: Andi Gutmans
    Sent: Thursday, June 01, 2006 10:29 AM
    To: Steph Fox; Frank M. Kromann
    Cc: 'internals'; 'Antony Dovgal'; Dmitry Stogov; 'Xuefer'
    Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI


    As we are not planning to release a new version within the next
    couple of weeks, I suggest before jumping to conclusions we
    take a look at it.

    If you really need to comment out that line in the meanwhile
    that's OK with me.

    Andi
    At 09:50 PM 5/31/2006, Steph Fox wrote:
    Yes, it would, given the root cause - but would you
    really want to
    break the whole of PHP for an academic exercise?
    It's not really an academic exercise. If we know there's a bug
    someplace we should at least look into it and try and
    understand it.
    Frank's referring to Zeev's three-years-ago decision to simply opt
    out of tsrm_shutdown() here... he's suggesting we revert it.
    Then if we decide to remove the trsm_shutdown call for a
    good reason
    (circular dependency, blah blah blah) then we can do that
    and put a
    nice fat comment on why it's the right thing to do. But I
    do think
    it's benefical to try and understand what's happening.
    Fine, but breaking working code while you're trying to understand
    what's happening is far from beneficial to our users. Can't
    we at least #0 it?
    Andi
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com

    --------------------------------------------------------------------------------

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

    __________ NOD32 1.1380 (20060125) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 27, '06 at 6:48p
activeJun 5, '06 at 11:59a
posts47
users9
websitephp.net

People

Translate

site design / logo © 2022 Grokbase