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/
send again,
dsp said he didn't received.
thanks
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/
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.
send again,
dsp said he didn't received.
thanks
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/
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.
send again,
dsp said he didn't received.
thanks
On Sun, Jan 22, 2012 at 1:19 AM, Laruencelaruence@php.net 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/
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)
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.
send again,
dsp said he didn't received.
thanks
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/
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.
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 Mon, Jan 23, 2012 at 4:09 PM, Dmitry Stogovdmitry@zend.com 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.
send again,
dsp said he didn't received.
thanks
On Sun, Jan 22, 2012 at 1:19 AM, Laruencelaruence@php.net 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/