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 Stogov<dmi...@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.
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, Laruence<larue...@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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
