Re: [PHP-DEV] memory manager panic
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] memory manager panic
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=21 INTVL=50 LIMIT=50 # 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] memory manager panic
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): [EMAIL PROTECTED]:~/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 [EMAIL PROTECTED]:~/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)] 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 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 [EMAIL PROTECTED]:~/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: [EMAIL PROTECTED]:~/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 Startin
[PHP-DEV] memory manager panic
Hi, There's a problem with the memory manager (HEAD): [EMAIL PROTECTED]:~/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 [EMAIL PROTECTED]:~/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)] 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 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 [EMAIL PROTECTED]:~/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: [EMAIL PROTECTED]:~/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 Thre
Re: [PHP-DEV] Memory manager
It's not really Y's port. We just helped it along a bit. Doug Rabson is the person you are looking for. See http://www.rabson.org/ -Rasmus On Mon, 5 Jul 2004, George Schlossnagle wrote: > I think sterling's looking for an OS X port. How is y!'s (inf)famous > freebsd port of valgrind coming along? > > Rasmus Lerdorf wrote: > > >http://ozlabs.org/~paulus/valgrind-2.1.0-ppc.tar.bz2 > > > >On Mon, 5 Jul 2004, Sterling Hughes wrote: > > > > > > > >>yes!!! > >> > >>i currently don't have a 32 bit linux box available to me (i'm remote > >>in ca for all of august), however, if someone gives me shell on one, > >>i'll bang around on it with valgrind. > >> > >>-sterling > >> > >>On Mon, 5 Jul 2004 11:13:12 -0700 (Pacific Standard Time), Rasmus > >>Lerdorf <[EMAIL PROTECTED]> wrote: > >> > >> > >>>I'd like to see a few people who know their way around Valgrind give this > >>>thing a workout before any release. I am planning on doing that as well > >>>this week, but the more codepaths tested, the better. > >>> > >>>-Rasmus > >>> > >>>On Mon, 5 Jul 2004, Andi Gutmans wrote: > >>> > >>> > >>> > Hi, > > Although I'm pretty sure I fixed the problem of the memory manager (in > zend_alloc.c), I agree with Sterling that it's probably best to disable it > for 5.0.0. I don't think that my fix will get enough testing until then for > me to feel comfortable with including it. > As I'd like to roll 5.0.0 by the end of the week, can developers please > speak up if they have anything critical they are working on? > > Please also run latest head just to make sure that the malloc()/free() MM > still works :) > > Andi > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > > > >>>-- > >>>PHP Internals - PHP Runtime Development Mailing List > >>>To unsubscribe, visit: http://www.php.net/unsub.php > >>> > >>> > >>> > >>> > >>-- > >>PHP Internals - PHP Runtime Development Mailing List > >>To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > >> > > > > > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory manager
I think sterling's looking for an OS X port. How is y!'s (inf)famous freebsd port of valgrind coming along? Rasmus Lerdorf wrote: http://ozlabs.org/~paulus/valgrind-2.1.0-ppc.tar.bz2 On Mon, 5 Jul 2004, Sterling Hughes wrote: yes!!! i currently don't have a 32 bit linux box available to me (i'm remote in ca for all of august), however, if someone gives me shell on one, i'll bang around on it with valgrind. -sterling On Mon, 5 Jul 2004 11:13:12 -0700 (Pacific Standard Time), Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: I'd like to see a few people who know their way around Valgrind give this thing a workout before any release. I am planning on doing that as well this week, but the more codepaths tested, the better. -Rasmus On Mon, 5 Jul 2004, Andi Gutmans wrote: Hi, Although I'm pretty sure I fixed the problem of the memory manager (in zend_alloc.c), I agree with Sterling that it's probably best to disable it for 5.0.0. I don't think that my fix will get enough testing until then for me to feel comfortable with including it. As I'd like to roll 5.0.0 by the end of the week, can developers please speak up if they have anything critical they are working on? Please also run latest head just to make sure that the malloc()/free() MM still works :) Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory manager
Hi > Is this with ZEND_MM or without? Sorry about my ignorance, but I don't know ;) standard ./configure (with some extensions) on OS X ... chregu On 5.7.2004 19:48 Uhr, Andi Gutmans wrote: Andi At 07:17 PM 7/5/2004 +0200, Christian Stocker wrote: On 5.7.2004 19:08 Uhr, Andi Gutmans wrote: Hi, Although I'm pretty sure I fixed the problem of the memory manager (in zend_alloc.c), I agree with Sterling that it's probably best to disable it for 5.0.0. I don't think that my fix will get enough testing until then for me to feel comfortable with including it. As I'd like to roll 5.0.0 by the end of the week, can developers please speak up if they have anything critical they are working on? Please also run latest head just to make sure that the malloc()/free() MM still works :) did you see http://bugs.php.net/bug.php?id=29016 ? sorry for not having short code to reproduce it... chregu Andi -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory manager
Hello Rasmus, Monday, July 5, 2004, 8:13:12 PM, you wrote: > I'd like to see a few people who know their way around Valgrind give this > thing a workout before any release. I am planning on doing that as well > this week, but the more codepaths tested, the better. i thought my valgrind was bork but wow it works after reverting to an older snapshot of the virtual machine :-) in the output there are 13281 errors from 4 contexts regarding missreads near constants. I tried to solve this again and gain and again but maybe i am blind. Apart from that i see some problems with internal classes. Note that this is a ZTS build. I know that for a short time some time ago i did not experience this. Anybody see those with non ZTS too? regards marcus [EMAIL PROTECTED] /usr/src/php-cvs $ valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=30 sapi/cli/php -r 'echo "Hello\n" ==27248== Memcheck, a memory error detector for x86-linux. ==27248== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. ==27248== Using valgrind-2.1.1, a program supervision framework for x86-linux. ==27248== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==27248== For more details, rerun with: -v ==27248== ==27248== Invalid read of size 1 ==27248==at 0x3C01DF90: memcpy (mac_replace_strmem.c:283) ==27248==by 0x8365A46: _zend_hash_add_or_update (zend_hash.c:242) ==27248==by 0x836742E: zend_hash_copy (zend_hash.c:754) ==27248==by 0x835D3BB: compiler_globals_ctor (zend.c:442) ==27248==by 0x835DD41: zend_post_startup (zend.c:686) ==27248==by 0x8309F2C: php_module_startup (main.c:1467) ==27248==by 0x83958F5: main (php_cli.c:621) ==27248== Address 0x3C840F13 is 1 bytes before a block of size 10 alloc'd ==27248==at 0x3C01E378: malloc (vg_replace_malloc.c:105) ==27248==by 0x834008C: zend_strndup (zend_alloc.c:413) ==27248==by 0x834DEC8: zend_register_long_constant (zend_constants.c:170) ==27248==by 0x834DB44: zend_register_standard_constants (zend_constants.c:97) ==27248==by 0x835DBAF: zend_startup (zend.c:642) ==27248==by 0x83098FD: php_module_startup (main.c:1338) ==27248==by 0x83958F5: main (php_cli.c:621) ==27248== ==27248== Invalid read of size 1 ==27248==at 0x3C01DF99: memcpy (mac_replace_strmem.c:284) ==27248==by 0x8365A46: _zend_hash_add_or_update (zend_hash.c:242) ==27248==by 0x836742E: zend_hash_copy (zend_hash.c:754) ==27248==by 0x835D3BB: compiler_globals_ctor (zend.c:442) ==27248==by 0x835DD41: zend_post_startup (zend.c:686) ==27248==by 0x8309F2C: php_module_startup (main.c:1467) ==27248==by 0x83958F5: main (php_cli.c:621) ==27248== Address 0x3C840F12 is 2 bytes before a block of size 10 alloc'd ==27248==at 0x3C01E378: malloc (vg_replace_malloc.c:105) ==27248==by 0x834008C: zend_strndup (zend_alloc.c:413) ==27248==by 0x834DEC8: zend_register_long_constant (zend_constants.c:170) ==27248==by 0x834DB44: zend_register_standard_constants (zend_constants.c:97) ==27248==by 0x835DBAF: zend_startup (zend.c:642) ==27248==by 0x83098FD: php_module_startup (main.c:1338) ==27248==by 0x83958F5: main (php_cli.c:621) ==27248== ==27248== Invalid read of size 1 ==27248==at 0x3C01DF9F: memcpy (mac_replace_strmem.c:285) ==27248==by 0x8365A46: _zend_hash_add_or_update (zend_hash.c:242) ==27248==by 0x836742E: zend_hash_copy (zend_hash.c:754) ==27248==by 0x835D3BB: compiler_globals_ctor (zend.c:442) ==27248==by 0x835DD41: zend_post_startup (zend.c:686) ==27248==by 0x8309F2C: php_module_startup (main.c:1467) ==27248==by 0x83958F5: main (php_cli.c:621) ==27248== Address 0x3C840F11 is 3 bytes before a block of size 10 alloc'd ==27248==at 0x3C01E378: malloc (vg_replace_malloc.c:105) ==27248==by 0x834008C: zend_strndup (zend_alloc.c:413) ==27248==by 0x834DEC8: zend_register_long_constant (zend_constants.c:170) ==27248==by 0x834DB44: zend_register_standard_constants (zend_constants.c:97) ==27248==by 0x835DBAF: zend_startup (zend.c:642) ==27248==by 0x83098FD: php_module_startup (main.c:1338) ==27248==by 0x83958F5: main (php_cli.c:621) ==27248== ==27248== Invalid read of size 1 ==27248==at 0x3C01DFA5: memcpy (mac_replace_strmem.c:286) ==27248==by 0x8365A46: _zend_hash_add_or_update (zend_hash.c:242) ==27248==by 0x836742E: zend_hash_copy (zend_hash.c:754) ==27248==by 0x835D3BB: compiler_globals_ctor (zend.c:442) ==27248==by 0x835DD41: zend_post_startup (zend.c:686) ==27248==by 0x8309F2C: php_module_startup (main.c:1467) ==27248==by 0x83958F5: main (php_cli.c:621) ==27248== Address 0x3C840F10 is 4 bytes before a block of size 10 alloc'd ==27248==at 0x3C01E378: malloc (vg_replace_malloc.c:105) ==27248==by 0x834008C: zend_strndup (zend_alloc.c:413) ==27248==by 0x834DEC8: zend_register_long_constant (zend_constants.c:170) ==27248==by 0x834DB44: zend_register_standard_constants (zend_constants.c:97) ==27248==by 0x835D
Re: [PHP-DEV] Memory manager
http://ozlabs.org/~paulus/valgrind-2.1.0-ppc.tar.bz2 On Mon, 5 Jul 2004, Sterling Hughes wrote: > yes!!! > > i currently don't have a 32 bit linux box available to me (i'm remote > in ca for all of august), however, if someone gives me shell on one, > i'll bang around on it with valgrind. > > -sterling > > On Mon, 5 Jul 2004 11:13:12 -0700 (Pacific Standard Time), Rasmus > Lerdorf <[EMAIL PROTECTED]> wrote: > > > > > > I'd like to see a few people who know their way around Valgrind give this > > thing a workout before any release. I am planning on doing that as well > > this week, but the more codepaths tested, the better. > > > > -Rasmus > > > > On Mon, 5 Jul 2004, Andi Gutmans wrote: > > > > > Hi, > > > > > > Although I'm pretty sure I fixed the problem of the memory manager (in > > > zend_alloc.c), I agree with Sterling that it's probably best to disable it > > > for 5.0.0. I don't think that my fix will get enough testing until then for > > > me to feel comfortable with including it. > > > As I'd like to roll 5.0.0 by the end of the week, can developers please > > > speak up if they have anything critical they are working on? > > > > > > Please also run latest head just to make sure that the malloc()/free() MM > > > still works :) > > > > > > Andi > > > > > > -- > > > PHP Internals - PHP Runtime Development Mailing List > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory manager
yes!!! i currently don't have a 32 bit linux box available to me (i'm remote in ca for all of august), however, if someone gives me shell on one, i'll bang around on it with valgrind. -sterling On Mon, 5 Jul 2004 11:13:12 -0700 (Pacific Standard Time), Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: > > > I'd like to see a few people who know their way around Valgrind give this > thing a workout before any release. I am planning on doing that as well > this week, but the more codepaths tested, the better. > > -Rasmus > > On Mon, 5 Jul 2004, Andi Gutmans wrote: > > > Hi, > > > > Although I'm pretty sure I fixed the problem of the memory manager (in > > zend_alloc.c), I agree with Sterling that it's probably best to disable it > > for 5.0.0. I don't think that my fix will get enough testing until then for > > me to feel comfortable with including it. > > As I'd like to roll 5.0.0 by the end of the week, can developers please > > speak up if they have anything critical they are working on? > > > > Please also run latest head just to make sure that the malloc()/free() MM > > still works :) > > > > Andi > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory manager
Yep, definitely. At 11:13 AM 7/5/2004 -0700, Rasmus Lerdorf wrote: I'd like to see a few people who know their way around Valgrind give this thing a workout before any release. I am planning on doing that as well this week, but the more codepaths tested, the better. -Rasmus On Mon, 5 Jul 2004, Andi Gutmans wrote: > Hi, > > Although I'm pretty sure I fixed the problem of the memory manager (in > zend_alloc.c), I agree with Sterling that it's probably best to disable it > for 5.0.0. I don't think that my fix will get enough testing until then for > me to feel comfortable with including it. > As I'd like to roll 5.0.0 by the end of the week, can developers please > speak up if they have anything critical they are working on? > > Please also run latest head just to make sure that the malloc()/free() MM > still works :) > > Andi > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory manager
I'd like to see a few people who know their way around Valgrind give this thing a workout before any release. I am planning on doing that as well this week, but the more codepaths tested, the better. -Rasmus On Mon, 5 Jul 2004, Andi Gutmans wrote: > Hi, > > Although I'm pretty sure I fixed the problem of the memory manager (in > zend_alloc.c), I agree with Sterling that it's probably best to disable it > for 5.0.0. I don't think that my fix will get enough testing until then for > me to feel comfortable with including it. > As I'd like to roll 5.0.0 by the end of the week, can developers please > speak up if they have anything critical they are working on? > > Please also run latest head just to make sure that the malloc()/free() MM > still works :) > > Andi > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory manager
Is this with ZEND_MM or without? Andi At 07:17 PM 7/5/2004 +0200, Christian Stocker wrote: On 5.7.2004 19:08 Uhr, Andi Gutmans wrote: Hi, Although I'm pretty sure I fixed the problem of the memory manager (in zend_alloc.c), I agree with Sterling that it's probably best to disable it for 5.0.0. I don't think that my fix will get enough testing until then for me to feel comfortable with including it. As I'd like to roll 5.0.0 by the end of the week, can developers please speak up if they have anything critical they are working on? Please also run latest head just to make sure that the malloc()/free() MM still works :) did you see http://bugs.php.net/bug.php?id=29016 ? sorry for not having short code to reproduce it... chregu Andi -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory manager
On 5.7.2004 19:08 Uhr, Andi Gutmans wrote: Hi, Although I'm pretty sure I fixed the problem of the memory manager (in zend_alloc.c), I agree with Sterling that it's probably best to disable it for 5.0.0. I don't think that my fix will get enough testing until then for me to feel comfortable with including it. As I'd like to roll 5.0.0 by the end of the week, can developers please speak up if they have anything critical they are working on? Please also run latest head just to make sure that the malloc()/free() MM still works :) did you see http://bugs.php.net/bug.php?id=29016 ? sorry for not having short code to reproduce it... chregu Andi -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Memory manager
Hi, Although I'm pretty sure I fixed the problem of the memory manager (in zend_alloc.c), I agree with Sterling that it's probably best to disable it for 5.0.0. I don't think that my fix will get enough testing until then for me to feel comfortable with including it. As I'd like to roll 5.0.0 by the end of the week, can developers please speak up if they have anything critical they are working on? Please also run latest head just to make sure that the malloc()/free() MM still works :) Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
