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: Feedback +Status: Open Type: Bug Package: Reproducible crash Operating System: Linux PHP Version: 5.4.12 Block user comment: N Private report: N New Comment: ==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 Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2013-02-25 13:48:45] jille at hexon dot cx Description: ------------ PHP crashes with a segmentation fault when we allocate more memory than allowed. This happens in 5.4.9 as well as 5.4.12. (No other versions tested.) The only Different SAPI's yield different behaviours: * cli prints the OOM-error and sends it to syslog and segfaults immediately. * cli in gdb or valgrind doesn't print it but syslogs and segfaults the same. * apache2handler immediately sends the OOM-error to syslog but gives an error ("Cannot redeclare class Bummer") and segfaults afterwards on the next request to that child. The class Bummer is included from our auto_prepend_file and I'm sure it isn't accidentally included twice. Funny thing is sometimes the error is about a different class (sometimes not even one that was loaded by the auto_prepend_file but just with a require()) so my guess would be some kind of memory corruption. I can reproduce this reliably but failed to create a small reproduction script and unfortunately can't publish the source of our libraries. Actual result: -------------- The OOM-error: PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 32 bytes) in /path/to/libs/bpm.lib on line 3190 GDB: Program received signal SIGSEGV, Segmentation fault. _zend_mm_free_int (heap=0xfb0510, p=0x403aeda8) at /tmp/php-5.4.12/Zend/zend_alloc.c:2071 2071 size = ZEND_MM_BLOCK_SIZE(mm_block); (gdb) bt #0 _zend_mm_free_int (heap=0xfb0510, p=0x403aeda8) at /tmp/php-5.4.12/Zend/zend_alloc.c:2071 #1 0x00000000007a3992 in destroy_op_array (op_array=0x11f1640) at /tmp/php-5.4.12/Zend/zend_opcode.c:356 #2 0x00000000007bb288 in zend_hash_destroy (ht=0xfb0e20) at /tmp/php-5.4.12/Zend/zend_hash.c:560 #3 0x00000000007ad491 in zend_shutdown () at /tmp/php-5.4.12/Zend/zend.c:822 #4 0x000000000074ec4a in php_module_shutdown () at /tmp/php-5.4.12/main/main.c:2365 #5 0x0000000000433c07 in main (argc=5, argv=0x7fffffffe648) at /tmp/php-5.4.12/sapi/cli/php_cli.c:1379 $ valgrind ./sapi/cli/php /path/to/memcrash.php ==5742== Memcheck, a memory error detector ==5742== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==5742== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==5742== Command: ./sapi/cli/php /path/to/memcrash.php ==5742== ==5742== Conditional jump or move depends on uninitialised value(s) ==5742== at 0x4E3B4E0: inflateReset2 (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4) ==5742== by 0x4E3B5D8: inflateInit2_ (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4) ==5742== by 0x4E364F5: uncompress (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4) ==5742== by 0x71E239: mmc_unpack_value (memcache_pool.c:337) ==5742== by 0x723CF3: mmc_server_read_value (memcache_ascii_protocol.c:189) ==5742== by 0x720732: mmc_pool_select (memcache_pool.c:1584) ==5742== by 0x7211A7: mmc_pool_run (memcache_pool.c:1670) ==5742== by 0x719635: zif_memcache_get (memcache.c:1669) ==5742== by 0x853B58: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642) ==5742== by 0x80E00E: execute (zend_vm_execute.h:410) ==5742== by 0x7AEF56: zend_execute_scripts (zend.c:1315) ==5742== by 0x74EEE2: php_execute_script (main.c:2492) ==5742== ==5742== Invalid read of size 8 ==5742== at 0x78717D: _zend_mm_free_int (zend_alloc.c:2071) ==5742== by 0x7A3991: destroy_op_array (zend_opcode.c:356) ==5742== by 0x7BB287: zend_hash_destroy (zend_hash.c:560) ==5742== by 0x7AD490: zend_shutdown (zend.c:822) ==5742== by 0x74EC49: php_module_shutdown (main.c:2365) ==5742== by 0x433C06: main (php_cli.c:1379) ==5742== Address 0x500031c0 is not stack'd, malloc'd or (recently) free'd ==5742== ==5742== ==5742== Process terminating with default action of signal 11 (SIGSEGV) ==5742== Access not within mapped region at address 0x500031C0 ==5742== at 0x78717D: _zend_mm_free_int (zend_alloc.c:2071) ==5742== by 0x7A3991: destroy_op_array (zend_opcode.c:356) ==5742== by 0x7BB287: zend_hash_destroy (zend_hash.c:560) ==5742== by 0x7AD490: zend_shutdown (zend.c:822) ==5742== by 0x74EC49: php_module_shutdown (main.c:2365) ==5742== by 0x433C06: main (php_cli.c:1379) ==5742== If you believe this happened as a result of a stack ==5742== overflow in your program's main thread (unlikely but ==5742== possible), you can try to increase the size of the ==5742== main thread stack using the --main-stacksize= flag. ==5742== The main thread stack size used in this run was 8388608. ==5742== ==5742== HEAP SUMMARY: ==5742== in use at exit: 7,524,625 bytes in 20,150 blocks ==5742== total heap usage: 2,020,371 allocs, 2,000,221 frees, 1,589,606,462 bytes allocated ==5742== ==5742== LEAK SUMMARY: ==5742== definitely lost: 201,072 bytes in 3,591 blocks ==5742== indirectly lost: 3,960,481 bytes in 2,926 blocks ==5742== possibly lost: 82,068 bytes in 53 blocks ==5742== still reachable: 3,281,004 bytes in 13,580 blocks ==5742== suppressed: 0 bytes in 0 blocks ==5742== Rerun with --leak-check=full to see details of leaked memory ==5742== ==5742== For counts of detected and suppressed errors, rerun with: -v ==5742== Use --track-origins=yes to see where uninitialised values come from ==5742== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 2 from 2) Segmentation fault ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=64297&edit=1
