Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:40930 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 57190 invoked from network); 10 Oct 2008 17:15:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Oct 2008 17:15:32 -0000 Received: from [127.0.0.1] ([127.0.0.1:20078]) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ECSTREAM id F4/08-38373-3BD8FE84 for ; Fri, 10 Oct 2008 13:15:31 -0400 Authentication-Results: pb1.pair.com header.from=php.list@daevel.fr; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=php.list@daevel.fr; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain daevel.fr designates 91.121.160.166 as permitted sender) X-PHP-List-Original-Sender: php.list@daevel.fr X-Host-Fingerprint: 91.121.160.166 scrubby.daevel.fr Linux 2.6 Received: from [91.121.160.166] ([91.121.160.166:33828] helo=scrubby.daevel.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F4/A7-38373-5C98FE84 for ; Fri, 10 Oct 2008 12:58:46 -0400 Received: from luuna.daevel.fr ([82.67.25.170] helo=[192.168.1.50]) by scrubby.daevel.fr with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.68) (envelope-from ) id 1KoLK6-0007Yg-LW for internals@lists.php.net; Fri, 10 Oct 2008 18:58:42 +0200 Message-ID: <48EF89BD.5030904@daevel.fr> Date: Fri, 10 Oct 2008 18:58:37 +0200 User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: internals@lists.php.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: segfault after an "invalid read of size 8" From: php.list@daevel.fr (Olivier Bonvalet) 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