Edit report at https://bugs.php.net/bug.php?id=64297&edit=1
ID: 64297 User updated by: jille at hexon dot cx Reported by: jille at hexon dot cx Summary: Segfault after allowed memory exhausted Status: Open Type: Bug Package: Reproducible crash Operating System: Linux PHP Version: 5.4.12 Block user comment: N Private report: N New Comment: Yes. Exactly the same. Previous Comments: ------------------------------------------------------------------------ [2013-03-01 09:38:53] [email protected] nothing serious, so the segufalt backtrace is the same as before? ------------------------------------------------------------------------ [2013-03-01 08:15:56] jille at hexon dot cx ==30922== Memcheck, a memory error detector ==30922== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==30922== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==30922== Command: ./sapi/cli/php -d auto_prepend_file=auto_prepend_prepend.lib /data/www/htdocs/wheeler/daemons/daemon_wrapper 1023 live memcrash.php ==30922== ==30922== Invalid read of size 8 ==30922== at 0x77954D: _zend_mm_free_int (zend_alloc.c:2071) ==30922== by 0x795D61: destroy_op_array (zend_opcode.c:356) ==30922== by 0x7AD657: zend_hash_destroy (zend_hash.c:560) ==30922== by 0x79F860: zend_shutdown (zend.c:822) ==30922== by 0x741019: php_module_shutdown (main.c:2365) ==30922== by 0x433BE6: main (php_cli.c:1379) ==30922== Address 0x4ca5d948 is not stack'd, malloc'd or (recently) free'd ==30922== ==30922== ==30922== Process terminating with default action of signal 11 (SIGSEGV) ==30922== Access not within mapped region at address 0x4CA5D948 ==30922== at 0x77954D: _zend_mm_free_int (zend_alloc.c:2071) ==30922== by 0x795D61: destroy_op_array (zend_opcode.c:356) ==30922== by 0x7AD657: zend_hash_destroy (zend_hash.c:560) ==30922== by 0x79F860: zend_shutdown (zend.c:822) ==30922== by 0x741019: php_module_shutdown (main.c:2365) ==30922== by 0x433BE6: main (php_cli.c:1379) ==30922== If you believe this happened as a result of a stack ==30922== overflow in your program's main thread (unlikely but ==30922== possible), you can try to increase the size of the ==30922== main thread stack using the --main-stacksize= flag. ==30922== The main thread stack size used in this run was 8388608. ==30922== ==30922== HEAP SUMMARY: ==30922== in use at exit: 7,553,441 bytes in 20,136 blocks ==30922== total heap usage: 2,020,750 allocs, 2,000,614 frees, 1,564,536,722 bytes allocated ==30922== ==30922== LEAK SUMMARY: ==30922== definitely lost: 203,536 bytes in 3,635 blocks ==30922== indirectly lost: 4,029,186 bytes in 2,979 blocks ==30922== possibly lost: 70,648 bytes in 43 blocks ==30922== still reachable: 3,250,071 bytes in 13,479 blocks ==30922== suppressed: 0 bytes in 0 blocks ==30922== Rerun with --leak-check=full to see details of leaked memory ==30922== ==30922== For counts of detected and suppressed errors, rerun with: -v ==30922== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) Segmentation fault ------------------------------------------------------------------------ [2013-03-01 03:12:22] [email protected] do you get the new valgrind log? thanks ------------------------------------------------------------------------ [2013-02-25 15:51:09] jille at hexon dot cx Removing the memcache extension doesn't help. (gdb output seems the same, do you want the new valgrind output? (Takes a while)) ------------------------------------------------------------------------ [2013-02-25 14:56:49] [email protected] please remove the memcache extension then test it again. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=64297 -- Edit this bug report at https://bugs.php.net/bug.php?id=64297&edit=1
