Hello,
I have a script which throw a segfault, in cli with PHP 5.2.6 (I just
recompiled it from source).
I track the error with valgrind, and obtain this as a result :
==17069== Invalid read of size 8
==17069== at 0x6CBCAC: _zend_mm_alloc_int (zend_alloc.c:1767)
==17069== by 0x6CC1DF: _estrndup (zend_alloc.c:2422)
==17069== by 0x6EFFDC: add_assoc_string_ex (zend_API.c:1038)
==17069== by 0x567027: zif_posix_uname (posix.c:466)
==17069== by 0x71E3AC: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==17069== by 0x709983: execute (zend_vm_execute.h:92)
==17069== by 0x6DA134: zend_call_function (zend_execute_API.c:1013)
==17069== by 0x6DB1C5: call_user_function_ex (zend_execute_API.c:640)
==17069== by 0x6DB241: call_user_function (zend_execute_API.c:613)
==17069== by 0x627D1A: user_shutdown_function_call
(basic_functions.c:5311)
==17069== by 0x6F133A: zend_hash_apply (zend_hash.c:673)
==17069== by 0x627FD5: php_call_shutdown_functions
(basic_functions.c:5395)
==17069== Address 0x61 is not stack'd, malloc'd or (recently) free'd
==17069==
==17069== Process terminating with default action of signal 11 (SIGSEGV)
==17069== Access not within mapped region at address 0x61
==17069== at 0x6CBCAC: _zend_mm_alloc_int (zend_alloc.c:1767)
==17069== by 0x6CC1DF: _estrndup (zend_alloc.c:2422)
==17069== by 0x6EFFDC: add_assoc_string_ex (zend_API.c:1038)
==17069== by 0x567027: zif_posix_uname (posix.c:466)
==17069== by 0x71E3AC: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==17069== by 0x709983: execute (zend_vm_execute.h:92)
==17069== by 0x6DA134: zend_call_function (zend_execute_API.c:1013)
==17069== by 0x6DB1C5: call_user_function_ex (zend_execute_API.c:640)
==17069== by 0x6DB241: call_user_function (zend_execute_API.c:613)
==17069== by 0x627D1A: user_shutdown_function_call
(basic_functions.c:5311)
==17069== by 0x6F133A: zend_hash_apply (zend_hash.c:673)
==17069== by 0x627FD5: php_call_shutdown_functions
(basic_functions.c:5395)
==17069==
==17069== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 66 from 4)
==17069== malloc/free: in use at exit: 2,641,381 bytes in 12,114 blocks.
==17069== malloc/free: 13,138 allocs, 1,024 frees, 7,178,514 bytes
allocated.
==17069== For counts of detected errors, rerun with: -v
==17069== searching for pointers to 12,114 not-freed blocks.
==17069== checked 2,442,920 bytes.
==17069==
==17069== LEAK SUMMARY:
==17069== definitely lost: 292 bytes in 11 blocks.
==17069== possibly lost: 0 bytes in 0 blocks.
==17069== still reachable: 2,641,089 bytes in 12,103 blocks.
==17069== suppressed: 0 bytes in 0 blocks.
==17069== Rerun with --leak-check=full to see details of leaked memory.
Should I try to reduce the size of the PHP script (actually it use a
framework) to can reproduce the problem ; or is this output of valgrind
is enough ?
Thanks,
Olivier
Em Sex, 2008-10-10 às 18:58 +0200, Olivier Bonvalet escreveu:
Hello,
I have a script which throw a segfault, in cli with PHP 5.2.6 (I just
recompiled it from source).I track the error with valgrind, and obtain this as a result :
==17069== Invalid read of size 8
==17069== at 0x6CBCAC: _zend_mm_alloc_int (zend_alloc.c:1767)
==17069== by 0x6CC1DF: _estrndup (zend_alloc.c:2422)
==17069== by 0x6EFFDC: add_assoc_string_ex (zend_API.c:1038)
==17069== by 0x567027: zif_posix_uname (posix.c:466)
==17069== by 0x71E3AC: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==17069== by 0x709983: execute (zend_vm_execute.h:92)
==17069== by 0x6DA134: zend_call_function (zend_execute_API.c:1013)
==17069== by 0x6DB1C5: call_user_function_ex (zend_execute_API.c:640)
==17069== by 0x6DB241: call_user_function (zend_execute_API.c:613)
==17069== by 0x627D1A: user_shutdown_function_call
(basic_functions.c:5311)
==17069== by 0x6F133A: zend_hash_apply (zend_hash.c:673)
==17069== by 0x627FD5: php_call_shutdown_functions
(basic_functions.c:5395)
==17069== Address 0x61 is not stack'd, malloc'd or (recently) free'd
==17069==
==17069== Process terminating with default action of signal 11 (SIGSEGV)
==17069== Access not within mapped region at address 0x61
==17069== at 0x6CBCAC: _zend_mm_alloc_int (zend_alloc.c:1767)
==17069== by 0x6CC1DF: _estrndup (zend_alloc.c:2422)
==17069== by 0x6EFFDC: add_assoc_string_ex (zend_API.c:1038)
==17069== by 0x567027: zif_posix_uname (posix.c:466)
==17069== by 0x71E3AC: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==17069== by 0x709983: execute (zend_vm_execute.h:92)
==17069== by 0x6DA134: zend_call_function (zend_execute_API.c:1013)
==17069== by 0x6DB1C5: call_user_function_ex (zend_execute_API.c:640)
==17069== by 0x6DB241: call_user_function (zend_execute_API.c:613)
==17069== by 0x627D1A: user_shutdown_function_call
(basic_functions.c:5311)
==17069== by 0x6F133A: zend_hash_apply (zend_hash.c:673)
==17069== by 0x627FD5: php_call_shutdown_functions
(basic_functions.c:5395)
==17069==
==17069== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 66 from 4)
==17069== malloc/free: in use at exit: 2,641,381 bytes in 12,114 blocks.
==17069== malloc/free: 13,138 allocs, 1,024 frees, 7,178,514 bytes
allocated.
==17069== For counts of detected errors, rerun with: -v
==17069== searching for pointers to 12,114 not-freed blocks.
==17069== checked 2,442,920 bytes.
==17069==
==17069== LEAK SUMMARY:
==17069== definitely lost: 292 bytes in 11 blocks.
==17069== possibly lost: 0 bytes in 0 blocks.
==17069== still reachable: 2,641,089 bytes in 12,103 blocks.
==17069== suppressed: 0 bytes in 0 blocks.
==17069== Rerun with --leak-check=full to see details of leaked memory.Should I try to reduce the size of the PHP script (actually it use a
framework) to can reproduce the problem ; or is this output of valgrind
is enough ?
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
In case of segfaulting with the latest version, file a bug at
http://bugs.php.net
Thanks. :)
--
Regards,
Felipe Pena
Thanks, with this version I obtain this valgrind output :
==6577== Conditional jump or move depends on uninitialised value(s)
==6577== at 0x6CB2DB: _zend_mm_free_int (zend_alloc.c:1941)
==6577== by 0x710210: ZEND_CONCAT_SPEC_CV_TMP_HANDLER
(zend_variables.h:35)
==6577== by 0x709D63: execute (zend_vm_execute.h:92)
==6577== by 0x6DA33C: zend_call_function (zend_execute_API.c:1015)
==6577== by 0x6DB3C5: call_user_function_ex (zend_execute_API.c:640)
==6577== by 0x6DB441: call_user_function (zend_execute_API.c:613)
==6577== by 0x627DAA: user_shutdown_function_call
(basic_functions.c:5311)
==6577== by 0x6F158A: zend_hash_apply (zend_hash.c:673)
==6577== by 0x628065: php_call_shutdown_functions
(basic_functions.c:5395)
==6577== by 0x6A2B44: php_request_shutdown (main.c:1446)
==6577== by 0x75B0B3: main (php_cli.c:1315)
==6577==
==6577== Use of uninitialised value of size 8
==6577== at 0x6CB33A: _zend_mm_free_int (zend_alloc.c:1963)
==6577== by 0x710210: ZEND_CONCAT_SPEC_CV_TMP_HANDLER
(zend_variables.h:35)
==6577== by 0x709D63: execute (zend_vm_execute.h:92)
==6577== by 0x6DA33C: zend_call_function (zend_execute_API.c:1015)
==6577== by 0x6DB3C5: call_user_function_ex (zend_execute_API.c:640)
==6577== by 0x6DB441: call_user_function (zend_execute_API.c:613)
==6577== by 0x627DAA: user_shutdown_function_call
(basic_functions.c:5311)
==6577== by 0x6F158A: zend_hash_apply (zend_hash.c:673)
==6577== by 0x628065: php_call_shutdown_functions
(basic_functions.c:5395)
==6577== by 0x6A2B44: php_request_shutdown (main.c:1446)
==6577== by 0x75B0B3: main (php_cli.c:1315)
==6577==
==6577== Invalid read of size 1
==6577== at 0x6CB33A: _zend_mm_free_int (zend_alloc.c:1963)
==6577== by 0x710210: ZEND_CONCAT_SPEC_CV_TMP_HANDLER
(zend_variables.h:35)
==6577== by 0x709D63: execute (zend_vm_execute.h:92)
==6577== by 0x6DA33C: zend_call_function (zend_execute_API.c:1015)
==6577== by 0x6DB3C5: call_user_function_ex (zend_execute_API.c:640)
==6577== by 0x6DB441: call_user_function (zend_execute_API.c:613)
==6577== by 0x627DAA: user_shutdown_function_call
(basic_functions.c:5311)
==6577== by 0x6F158A: zend_hash_apply (zend_hash.c:673)
==6577== by 0x628065: php_call_shutdown_functions
(basic_functions.c:5395)
==6577== by 0x6A2B44: php_request_shutdown (main.c:1446)
==6577== by 0x75B0B3: main (php_cli.c:1315)
==6577== Address 0x706eda800 is not stack'd, malloc'd or (recently) free'd
==6577==
==6577== Process terminating with default action of signal 11 (SIGSEGV)
==6577== Access not within mapped region at address 0x706EDA800
==6577== at 0x6CB33A: _zend_mm_free_int (zend_alloc.c:1963)
==6577== by 0x710210: ZEND_CONCAT_SPEC_CV_TMP_HANDLER
(zend_variables.h:35)
==6577== by 0x709D63: execute (zend_vm_execute.h:92)
==6577== by 0x6DA33C: zend_call_function (zend_execute_API.c:1015)
==6577== by 0x6DB3C5: call_user_function_ex (zend_execute_API.c:640)
==6577== by 0x6DB441: call_user_function (zend_execute_API.c:613)
==6577== by 0x627DAA: user_shutdown_function_call
(basic_functions.c:5311)
==6577== by 0x6F158A: zend_hash_apply (zend_hash.c:673)
==6577== by 0x628065: php_call_shutdown_functions
(basic_functions.c:5395)
==6577== by 0x6A2B44: php_request_shutdown (main.c:1446)
==6577== by 0x75B0B3: main (php_cli.c:1315)
==6577==
==6577== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 66 from 4)
==6577== malloc/free: in use at exit: 2,641,381 bytes in 12,114 blocks.
==6577== malloc/free: 13,138 allocs, 1,024 frees, 7,178,513 bytes allocated.
==6577== For counts of detected errors, rerun with: -v
==6577== searching for pointers to 12,114 not-freed blocks.
==6577== checked 2,441,216 bytes.
==6577==
==6577== LEAK SUMMARY:
==6577== definitely lost: 292 bytes in 11 blocks.
==6577== possibly lost: 0 bytes in 0 blocks.
==6577== still reachable: 2,641,089 bytes in 12,103 blocks.
==6577== suppressed: 0 bytes in 0 blocks.
==6577== Rerun with --leak-check=full to see details of leaked memory.
Felipe Pena a écrit :
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msiIn case of segfaulting with the latest version, file a bug at
http://bugs.php.netThanks. :)
Olivier Bonvalet escribió:
Should I try to reduce the size of the PHP script (actually it use a
framework) to can reproduce the problem ; or is this output of valgrind
is enough ?
what does
<?php
var_dump(posix_uname());
?>
produces in your system and what OS are you using ?
--
"A computer is like an Old Testament god, with a lot of rules and no
mercy. "
Cristian Rodríguez R.
Platform/OpenSUSE - Core Services
SUSE LINUX Products GmbH
Research & Development
http://www.opensuse.org/
Hello,
it's a Debian Lenny (testing) 64bits :
Linux debian 2.6.26-1-amd64 #1 SMP Wed Sep 10 15:31:12 UTC 2008
x86_64 GNU/Linux
(and I have the problem with the Debian version of PHP too)
Cristian Rodríguez a écrit :
Olivier Bonvalet escribió:
Should I try to reduce the size of the PHP script (actually it use a
framework) to can reproduce the problem ; or is this output of valgrind
is enough ?what does
<?php
var_dump(posix_uname());
?>
produces in your system and what OS are you using ?
So, I reduce the script which throw the segmentation fault.
My environment :
Debian Lenny, 64bits
Latest PHP 5.2 from CVS (php5.2-200810151030) compiled with :
./configure --prefix=/home/dev-olivier/usr/ --disable-all
--enable-debug
In "first.php" I have this code :
<?php
class main
{
public static $dummy = NULL ;
public static $dataAccessor = NULL ;
}
class dataAccessor
{
}
class relay
{
public function __get( $name )
{
main::$dataAccessor = new dataAccessor;
}
}
class dummy
{
}
main::$dummy = new dummy();
main::$dataAccessor = new relay();
?>
And in "second.php" I have this :
(if I regroup all code in one file, there is no segfault)
============================================================
<?php
error_reporting( E_ALL | E_NOTICE );
require 'first.php';
main::$dataAccessor->bar;
?>
If I do :
export USE_ZEND_ALLOC=1 ; /home/dev-olivier/usr/bin/php second.php
==> no segfault
export USE_ZEND_ALLOC=0 ; /home/dev-olivier/usr/bin/php second.php
==> segfault
Sometimes I obtain this output :
*** glibc detected *** /home/dev-olivier/usr/bin/php: corrupted
double-linked list: 0x0000000002603800 ***
======= Backtrace: =========
/lib/libc.so.6[0x7f038ba39948]
/lib/libc.so.6[0x7f038ba39bda]
/lib/libc.so.6[0x7f038ba3b708]
/lib/libc.so.6(cfree+0x76)[0x7f038ba3ba56]
/home/dev-olivier/usr/bin/php[0x53ec31]
/home/dev-olivier/usr/bin/php[0x53ecb3]
/home/dev-olivier/usr/bin/php[0x541d2b]
/home/dev-olivier/usr/bin/php(zend_mm_shutdown+0x4c)[0x540a80]
/home/dev-olivier/usr/bin/php(shutdown_memory_manager+0x20)[0x5436ae]
/home/dev-olivier/usr/bin/php(php_request_shutdown+0x31c)[0x50add9]
/home/dev-olivier/usr/bin/php(main+0x17c1)[0x5e6c24]
/lib/libc.so.6(__libc_start_main+0xe6)[0x7f038b9e41a6]
/home/dev-olivier/usr/bin/php[0x425c39]
======= Memory map: ========
00400000-006ad000 r-xp 00000000 fd:04 1968300
/home/dev-olivier/usr/bin/php
008ac000-008ca000 rw-p 002ac000 fd:04 1968300
/home/dev-olivier/usr/bin/php
008ca000-008cf000 rw-p 008ca000 00:00 0
0253b000-0260c000 rw-p 0253b000 00:00 0
[heap]
7f0384000000-7f0384021000 rw-p 7f0384000000 00:00 0
7f0384021000-7f0388000000 ---p 7f0384021000 00:00 0
7f038b5fe000-7f038b614000 r-xp 00000000 09:01 285898
/lib/libgcc_s.so.1
7f038b614000-7f038b814000 ---p 00016000 09:01 285898
/lib/libgcc_s.so.1
7f038b814000-7f038b815000 rw-p 00016000 09:01 285898
/lib/libgcc_s.so.1
7f038b815000-7f038b9c6000 r--p 00000000 09:01 261814
/usr/lib/locale/locale-archive
7f038b9c6000-7f038bb10000 r-xp 00000000 09:01 288347
/lib/libc-2.7.so
7f038bb10000-7f038bd0f000 ---p 0014a000 09:01 288347
/lib/libc-2.7.so
7f038bd0f000-7f038bd12000 r--p 00149000 09:01 288347
/lib/libc-2.7.so
7f038bd12000-7f038bd14000 rw-p 0014c000 09:01 288347
/lib/libc-2.7.so
7f038bd14000-7f038bd19000 rw-p 7f038bd14000 00:00 0
7f038bd19000-7f038bd2e000 r-xp 00000000 09:01 288291
/lib/libnsl-2.7.so
7f038bd2e000-7f038bf2d000 ---p 00015000 09:01 288291
/lib/libnsl-2.7.so
7f038bf2d000-7f038bf2f000 rw-p 00014000 09:01 288291
/lib/libnsl-2.7.so
7f038bf2f000-7f038bf31000 rw-p 7f038bf2f000 00:00 0
7f038bf31000-7f038bf33000 r-xp 00000000 09:01 288283
/lib/libdl-2.7.so
7f038bf33000-7f038c133000 ---p 00002000 09:01 288283
/lib/libdl-2.7.so
7f038c133000-7f038c135000 rw-p 00002000 09:01 288283
/lib/libdl-2.7.so
7f038c135000-7f038c1b7000 r-xp 00000000 09:01 301994
/lib/libm-2.7.so
7f038c1b7000-7f038c3b6000 ---p 00082000 09:01 301994
/lib/libm-2.7.so
7f038c3b6000-7f038c3b8000 rw-p 00081000 09:01 301994
/lib/libm-2.7.so
7f038c3b8000-7f038c3c8000 r-xp 00000000 09:01 301990
/lib/libresolv-2.7.so
7f038c3c8000-7f038c5c8000 ---p 00010000 09:01 301990
/lib/libresolv-2.7.so
7f038c5c8000-7f038c5ca000 rw-p 00010000 09:01 301990
/lib/libresolv-2.7.so
7f038c5ca000-7f038c5cc000 rw-p 7f038c5ca000 00:00 0
7f038c5cc000-7f038c5d4000 r-xp 00000000 09:01 288290
/lib/libcrypt-2.7.so
7f038c5d4000-7f038c7d4000 ---p 00008000 09:01 288290
/lib/libcrypt-2.7.so
7f038c7d4000-7f038c7d6000 rw-p 00008000 09:01 288290
/lib/libcrypt-2.7.so
7f038c7d6000-7f038c804000 rw-p 7f038c7d6000 00:00 0
7f038c804000-7f038c820000 r-xp 00000000 09:01 288285
/lib/ld-2.7.so
7f038ca0a000-7f038ca0e000 rw-p 7f038ca0a000 00:00 0
7f038ca19000-7f038ca1a000 rw-p 7f038ca19000 00:00 0
7f038ca1c000-7f038ca1f000 rw-p 7f038ca1c000 00:00 0
7f038ca1f000-7f038ca21000 rw-p 0001b000 09:01 288285
/lib/ld-2.7.so
7fff94a0b000-7fff94a20000 rw-p 7ffffffea000 00:00 0
[stack]
7fff94bfe000-7fff94bff000 r-xp 7fff94bfe000 00:00 0
[vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
[vsyscall]
Abort
And valgrind outputs this :
==12485== Memcheck, a memory error detector.
==12485== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==12485== Using LibVEX rev 1854, a library for dynamic binary translation.
==12485== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==12485== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation
framework.
==12485== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==12485== For more details, rerun with: -v
==12485==
==12485== Invalid write of size 1
==12485== at 0x585F25: zend_std_read_property
(zend_object_handlers.c:333)
==12485== by 0x5A796E:
zend_fetch_property_address_read_helper_SPEC_VAR_CONST
(zend_vm_execute.h:9107)
==12485== by 0x5A7AE6: ZEND_FETCH_OBJ_R_SPEC_VAR_CONST_HANDLER
(zend_vm_execute.h:9130)
==12485== by 0x58AE3A: execute (zend_vm_execute.h:92)
==12485== by 0x562D40: zend_execute_scripts (zend.c:1134)
==12485== by 0x50B98C: php_execute_script (main.c:2011)
==12485== by 0x5E635D: main (php_cli.c:1134)
==12485== Address 0x5db37d8 is 0 bytes inside a block of size 5 free'd
==12485== at 0x4C20B6E: free (vg_replace_malloc.c:323)
==12485== by 0x5430AC: _efree (zend_alloc.c:2293)
==12485== by 0x56FF50: zend_hash_destroy (zend_hash.c:529)
==12485== by 0x584837: zend_object_std_dtor (zend_objects.c:41)
==12485== by 0x584C71: zend_objects_free_object_storage
(zend_objects.c:122)
==12485== by 0x588E46: zend_objects_store_del_ref_by_handle
(zend_objects_API.c:206)
==12485== by 0x588C9E: zend_objects_store_del_ref
(zend_objects_API.c:168)
==12485== by 0x560748: _zval_dtor_func (zend_variables.c:52)
==12485== by 0x551772: _zval_dtor (zend_variables.h:35)
==12485== by 0x551986: _zval_ptr_dtor (zend_execute_API.c:414)
==12485== by 0x554323: zend_call_function (zend_execute_API.c:1040)
==12485== by 0x57C4A1: zend_call_method (zend_interfaces.c:88)
==12485==
==12485== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 8 from 1)
==12485== malloc/free: in use at exit: 0 bytes in 0 blocks.
==12485== malloc/free: 4,998 allocs, 4,998 frees, 1,397,127 bytes allocated.
==12485== For counts of detected errors, rerun with: -v
==12485== All heap blocks were freed -- no leaks are possible.
I hope this will help.
Olivier
Hi Olivier,
Em Qua, 2008-10-15 às 15:44 +0200, Olivier Bonvalet escreveu:
So, I reduce the script which throw the segmentation fault.
My environment :
Debian Lenny, 64bits
Latest PHP 5.2 from CVS (php5.2-200810151030) compiled with :
./configure --prefix=/home/dev-olivier/usr/ --disable-all
--enable-debugIn "first.php" I have this code :
<?php
class main
{
public static $dummy =NULL;
public static $dataAccessor =NULL;
}class dataAccessor
{
}class relay
{
public function __get( $name )
{
main::$dataAccessor = new dataAccessor;
}
}class dummy
{
}main::$dummy = new dummy();
main::$dataAccessor = new relay();
?>And in "second.php" I have this :
(if I regroup all code in one file, there is no segfault)
That is weird, cannot you reproduce it using the code below?
<?php
class main
{
public static $dataAccessor;
}
class relay
{
public function __get($name)
{
main::$dataAccessor = 1;
}
}
main::$dataAccessor = new relay();
var_dump(main::$dataAccessor->bar);
?>
Anyway, please file a bug report: http://bugs.php.net/report.php
Thanks.
--
Regards,
Felipe Pena
Hi Filipe,
there is not the problem with your code, the script works fine and show
"NULL".
I open this bug report : http://bugs.php.net/bug.php?id=46308
(I hope the title is correct... I did'nt know what to put...)
Thanks,
Olivier
Felipe Pena a écrit :
Hi Olivier,
That is weird, cannot you reproduce it using the code below?
<?php
class main
{
public static $dataAccessor;
}class relay
{
public function __get($name)
{
main::$dataAccessor = 1;
}
}main::$dataAccessor = new relay();
var_dump(main::$dataAccessor->bar);?>
Anyway, please file a bug report: http://bugs.php.net/report.php
Thanks.
Hello,
this bug was corrected in CVS on 17 oct, but I can't find the related
patch on http://news.php.net/php.cvs/start/53560
Does someone know which one is it ? I would like try to backport it to
PHP 5.2.6
Thanks in advance,
Olivier Bonvalet
Olivier Bonvalet a écrit :
Hi Filipe,
there is not the problem with your code, the script works fine and
show "NULL".I open this bug report : http://bugs.php.net/bug.php?id=46308
(I hope the title is correct... I did'nt know what to put...)Thanks,
OlivierFelipe Pena a écrit :
Hi Olivier,
That is weird, cannot you reproduce it using the code below?
<?php
class main
{
public static $dataAccessor;
}class relay
{
public function __get($name)
{
main::$dataAccessor = 1;
}
}main::$dataAccessor = new relay();
var_dump(main::$dataAccessor->bar);?>
Anyway, please file a bug report: http://bugs.php.net/report.php
Thanks.
Hello,
Em Dom, 2009-01-11 às 01:45 +0100, Olivier Bonvalet escreveu:
Hello,
this bug was corrected in CVS on 17 oct, but I can't find the related
patch on http://news.php.net/php.cvs/start/53560
Does someone know which one is it ? I would like try to backport it to
PHP 5.2.6Thanks in advance,
Olivier Bonvalet
See:
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_object_handlers.c?r1=1.135.2.6.2.28&r2=1.135.2.6.2.29
I think that it's only that.
--
Regards,
Felipe Pena
Thanks Felipe !
Felipe Pena a écrit :
Hello,
Em Dom, 2009-01-11 às 01:45 +0100, Olivier Bonvalet escreveu:
Hello,
this bug was corrected in CVS on 17 oct, but I can't find the related
patch on http://news.php.net/php.cvs/start/53560
Does someone know which one is it ? I would like try to backport it to
PHP 5.2.6Thanks in advance,
Olivier BonvaletSee:
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_object_handlers.c?r1=1.135.2.6.2.28&r2=1.135.2.6.2.29I think that it's only that.
Hi!
So, I reduce the script which throw the segmentation fault.
My environment :
Debian Lenny, 64bits
Latest PHP 5.2 from CVS (php5.2-200810151030) compiled with :
./configure --prefix=/home/dev-olivier/usr/ --disable-all
--enable-debug
Can reproduce the problem with valgrind and USE_ZEND_ALLOC=0 on 32-bit
with 5.3 HEAD. Looks like genuine bug.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev escribió:
Can reproduce the problem with valgrind and USE_ZEND_ALLOC=0 on 32-bit
with 5.3 HEAD. Looks like genuine bug.
Reproduced with 5_3 and 5_2 in 64 bit linux USE_ZEND_ALLOC=0, please
open a bug report..
--
"A computer is like an Old Testament god, with a lot of rules and no
mercy. "
Cristian Rodríguez R.
Platform/OpenSUSE - Core Services
SUSE LINUX Products GmbH
Research & Development
http://www.opensuse.org/