Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » memory manager panic »

memory manager panic

php.internals

Michael Wallner

19 years ago
Hi, There's a problem with the memory manager (HEAD): mike@honeybadger:~/build/php-unicode-debug$ cli -d"memory_limit=500k" -r 'leak(212930);' [Sat Nov 11 21:39:42 2006] Script: '-' /home/mike/cvs/php-src/Zend/zend_builtin_functions.c(1181) : Freeing 0xB6E73000 (212930 bytes), script=- zend_mm_heap corrupted Segmentation fault mike@honeybadger:~/build/php-unicode-debug$ gdb --args sapi/cli/php -d"memory_limit=500k" -r 'leak(212800);' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) r Starting program: /home/mike/build/php-unicode-debug/sapi/cli/php -dmemory_limit=500k -r leak\(212800\)\; [Thread debugging using libthread_db enabled] [New Thread -1225652560 (LWP 9328)] [Sat Nov 11 21:40:04 2006] Script: '-' /home/mike/cvs/php-src/Zend/zend_builtin_functions.c(1181) : Freeing 0xB6EEB0A0 (212800 bytes), script=- zend_mm_heap corrupted Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1225652560 (LWP 9328)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7035ba6 in kill () from /lib/tls/i686/cmov/libc.so.6 #2 0x08298639 in zend_mm_panic (message=0x83e9a2b "zend_mm_heap corrupted") at /home/mike/cvs/php-src/Zend/zend_alloc.c:61 #3 0x08298f14 in zend_mm_find_leaks (segment=0xb6edf008, b=0xb6eeb07c) at /home/mike/cvs/php-src/Zend/zend_alloc.c:673 #4 0x082990dd in zend_mm_check_leaks (heap=0x841b4b0) at /home/mike/cvs/php-src/Zend/zend_alloc.c:735 #5 0x08299b2a in zend_mm_shutdown (heap=0x841b4b0, full_shutdown=0, silent=0) at /home/mike/cvs/php-src/Zend/zend_alloc.c:997 #6 0x0829b940 in shutdown_memory_manager (silent=0, full_shutdown=0, tsrm_ls=0x841a018) at /home/mike/cvs/php-src/Zend/zend_alloc.c:1875 #7 0x0824a439 in php_request_shutdown (dummy=0x0) at /home/mike/cvs/php-src/main/main.c:1435 #8 0x08360230 in main (argc=4, argv=0xbfd39c94) at /home/mike/cvs/php-src/sapi/cli/php_cli.c:1270 mike@honeybadger:~/build/php-unicode-debug$ valgrind sapi/cli/php -d"memory_limit=500k" -r 'leak(211800);' ==9345== Memcheck, a memory error detector. ==9345== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==9345== Using LibVEX rev 1606, a library for dynamic binary translation. ==9345== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==9345== Using valgrind-3.2.0-Debian, a dynamic binary instrumentation framework. ==9345== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==9345== For more details, rerun with: -v ==9345== [Sat Nov 11 21:44:38 2006] Script: '-' /home/mike/cvs/php-src/Zend/zend_builtin_functions.c(1181) : Freeing 0x052AF490 (211800 bytes), script=- ==9345== Invalid read of size 4 ==9345== at 0x8298F01: zend_mm_find_leaks (zend_alloc.c:670) ==9345== by 0x82990DC: zend_mm_check_leaks (zend_alloc.c:735) ==9345== by 0x8299B29: zend_mm_shutdown (zend_alloc.c:997) ==9345== by 0x829B93F: shutdown_memory_manager (zend_alloc.c:1875) ==9345== by 0x824A438: php_request_shutdown (main.c:1435) ==9345== by 0x836022F: main (php_cli.c:1270) ==9345== Address 0x52E302C is 4 bytes after a block of size 262,144 alloc'd ==9345== at 0x4021396: malloc (vg_replace_malloc.c:149) ==9345== by 0x8298843: zend_mm_mem_malloc_alloc (zend_alloc.c:230) ==9345== by 0x829A243: _zend_mm_alloc_int (zend_alloc.c:1208) ==9345== by 0x829B194: _emalloc (zend_alloc.c:1646) ==9345== by 0x8263991: php_output_activate (output.c:116) ==9345== by 0x8249481: php_request_startup (main.c:1195) ==9345== by 0x835F714: main (php_cli.c:1015) zend_mm_heap corrupted ==9345== ==9345== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 47 from 1) ==9345== malloc/free: in use at exit: 1,104,886 bytes in 14,284 blocks. ==9345== malloc/free: 15,049 allocs, 765 frees, 1,463,471 bytes allocated. ==9345== For counts of detected errors, rerun with: -v ==9345== searching for pointers to 14,284 not-freed blocks. ==9345== checked 1,236,528 bytes. ==9345== ==9345== LEAK SUMMARY: ==9345== definitely lost: 0 bytes in 0 blocks. ==9345== possibly lost: 0 bytes in 0 blocks. ==9345== still reachable: 1,104,886 bytes in 14,284 blocks. ==9345== suppressed: 0 bytes in 0 blocks. ==9345== Reachable blocks (those to which a pointer was found) are not shown. ==9345== To see them, rerun with: --show-reachable=yes Segmentation fault Bytes to leak may differ as you can see. The problem doesn't seem to be tied to leaks though, because I can replicate with code that doesn't leak and that generates a different backtrace: mike@honeybadger:~/build/php-unicode-debug$ gdb --quiet sapi/cli/php Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) r -d"memory_limit=500k" -d"output_buffering=1" -r 'while(true) echo "foo";' > /dev/null Starting program: /home/mike/build/php-unicode-debug/sapi/cli/php -d"memory_limit=500k" -d"output_buffering=1" -r 'while(true) echo "foo";' > /dev/null [Thread debugging using libthread_db enabled] [New Thread -1225435472 (LWP 9350)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1225435472 (LWP 9350)] 0x0829a048 in _zend_mm_alloc_int (heap=0x841b4c8, size=10, __zend_filename=0x83d057c "/home/mike/cvs/php-src/main/SAPI.c", __zend_lineno=267, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /home/mike/cvs/php-src/Zend/zend_alloc.c:1139 1139 size_t s = ZEND_MM_FREE_BLOCK_SIZE(p); (gdb) bt #0 0x0829a048 in _zend_mm_alloc_int (heap=0x841b4c8, size=10, __zend_filename=0x83d057c "/home/mike/cvs/php-src/main/SAPI.c", __zend_lineno=267, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /home/mike/cvs/php-src/Zend/zend_alloc.c:1139 #1 0x0829b195 in _emalloc (size=10, __zend_filename=0x83d057c "/home/mike/cvs/php-src/main/SAPI.c", __zend_lineno=267, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /home/mike/cvs/php-src/Zend/zend_alloc.c:1646 #2 0x0829b5ed in _estrdup (s=0x83cf29b "text/html", __zend_filename=0x83d057c "/home/mike/cvs/php-src/main/SAPI.c", __zend_lineno=267, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /home/mike/cvs/php-src/Zend/zend_alloc.c:1754 #3 0x082545e9 in sapi_get_default_content_type (tsrm_ls=0x841a018) at /home/mike/cvs/php-src/main/SAPI.c:267 #4 0x08254608 in sapi_get_default_content_type_header (default_header=0xbffdc898, tsrm_ls=0x841a018) at /home/mike/cvs/php-src/main/SAPI.c:275 #5 0x082560e2 in sapi_send_headers (tsrm_ls=0x841a018) at /home/mike/cvs/php-src/main/SAPI.c:727 #6 0x081b17f1 in php_header (tsrm_ls=0x841a018) at /home/mike/cvs/php-src/ext/standard/head.c:54 #7 0x08266638 in php_output_op (op=0, str=0xb6f241fc "foo"..., len=180390, tsrm_ls=0x841a018) at /home/mike/cvs/php-src/main/output.c:1073 #8 0x08264605 in php_output_write ( str=0xb6f241fc "foo"..., len=180390, tsrm_ls=0x841a018) at /home/mike/cvs/php-src/main/output.c:278 #9 0x08266ff5 in php_output_stack_pop (flags=1, tsrm_ls=0x841a018) at /home/mike/cvs/php-src/main/output.c:1250 #10 0x08264937 in php_output_end_all (tsrm_ls=0x841a018) at /home/mike/cvs/php-src/main/output.c:358 #11 0x0824a042 in php_request_shutdown (dummy=0x0) at /home/mike/cvs/php-src/main/main.c:1388 #12 0x08360230 in main (argc=5, argv=0xbffdcf14) at /home/mike/cvs/php-src/sapi/cli/php_cli.c:1270 Regards,
-- Michael

Antony Dovgal

19 years ago
Mike, please make sure you didn't forget to do `cvs up Zend` and `./cvsclean` to get a clean build. I can't reproduce it with your test case, though. On 11/11/2006 11:57 PM, Michael Wallner wrote:
> Hi, > > There's a problem with the memory manager (HEAD): > > mike@honeybadger:~/build/php-unicode-debug$ cli -d"memory_limit=500k" -r 'leak(212930);' > [Sat Nov 11 21:39:42 2006] Script: '-' > /home/mike/cvs/php-src/Zend/zend_builtin_functions.c(1181) : Freeing 0xB6E73000 (212930 bytes), script=- > zend_mm_heap corrupted > Segmentation fault > > mike@honeybadger:~/build/php-unicode-debug$ gdb --args sapi/cli/php -d"memory_limit=500k" -r 'leak(212800);' > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > (gdb) r > Starting program: /home/mike/build/php-unicode-debug/sapi/cli/php -dmemory_limit=500k -r leak\(212800\)\; > [Thread debugging using libthread_db enabled] > [New Thread -1225652560 (LWP 9328)] > [Sat Nov 11 21:40:04 2006] Script: '-' > /home/mike/cvs/php-src/Zend/zend_builtin_functions.c(1181) : Freeing 0xB6EEB0A0 (212800 bytes), script=- > zend_mm_heap corrupted > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1225652560 (LWP 9328)] > 0xffffe410 in __kernel_vsyscall () > (gdb) bt > #0 0xffffe410 in __kernel_vsyscall () > #1 0xb7035ba6 in kill () from /lib/tls/i686/cmov/libc.so.6 > #2 0x08298639 in zend_mm_panic (message=0x83e9a2b "zend_mm_heap corrupted") at /home/mike/cvs/php-src/Zend/zend_alloc.c:61 > #3 0x08298f14 in zend_mm_find_leaks (segment=0xb6edf008, b=0xb6eeb07c) at /home/mike/cvs/php-src/Zend/zend_alloc.c:673 > #4 0x082990dd in zend_mm_check_leaks (heap=0x841b4b0) at /home/mike/cvs/php-src/Zend/zend_alloc.c:735 > #5 0x08299b2a in zend_mm_shutdown (heap=0x841b4b0, full_shutdown=0, silent=0) at /home/mike/cvs/php-src/Zend/zend_alloc.c:997 > #6 0x0829b940 in shutdown_memory_manager (silent=0, full_shutdown=0, tsrm_ls=0x841a018) at /home/mike/cvs/php-src/Zend/zend_alloc.c:1875 > #7 0x0824a439 in php_request_shutdown (dummy=0x0) at /home/mike/cvs/php-src/main/main.c:1435 > #8 0x08360230 in main (argc=4, argv=0xbfd39c94) at /home/mike/cvs/php-src/sapi/cli/php_cli.c:1270 > > mike@honeybadger:~/build/php-unicode-debug$ valgrind sapi/cli/php -d"memory_limit=500k" -r 'leak(211800);' > ==9345== Memcheck, a memory error detector. > ==9345== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. > ==9345== Using LibVEX rev 1606, a library for dynamic binary translation. > ==9345== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. > ==9345== Using valgrind-3.2.0-Debian, a dynamic binary instrumentation framework. > ==9345== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. > ==9345== For more details, rerun with: -v > ==9345== > [Sat Nov 11 21:44:38 2006] Script: '-' > /home/mike/cvs/php-src/Zend/zend_builtin_functions.c(1181) : Freeing 0x052AF490 (211800 bytes), script=- > ==9345== Invalid read of size 4 > ==9345== at 0x8298F01: zend_mm_find_leaks (zend_alloc.c:670) > ==9345== by 0x82990DC: zend_mm_check_leaks (zend_alloc.c:735) > ==9345== by 0x8299B29: zend_mm_shutdown (zend_alloc.c:997) > ==9345== by 0x829B93F: shutdown_memory_manager (zend_alloc.c:1875) > ==9345== by 0x824A438: php_request_shutdown (main.c:1435) > ==9345== by 0x836022F: main (php_cli.c:1270) > ==9345== Address 0x52E302C is 4 bytes after a block of size 262,144 alloc'd > ==9345== at 0x4021396: malloc (vg_replace_malloc.c:149) > ==9345== by 0x8298843: zend_mm_mem_malloc_alloc (zend_alloc.c:230) > ==9345== by 0x829A243: _zend_mm_alloc_int (zend_alloc.c:1208) > ==9345== by 0x829B194: _emalloc (zend_alloc.c:1646) > ==9345== by 0x8263991: php_output_activate (output.c:116) > ==9345== by 0x8249481: php_request_startup (main.c:1195) > ==9345== by 0x835F714: main (php_cli.c:1015) > zend_mm_heap corrupted > ==9345== > ==9345== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 47 from 1) > ==9345== malloc/free: in use at exit: 1,104,886 bytes in 14,284 blocks. > ==9345== malloc/free: 15,049 allocs, 765 frees, 1,463,471 bytes allocated. > ==9345== For counts of detected errors, rerun with: -v > ==9345== searching for pointers to 14,284 not-freed blocks. > ==9345== checked 1,236,528 bytes. > ==9345== > ==9345== LEAK SUMMARY: > ==9345== definitely lost: 0 bytes in 0 blocks. > ==9345== possibly lost: 0 bytes in 0 blocks. > ==9345== still reachable: 1,104,886 bytes in 14,284 blocks. > ==9345== suppressed: 0 bytes in 0 blocks. > ==9345== Reachable blocks (those to which a pointer was found) are not shown. > ==9345== To see them, rerun with: --show-reachable=yes > Segmentation fault > > > Bytes to leak may differ as you can see. The problem doesn't seem to be tied > to leaks though, because I can replicate with code that doesn't leak and that > generates a different backtrace: > > mike@honeybadger:~/build/php-unicode-debug$ gdb --quiet sapi/cli/php > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > (gdb) r -d"memory_limit=500k" -d"output_buffering=1" -r 'while(true) echo "foo";' > /dev/null > Starting program: /home/mike/build/php-unicode-debug/sapi/cli/php -d"memory_limit=500k" -d"output_buffering=1" -r 'while(true) echo "foo";' > /dev/null > [Thread debugging using libthread_db enabled] > [New Thread -1225435472 (LWP 9350)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1225435472 (LWP 9350)] > 0x0829a048 in _zend_mm_alloc_int (heap=0x841b4c8, size=10, __zend_filename=0x83d057c "/home/mike/cvs/php-src/main/SAPI.c", __zend_lineno=267, __zend_orig_filename=0x0, __zend_orig_lineno=0) > at /home/mike/cvs/php-src/Zend/zend_alloc.c:1139 > 1139 size_t s = ZEND_MM_FREE_BLOCK_SIZE(p); > (gdb) bt > #0 0x0829a048 in _zend_mm_alloc_int (heap=0x841b4c8, size=10, __zend_filename=0x83d057c "/home/mike/cvs/php-src/main/SAPI.c", __zend_lineno=267, __zend_orig_filename=0x0, __zend_orig_lineno=0) > at /home/mike/cvs/php-src/Zend/zend_alloc.c:1139 > #1 0x0829b195 in _emalloc (size=10, __zend_filename=0x83d057c "/home/mike/cvs/php-src/main/SAPI.c", __zend_lineno=267, __zend_orig_filename=0x0, __zend_orig_lineno=0) > at /home/mike/cvs/php-src/Zend/zend_alloc.c:1646 > #2 0x0829b5ed in _estrdup (s=0x83cf29b "text/html", __zend_filename=0x83d057c "/home/mike/cvs/php-src/main/SAPI.c", __zend_lineno=267, __zend_orig_filename=0x0, __zend_orig_lineno=0) > at /home/mike/cvs/php-src/Zend/zend_alloc.c:1754 > #3 0x082545e9 in sapi_get_default_content_type (tsrm_ls=0x841a018) at /home/mike/cvs/php-src/main/SAPI.c:267 > #4 0x08254608 in sapi_get_default_content_type_header (default_header=0xbffdc898, tsrm_ls=0x841a018) at /home/mike/cvs/php-src/main/SAPI.c:275 > #5 0x082560e2 in sapi_send_headers (tsrm_ls=0x841a018) at /home/mike/cvs/php-src/main/SAPI.c:727 > #6 0x081b17f1 in php_header (tsrm_ls=0x841a018) at /home/mike/cvs/php-src/ext/standard/head.c:54 > #7 0x08266638 in php_output_op (op=0, > str=0xb6f241fc "foo"..., len=180390, tsrm_ls=0x841a018) at /home/mike/cvs/php-src/main/output.c:1073 > #8 0x08264605 in php_output_write ( > str=0xb6f241fc "foo"..., len=180390, tsrm_ls=0x841a018) at /home/mike/cvs/php-src/main/output.c:278 > #9 0x08266ff5 in php_output_stack_pop (flags=1, tsrm_ls=0x841a018) at /home/mike/cvs/php-src/main/output.c:1250 > #10 0x08264937 in php_output_end_all (tsrm_ls=0x841a018) at /home/mike/cvs/php-src/main/output.c:358 > #11 0x0824a042 in php_request_shutdown (dummy=0x0) at /home/mike/cvs/php-src/main/main.c:1388 > #12 0x08360230 in main (argc=5, argv=0xbffdcf14) at /home/mike/cvs/php-src/sapi/cli/php_cli.c:1270 > > > Regards,
-- Wbr, Antony Dovgal

Michael Wallner

19 years ago
Hi Tony,
> > Mike, please make sure you didn't forget to do `cvs up Zend` and > `./cvsclean` to get a clean build. > I can't reproduce it with your test case, though.
It is generated from a clean build. I'd appreciate if you could try to replicate it with the following shell script: --- #!/bin/bash # adjust these values BYTES=210000 INTVL=50 LIMIT=500000 # RTVAL=0 START=$BYTES while test $RTVAL == "0" do sapi/cli/php -dmemory_limit=$LIMIT -r"leak($BYTES);" >/dev/null 2>&1; RTVAL=$?; if test $RTVAL == "255"; then if test $START == $BYTES; then echo "Initial BYTES ($START) too big"; else echo "Intervall ($INTVL) too big"; fi; exit; fi; BYTES=`expr $BYTES + $INTVL`; if test $BYTES == $LIMIT; then echo "Huh? Reached LIMIT ($LIMIT)"; exit; fi; done; echo "SEGV at $BYTES bytes alloc"; ---
-- Michael

Michael Wallner

19 years ago
Michael Wallner wrote:
> Hi Tony, >> Mike, please make sure you didn't forget to do `cvs up Zend` and >> `./cvsclean` to get a clean build. >> I can't reproduce it with your test case, though. > > It is generated from a clean build. > I'd appreciate if you could try to replicate it with the following shell script: >
Just a note, that I can alos replicate with PHP-5.2. Regards,
-- Michael

Dmitry Stogov

19 years ago
Hi Michel, Thank you for catching this. I fixed the first problem, and will care about the second one later. It is related to memory overflow and probably cannot be fixed in memory manager itself. Dmitry.