Re: segfault after an "invalid read of size 8"

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