FAQ
Hi:

I have fixed #60825 (Segfault when running symfony 2 tests)

cvs mail here: http://news.php.net/php.cvs/67503

should I also commit this fix to 5.4 branch now?

thanks

--
Laruence  Xinchen Hui
http://www.laruence.com/

Search Discussions

  • Laruence at Jan 22, 2012 at 2:43 am
    send again,

    dsp said he didn't received.

    thanks
    On Sun, Jan 22, 2012 at 1:19 AM, Laruence wrote:
    Hi:

    I have fixed #60825 (Segfault when running symfony 2 tests)

    cvs mail here: http://news.php.net/php.cvs/67503

    should I also commit this fix to 5.4 branch now?

    thanks

    --
    Laruence  Xinchen Hui
    http://www.laruence.com/


    --
    Laruence  Xinchen Hui
    http://www.laruence.com/
  • Dmitry Stogov at Jan 23, 2012 at 8:09 am
    Hi Laruence,

    I'm not sure if the proposed patch fixes all the problems.

    Imagine that __FILE__ stored in some PHP variable and accessed after
    include() has finished. That time C variable "tmp_inc_filename" won't be
    valid but PHP variable may still refer to it.

    I didn't try to reproduce it, so I might be wrong.

    Thanks. Dmitry.
    On 01/22/2012 06:42 AM, Laruence wrote:
    send again,

    dsp said he didn't received.

    thanks

    On Sun, Jan 22, 2012 at 1:19 AM, Laruencewrote:
    Hi:

    I have fixed #60825 (Segfault when running symfony 2 tests)

    cvs mail here: http://news.php.net/php.cvs/67503

    should I also commit this fix to 5.4 branch now?

    thanks

    --
    Laruence Xinchen Hui
    http://www.laruence.com/
  • Laruence at Jan 23, 2012 at 9:02 am

    On Mon, Jan 23, 2012 at 4:09 PM, Dmitry Stogov wrote:
    Hi Laruence,

    I'm not sure if the proposed patch fixes all the problems.

    Imagine that __FILE__ stored in some PHP variable and accessed after
    include() has finished. That time C variable "tmp_inc_filename" won't be
    valid but PHP variable may still refer to it.
    Hi,

    I am not sure whether I got your point,

    but zend_std_cast_object_tostring will duplicate that "string", so
    zval_dtor tmp_inc_filename will okey(just efree that duplicate) I
    think. :)

    thanks
    I didn't try to reproduce it, so I might be wrong.

    Thanks. Dmitry.

    On 01/22/2012 06:42 AM, Laruence wrote:

    send again,

    dsp said he didn't received.

    thanks

    On Sun, Jan 22, 2012 at 1:19 AM, Laruencewrote:
    Hi:

    I have fixed #60825 (Segfault when running symfony 2 tests)

    cvs mail here: http://news.php.net/php.cvs/67503

    should I also commit this fix to 5.4 branch now?

    thanks

    --
    Laruence  Xinchen Hui
    http://www.laruence.com/



    --
    Laruence  Xinchen Hui
    http://www.laruence.com/
  • Dmitry Stogov at Jan 24, 2012 at 12:19 pm
    Hi Laruence,

    I'll try to demonstrate the problem I tried to describe with a script.
    The following script is still fails on trunk.

    <?php
    class test {
    public static $x;
    public function __toString() {
    self::$x = $this;
    return __FILE__;
    }
    }
    $a = new test;
    require_once $a;
    var_dump(test::$x);
    ?>

    So your fix is not enough.
    It make no sense to play with refcounts of zvals allocated on stack.
    Probably, the temporary zval needs to be allocated on heap.

    Tahnks. Dmitry.

    [dmitry@ws CGI-DEBUG]$ USE_ZEND_ALLOC=0 valgrind
    ../../php-trunk/CGI-DEBUG/sapi/cli/php -n bug60825.php
    ==25455== Memcheck, a memory error detector
    ==25455== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
    ==25455== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
    ==25455== Command: ../../php-trunk/CGI-DEBUG/sapi/cli/php -n bug60825.php
    ==25455==
    ==25455== Conditional jump or move depends on uninitialised value(s)
    ==25455== at 0x853E3C9: zend_send_by_var_helper_SPEC_VAR
    (zend_execute.c:71)
    ==25455== by 0x853F9C0: ZEND_SEND_VAR_SPEC_VAR_HANDLER
    (zend_vm_execute.h:11056)
    ==25455== by 0x8511872: execute (zend_vm_execute.h:410)
    ==25455== by 0x84DBE85: zend_execute_scripts (zend.c:1272)
    ==25455== by 0x8462641: php_execute_script (main.c:2476)
    ==25455== by 0x85F1506: do_cli (php_cli.c:983)
    ==25455== by 0x85F2678: main (php_cli.c:1356)
    ==25455==
    &UNKNOWN:0
    ==25455== Invalid read of size 4
    ==25455== at 0x84C9964: _zval_ptr_dtor (zend.h:391)
    ==25455== by 0x84CEE6E: cleanup_user_class_data (zend_opcode.c:165)
    ==25455== by 0x84CEF5D: zend_cleanup_user_class_data (zend_opcode.c:198)
    ==25455== by 0x84EB22C: zend_hash_reverse_apply (zend_hash.c:799)
    ==25455== by 0x84C958B: shutdown_executor (zend_execute_API.c:289)
    ==25455== by 0x84DB12B: zend_deactivate (zend.c:934)
    ==25455== by 0x8461441: php_request_shutdown (main.c:1782)
    ==25455== by 0x85F1EBC: do_cli (php_cli.c:1169)
    ==25455== by 0x85F2678: main (php_cli.c:1356)
    ==25455== Address 0xfee969e4 is not stack'd, malloc'd or (recently) free'd
    ==25455==
    ==25455== Invalid write of size 4
    ==25455== at 0x84C996D: _zval_ptr_dtor (zend.h:391)
    ==25455== by 0x84CEE6E: cleanup_user_class_data (zend_opcode.c:165)
    ==25455== by 0x84CEF5D: zend_cleanup_user_class_data (zend_opcode.c:198)
    ==25455== by 0x84EB22C: zend_hash_reverse_apply (zend_hash.c:799)
    ==25455== by 0x84C958B: shutdown_executor (zend_execute_API.c:289)
    ==25455== by 0x84DB12B: zend_deactivate (zend.c:934)
    ==25455== by 0x8461441: php_request_shutdown (main.c:1782)
    ==25455== by 0x85F1EBC: do_cli (php_cli.c:1169)
    ==25455== by 0x85F2678: main (php_cli.c:1356)
    ==25455== Address 0xfee969e4 is not stack'd, malloc'd or (recently) free'd
    ==25455==
    ==25455== Invalid read of size 4
    ==25455== at 0x84C997B: _zval_ptr_dtor (zend.h:379)
    ==25455== by 0x84CEE6E: cleanup_user_class_data (zend_opcode.c:165)
    ==25455== by 0x84CEF5D: zend_cleanup_user_class_data (zend_opcode.c:198)
    ==25455== by 0x84EB22C: zend_hash_reverse_apply (zend_hash.c:799)
    ==25455== by 0x84C958B: shutdown_executor (zend_execute_API.c:289)
    ==25455== by 0x84DB12B: zend_deactivate (zend.c:934)
    ==25455== by 0x8461441: php_request_shutdown (main.c:1782)
    ==25455== by 0x85F1EBC: do_cli (php_cli.c:1169)
    ==25455== by 0x85F2678: main (php_cli.c:1356)
    ==25455== Address 0xfee969e4 is not stack'd, malloc'd or (recently) free'd
    ==25455==
    ==25455== Invalid read of size 4
    ==25455== at 0x84C9A1E: _zval_ptr_dtor (zend.h:379)
    ==25455== by 0x84CEE6E: cleanup_user_class_data (zend_opcode.c:165)
    ==25455== by 0x84CEF5D: zend_cleanup_user_class_data (zend_opcode.c:198)
    ==25455== by 0x84EB22C: zend_hash_reverse_apply (zend_hash.c:799)
    ==25455== by 0x84C958B: shutdown_executor (zend_execute_API.c:289)
    ==25455== by 0x84DB12B: zend_deactivate (zend.c:934)
    ==25455== by 0x8461441: php_request_shutdown (main.c:1782)
    ==25455== by 0x85F1EBC: do_cli (php_cli.c:1169)
    ==25455== by 0x85F2678: main (php_cli.c:1356)
    ==25455== Address 0xfee969e4 is not stack'd, malloc'd or (recently) free'd
    ==25455==
    ==25455== Invalid read of size 1
    ==25455== at 0x84C9A40: _zval_ptr_dtor (zend_gc.h:182)
    ==25455== by 0x84CEE6E: cleanup_user_class_data (zend_opcode.c:165)
    ==25455== by 0x84CEF5D: zend_cleanup_user_class_data (zend_opcode.c:198)
    ==25455== by 0x84EB22C: zend_hash_reverse_apply (zend_hash.c:799)
    ==25455== by 0x84C958B: shutdown_executor (zend_execute_API.c:289)
    ==25455== by 0x84DB12B: zend_deactivate (zend.c:934)
    ==25455== by 0x8461441: php_request_shutdown (main.c:1782)
    ==25455== by 0x85F1EBC: do_cli (php_cli.c:1169)
    ==25455== by 0x85F2678: main (php_cli.c:1356)
    ==25455== Address 0xfee969e8 is not stack'd, malloc'd or (recently) free'd
    ==25455==
    ==25455== Invalid read of size 1
    ==25455== at 0x84C9A4B: _zval_ptr_dtor (zend_gc.h:182)
    ==25455== by 0x84CEE6E: cleanup_user_class_data (zend_opcode.c:165)
    ==25455== by 0x84CEF5D: zend_cleanup_user_class_data (zend_opcode.c:198)
    ==25455== by 0x84EB22C: zend_hash_reverse_apply (zend_hash.c:799)
    ==25455== by 0x84C958B: shutdown_executor (zend_execute_API.c:289)
    ==25455== by 0x84DB12B: zend_deactivate (zend.c:934)
    ==25455== by 0x8461441: php_request_shutdown (main.c:1782)
    ==25455== by 0x85F1EBC: do_cli (php_cli.c:1169)
    ==25455== by 0x85F2678: main (php_cli.c:1356)
    ==25455== Address 0xfee969e8 is not stack'd, malloc'd or (recently) free'd
    ==25455==
    ==25455==
    ==25455== HEAP SUMMARY:
    ==25455== in use at exit: 36,448 bytes in 2,333 blocks
    ==25455== total heap usage: 20,378 allocs, 18,045 frees, 2,405,048
    bytes allocated
    ==25455==
    ==25455== LEAK SUMMARY:
    ==25455== definitely lost: 0 bytes in 0 blocks
    ==25455== indirectly lost: 0 bytes in 0 blocks
    ==25455== possibly lost: 0 bytes in 0 blocks
    ==25455== still reachable: 36,448 bytes in 2,333 blocks
    ==25455== suppressed: 0 bytes in 0 blocks
    ==25455== Rerun with --leak-check=full to see details of leaked memory
    ==25455==
    ==25455== For counts of detected and suppressed errors, rerun with: -v
    ==25455== Use --track-origins=yes to see where uninitialised values come
    from
    ==25455== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)
    On 01/23/2012 01:02 PM, Laruence wrote:
    On Mon, Jan 23, 2012 at 4:09 PM, Dmitry Stogovwrote:
    Hi Laruence,

    I'm not sure if the proposed patch fixes all the problems.

    Imagine that __FILE__ stored in some PHP variable and accessed after
    include() has finished. That time C variable "tmp_inc_filename" won't be
    valid but PHP variable may still refer to it.
    Hi,

    I am not sure whether I got your point,

    but zend_std_cast_object_tostring will duplicate that "string", so
    zval_dtor tmp_inc_filename will okey(just efree that duplicate) I
    think. :)

    thanks
    I didn't try to reproduce it, so I might be wrong.

    Thanks. Dmitry.

    On 01/22/2012 06:42 AM, Laruence wrote:

    send again,

    dsp said he didn't received.

    thanks

    On Sun, Jan 22, 2012 at 1:19 AM, Laruencewrote:
    Hi:

    I have fixed #60825 (Segfault when running symfony 2 tests)

    cvs mail here: http://news.php.net/php.cvs/67503

    should I also commit this fix to 5.4 branch now?

    thanks

    --
    Laruence Xinchen Hui
    http://www.laruence.com/

  • Laruence at Jan 24, 2012 at 1:09 pm
    Hi Dmitry,

    ah, I see, thanks very much.

    in this case, the 5.3 branch should failed too since it also use a
    stack zval.

    I will make a improved fix soon.. :)
    thanks.
    On Tue, Jan 24, 2012 at 8:19 PM, Dmitry Stogov wrote:
    Hi Laruence,

    I'll try to demonstrate the problem I tried to describe with a script.
    The following script is still fails on trunk.

    <?php
    class test {
    public static $x;
    public function __toString() {
    self::$x = $this;
    return __FILE__;
    }
    }
    $a = new test;
    require_once $a;
    var_dump(test::$x);
    ?>

    So your fix is not enough.
    It make no sense to play with refcounts of zvals allocated on stack.
    Probably, the temporary zval needs to be allocated on heap.

    Tahnks. Dmitry.

    [dmitry@ws CGI-DEBUG]$ USE_ZEND_ALLOC=0 valgrind
    ../../php-trunk/CGI-DEBUG/sapi/cli/php -n bug60825.php
    ==25455== Memcheck, a memory error detector
    ==25455== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
    ==25455== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
    ==25455== Command: ../../php-trunk/CGI-DEBUG/sapi/cli/php -n bug60825.php
    ==25455==
    ==25455== Conditional jump or move depends on uninitialised value(s)
    ==25455==    at 0x853E3C9: zend_send_by_var_helper_SPEC_VAR
    (zend_execute.c:71)
    ==25455==    by 0x853F9C0: ZEND_SEND_VAR_SPEC_VAR_HANDLER
    (zend_vm_execute.h:11056)
    ==25455==    by 0x8511872: execute (zend_vm_execute.h:410)
    ==25455==    by 0x84DBE85: zend_execute_scripts (zend.c:1272)
    ==25455==    by 0x8462641: php_execute_script (main.c:2476)
    ==25455==    by 0x85F1506: do_cli (php_cli.c:983)
    ==25455==    by 0x85F2678: main (php_cli.c:1356)
    ==25455==
    &UNKNOWN:0
    ==25455== Invalid read of size 4
    ==25455==    at 0x84C9964: _zval_ptr_dtor (zend.h:391)
    ==25455==    by 0x84CEE6E: cleanup_user_class_data (zend_opcode.c:165)
    ==25455==    by 0x84CEF5D: zend_cleanup_user_class_data (zend_opcode.c:198)
    ==25455==    by 0x84EB22C: zend_hash_reverse_apply (zend_hash.c:799)
    ==25455==    by 0x84C958B: shutdown_executor (zend_execute_API.c:289)
    ==25455==    by 0x84DB12B: zend_deactivate (zend.c:934)
    ==25455==    by 0x8461441: php_request_shutdown (main.c:1782)
    ==25455==    by 0x85F1EBC: do_cli (php_cli.c:1169)
    ==25455==    by 0x85F2678: main (php_cli.c:1356)
    ==25455==  Address 0xfee969e4 is not stack'd, malloc'd or (recently) free'd
    ==25455==
    ==25455== Invalid write of size 4
    ==25455==    at 0x84C996D: _zval_ptr_dtor (zend.h:391)
    ==25455==    by 0x84CEE6E: cleanup_user_class_data (zend_opcode.c:165)
    ==25455==    by 0x84CEF5D: zend_cleanup_user_class_data (zend_opcode.c:198)
    ==25455==    by 0x84EB22C: zend_hash_reverse_apply (zend_hash.c:799)
    ==25455==    by 0x84C958B: shutdown_executor (zend_execute_API.c:289)
    ==25455==    by 0x84DB12B: zend_deactivate (zend.c:934)
    ==25455==    by 0x8461441: php_request_shutdown (main.c:1782)
    ==25455==    by 0x85F1EBC: do_cli (php_cli.c:1169)
    ==25455==    by 0x85F2678: main (php_cli.c:1356)
    ==25455==  Address 0xfee969e4 is not stack'd, malloc'd or (recently) free'd
    ==25455==
    ==25455== Invalid read of size 4
    ==25455==    at 0x84C997B: _zval_ptr_dtor (zend.h:379)
    ==25455==    by 0x84CEE6E: cleanup_user_class_data (zend_opcode.c:165)
    ==25455==    by 0x84CEF5D: zend_cleanup_user_class_data (zend_opcode.c:198)
    ==25455==    by 0x84EB22C: zend_hash_reverse_apply (zend_hash.c:799)
    ==25455==    by 0x84C958B: shutdown_executor (zend_execute_API.c:289)
    ==25455==    by 0x84DB12B: zend_deactivate (zend.c:934)
    ==25455==    by 0x8461441: php_request_shutdown (main.c:1782)
    ==25455==    by 0x85F1EBC: do_cli (php_cli.c:1169)
    ==25455==    by 0x85F2678: main (php_cli.c:1356)
    ==25455==  Address 0xfee969e4 is not stack'd, malloc'd or (recently) free'd
    ==25455==
    ==25455== Invalid read of size 4
    ==25455==    at 0x84C9A1E: _zval_ptr_dtor (zend.h:379)
    ==25455==    by 0x84CEE6E: cleanup_user_class_data (zend_opcode.c:165)
    ==25455==    by 0x84CEF5D: zend_cleanup_user_class_data (zend_opcode.c:198)
    ==25455==    by 0x84EB22C: zend_hash_reverse_apply (zend_hash.c:799)
    ==25455==    by 0x84C958B: shutdown_executor (zend_execute_API.c:289)
    ==25455==    by 0x84DB12B: zend_deactivate (zend.c:934)
    ==25455==    by 0x8461441: php_request_shutdown (main.c:1782)
    ==25455==    by 0x85F1EBC: do_cli (php_cli.c:1169)
    ==25455==    by 0x85F2678: main (php_cli.c:1356)
    ==25455==  Address 0xfee969e4 is not stack'd, malloc'd or (recently) free'd
    ==25455==
    ==25455== Invalid read of size 1
    ==25455==    at 0x84C9A40: _zval_ptr_dtor (zend_gc.h:182)
    ==25455==    by 0x84CEE6E: cleanup_user_class_data (zend_opcode.c:165)
    ==25455==    by 0x84CEF5D: zend_cleanup_user_class_data (zend_opcode.c:198)
    ==25455==    by 0x84EB22C: zend_hash_reverse_apply (zend_hash.c:799)
    ==25455==    by 0x84C958B: shutdown_executor (zend_execute_API.c:289)
    ==25455==    by 0x84DB12B: zend_deactivate (zend.c:934)
    ==25455==    by 0x8461441: php_request_shutdown (main.c:1782)
    ==25455==    by 0x85F1EBC: do_cli (php_cli.c:1169)
    ==25455==    by 0x85F2678: main (php_cli.c:1356)
    ==25455==  Address 0xfee969e8 is not stack'd, malloc'd or (recently) free'd
    ==25455==
    ==25455== Invalid read of size 1
    ==25455==    at 0x84C9A4B: _zval_ptr_dtor (zend_gc.h:182)
    ==25455==    by 0x84CEE6E: cleanup_user_class_data (zend_opcode.c:165)
    ==25455==    by 0x84CEF5D: zend_cleanup_user_class_data (zend_opcode.c:198)
    ==25455==    by 0x84EB22C: zend_hash_reverse_apply (zend_hash.c:799)
    ==25455==    by 0x84C958B: shutdown_executor (zend_execute_API.c:289)
    ==25455==    by 0x84DB12B: zend_deactivate (zend.c:934)
    ==25455==    by 0x8461441: php_request_shutdown (main.c:1782)
    ==25455==    by 0x85F1EBC: do_cli (php_cli.c:1169)
    ==25455==    by 0x85F2678: main (php_cli.c:1356)
    ==25455==  Address 0xfee969e8 is not stack'd, malloc'd or (recently) free'd
    ==25455==
    ==25455==
    ==25455== HEAP SUMMARY:
    ==25455==     in use at exit: 36,448 bytes in 2,333 blocks
    ==25455==   total heap usage: 20,378 allocs, 18,045 frees, 2,405,048 bytes
    allocated
    ==25455==
    ==25455== LEAK SUMMARY:
    ==25455==    definitely lost: 0 bytes in 0 blocks
    ==25455==    indirectly lost: 0 bytes in 0 blocks
    ==25455==      possibly lost: 0 bytes in 0 blocks
    ==25455==    still reachable: 36,448 bytes in 2,333 blocks
    ==25455==         suppressed: 0 bytes in 0 blocks
    ==25455== Rerun with --leak-check=full to see details of leaked memory
    ==25455==
    ==25455== For counts of detected and suppressed errors, rerun with: -v
    ==25455== Use --track-origins=yes to see where uninitialised values come
    from
    ==25455== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)

    On 01/23/2012 01:02 PM, Laruence wrote:

    On Mon, Jan 23, 2012 at 4:09 PM, Dmitry Stogovwrote:
    Hi Laruence,

    I'm not sure if the proposed patch fixes all the problems.

    Imagine that __FILE__ stored in some PHP variable and accessed after
    include() has finished. That time C variable "tmp_inc_filename" won't be
    valid but PHP variable may still refer to it.
    Hi,

    I am not sure whether I got your point,

    but zend_std_cast_object_tostring will duplicate that "string", so
    zval_dtor tmp_inc_filename will okey(just efree that duplicate) I
    think. :)

    thanks
    I didn't try to reproduce it, so I might be wrong.

    Thanks. Dmitry.

    On 01/22/2012 06:42 AM, Laruence wrote:


    send again,

    dsp said he didn't received.

    thanks

    On Sun, Jan 22, 2012 at 1:19 AM, Laruencewrote:

    Hi:

    I have fixed #60825 (Segfault when running symfony 2 tests)

    cvs mail here: http://news.php.net/php.cvs/67503

    should I also commit this fix to 5.4 branch now?

    thanks

    --
    Laruence  Xinchen Hui
    http://www.laruence.com/




    --
    Laruence  Xinchen Hui
    http://www.laruence.com/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJan 21, '12 at 5:19p
activeJan 24, '12 at 1:09p
posts6
users2
websitephp.net

2 users in discussion

Laruence: 4 posts Dmitry Stogov: 2 posts

People

Translate

site design / logo © 2022 Grokbase