#19482 [Com]: segfault on child process
ID: 19482 Comment by: sales at isptek dot com Reported By: amith at xalan dot com Status: Closed Bug Type: PCRE related Operating System: Redhat 7.3 PHP Version: 4.2.3,4.3.0-dev New Comment: yes same problem here 8 identical machines but two seg fault just about every day on login to imp Previous Comments: [2003-07-19 22:15:50] gonzalo at linuxaus dot com Hi, I know it's been almost a year since closing bug #19482 but I'm having a very similar issue, only that it's difficult to reproduce. Sometimes, mainly when someone is using IMP, child processes tend to segfault quite a bit. As I said, I can't reproduce it easily so it's hard to know whether whatever I try fixes it or not.. it's just a matter of time :) I'm running Apache 1.3.27, PHP 4.3.1, Horde 2.2.3, IMP 3.2.1 Have you had any similar reports recently? [2002-10-07 12:25:02] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-10-07 11:44:06] amith at xalan dot com I applied the patch to php4-200209191800 (the newest snapshot died with some other unrelated problem) and ran my normal tests. Looked like this fixed it! I went through 174 emails with IE and had no segfaults. Thanks for everyone's help in solving this problem and continue with the good work. [2002-10-07 11:16:59] [EMAIL PROTECTED] Please try this patch and report back: RCS file: /repository/php4/ext/pcre/php_pcre.c,v retrieving revision 1.128 diff -u -2 -b -w -B -r1.128 php_pcre.c --- ext/pcre/php_pcre.c 11 Sep 2002 14:41:25 - 1.128 +++ ext/pcre/php_pcre.c 7 Oct 2002 16:05:59 - @@ -67,4 +67,5 @@ #if HAVE_SETLOCALE if ((void*)pce-tables) pefree((void*)pce-tables, 1); + pefree(pce-locale, 1); #endif } @@ -303,5 +304,5 @@ new_entry.preg_options = poptions; #if HAVE_SETLOCALE - new_entry.locale = locale; + new_entry.locale = pestrdup(locale, 1); new_entry.tables = tables; #endif [2002-10-06 22:41:36] amith at xalan dot com I tried with the newest snapshot but I get the following backtrace (gdb) run -X -DSSL -f /usr/local/apache/conf/httpd.conf Starting program: /usr/local/apache/bin/httpd -X -DSSL -f /usr/local/apache/conf/httpd.conf Program received signal SIGSEGV, Segmentation fault. 0x403d2e94 in _efree (ptr=0x0) at /usr/local/software/php4-200210061800/Zend/zend_alloc.c:211 211 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p-size); (gdb) bt #0 0x403d2e94 in _efree (ptr=0x0) at /usr/local/software/php4-200210061800/Zend/zend_alloc.c:211 #1 0x403e5b8e in zend_hash_destroy (ht=0x82ea824) at /usr/local/software/php4-200210061800/Zend/zend_hash.c:550 #2 0x403e063a in _zval_dtor (zvalue=0x81802ec) at /usr/local/software/php4-200210061800/Zend/zend_variables.c:51 #3 0x403f1206 in execute (op_array=0x82d130c) at /usr/local/software/php4-200210061800/Zend/zend_execute.c:449 #4 0x403f411a in execute (op_array=0x82182e4) at /usr/local/software/php4-200210061800/Zend/zend_execute.c:1641 #5 0x403e1adc in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/software/php4-200210061800/Zend/zend.c:834 #6 0x403bbfed in php_execute_script (primary_file=0xb6d0) at /usr/local/software/php4-200210061800/main/main.c:1542 #7 0x403fb4b6 in apache_php_module_main (r=0x816c9e0, display_source_mode=0) at /usr/local/software/php4-200210061800/sapi/apache/sapi_apache.c:55 #8 0x403fbfd6 in send_php (r=0x816c9e0, display_source_mode=0, filename=0x0) at /usr/local/software/php4-200210061800/sapi/apache/mod_php4.c:564 #9 0x403fc02a in send_parsed_php (r=0x816c9e0) at /usr/local/software/php4-200210061800/sapi/apache/mod_php4.c:579 #10 0x0806bdcf in ap_invoke_handler () #11 0x08080e53 in process_request_internal () #12 0x08080eb4 in ap_process_request () ---Type return to continue, or q return to quit--- #13 0x08077df1 in child_main () #14 0x08077fc0 in make_child () #15 0x08078134 in startup_children () #16 0x080787ac in standalone_main () #17 0x0807902b in main () #18 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
#19482 [Com]: segfault on child process
ID: 19482 Comment by: gonzalo at linuxaus dot com Reported By: amith at xalan dot com Status: Closed Bug Type: PCRE related Operating System: Redhat 7.3 PHP Version: 4.2.3,4.3.0-dev New Comment: Hi, I know it's been almost a year since closing bug #19482 but I'm having a very similar issue, only that it's difficult to reproduce. Sometimes, mainly when someone is using IMP, child processes tend to segfault quite a bit. As I said, I can't reproduce it easily so it's hard to know whether whatever I try fixes it or not.. it's just a matter of time :) I'm running Apache 1.3.27, PHP 4.3.1, Horde 2.2.3, IMP 3.2.1 Have you had any similar reports recently? Previous Comments: [2002-10-07 12:25:02] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-10-07 11:44:06] amith at xalan dot com I applied the patch to php4-200209191800 (the newest snapshot died with some other unrelated problem) and ran my normal tests. Looked like this fixed it! I went through 174 emails with IE and had no segfaults. Thanks for everyone's help in solving this problem and continue with the good work. [2002-10-07 11:16:59] [EMAIL PROTECTED] Please try this patch and report back: RCS file: /repository/php4/ext/pcre/php_pcre.c,v retrieving revision 1.128 diff -u -2 -b -w -B -r1.128 php_pcre.c --- ext/pcre/php_pcre.c 11 Sep 2002 14:41:25 - 1.128 +++ ext/pcre/php_pcre.c 7 Oct 2002 16:05:59 - @@ -67,4 +67,5 @@ #if HAVE_SETLOCALE if ((void*)pce-tables) pefree((void*)pce-tables, 1); + pefree(pce-locale, 1); #endif } @@ -303,5 +304,5 @@ new_entry.preg_options = poptions; #if HAVE_SETLOCALE - new_entry.locale = locale; + new_entry.locale = pestrdup(locale, 1); new_entry.tables = tables; #endif [2002-10-06 22:41:36] amith at xalan dot com I tried with the newest snapshot but I get the following backtrace (gdb) run -X -DSSL -f /usr/local/apache/conf/httpd.conf Starting program: /usr/local/apache/bin/httpd -X -DSSL -f /usr/local/apache/conf/httpd.conf Program received signal SIGSEGV, Segmentation fault. 0x403d2e94 in _efree (ptr=0x0) at /usr/local/software/php4-200210061800/Zend/zend_alloc.c:211 211 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p-size); (gdb) bt #0 0x403d2e94 in _efree (ptr=0x0) at /usr/local/software/php4-200210061800/Zend/zend_alloc.c:211 #1 0x403e5b8e in zend_hash_destroy (ht=0x82ea824) at /usr/local/software/php4-200210061800/Zend/zend_hash.c:550 #2 0x403e063a in _zval_dtor (zvalue=0x81802ec) at /usr/local/software/php4-200210061800/Zend/zend_variables.c:51 #3 0x403f1206 in execute (op_array=0x82d130c) at /usr/local/software/php4-200210061800/Zend/zend_execute.c:449 #4 0x403f411a in execute (op_array=0x82182e4) at /usr/local/software/php4-200210061800/Zend/zend_execute.c:1641 #5 0x403e1adc in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/software/php4-200210061800/Zend/zend.c:834 #6 0x403bbfed in php_execute_script (primary_file=0xb6d0) at /usr/local/software/php4-200210061800/main/main.c:1542 #7 0x403fb4b6 in apache_php_module_main (r=0x816c9e0, display_source_mode=0) at /usr/local/software/php4-200210061800/sapi/apache/sapi_apache.c:55 #8 0x403fbfd6 in send_php (r=0x816c9e0, display_source_mode=0, filename=0x0) at /usr/local/software/php4-200210061800/sapi/apache/mod_php4.c:564 #9 0x403fc02a in send_parsed_php (r=0x816c9e0) at /usr/local/software/php4-200210061800/sapi/apache/mod_php4.c:579 #10 0x0806bdcf in ap_invoke_handler () #11 0x08080e53 in process_request_internal () #12 0x08080eb4 in ap_process_request () ---Type return to continue, or q return to quit--- #13 0x08077df1 in child_main () #14 0x08077fc0 in make_child () #15 0x08078134 in startup_children () #16 0x080787ac in standalone_main () #17 0x0807902b in main () #18 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6 [2002-10-06 19:08:49] speedfreak50 at netscape dot net Note sure if this will be useful, but if i edit main/php_config.h (after running ./configure) and remove all LOCALE defines, here's a backtrace of the segfault:
#19482 [Com]: segfault on child process
ID: 19482
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: PCRE related
Operating System: Redhat 7.3
PHP Version: 4.2.3,4.3.0-dev
New Comment:
Note sure if this will be useful, but if i edit main/php_config.h
(after running ./configure) and remove all LOCALE defines, here's a
backtrace of the segfault:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 6702)]
0x403d6c67 in _zval_dtor (zvalue=0x82ad344,
__zend_filename=0x40432520
/tmp/php-debug/Zend/zend_execute_API.c,
__zend_lineno=291) at /tmp/php-debug/Zend/zend_variables.c:43
43 CHECK_ZVAL_STRING_REL(zvalue);
(gdb) bt
#0 0x403d6c67 in _zval_dtor (zvalue=0x82ad344,
__zend_filename=0x40432520
/tmp/php-debug/Zend/zend_execute_API.c,
__zend_lineno=291) at /tmp/php-debug/Zend/zend_variables.c:43
#1 0x403cd471 in _zval_ptr_dtor (zval_ptr=0x40463b80,
__zend_filename=0x40434300
/tmp/php-debug/Zend/zend_execute_locks.h,
__zend_lineno=26) at /tmp/php-debug/Zend/zend_execute_API.c:291
#2 0x403ee0b4 in zend_clean_garbage () at
/tmp/php-debug/Zend/zend_execute_locks.h:26
#3 0x403e7bd5 in execute (op_array=0x82ae564) at
/tmp/php-debug/Zend/zend_execute.c:1050
#4 0x403eab86 in execute (op_array=0x81e95c4) at
/tmp/php-debug/Zend/zend_execute.c:1641
#5 0x403eab86 in execute (op_array=0x8241b2c) at
/tmp/php-debug/Zend/zend_execute.c:1641
#6 0x403d8ad8 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /tmp/php-debug/Zend/zend.c:834
#7 0x403a2542 in php_execute_script (primary_file=0xb700)
at /tmp/php-debug/main/main.c:1542
#8 0x403ef8c2 in apache_php_module_main (r=0x808cf18,
display_source_mode=0)
at /tmp/php-debug/sapi/apache/sapi_apache.c:55
#9 0x403f07bc in send_php (r=0x808cf18, display_source_mode=0,
filename=0x808ebe0 /var/www/modesmail/horde/imp/redirect.php)
at /tmp/php-debug/sapi/apache/mod_php4.c:564
#10 0x403f0829 in send_parsed_php (r=0x808cf18)
at /tmp/php-debug/sapi/apache/mod_php4.c:579
#11 0x0805475d in ap_invoke_handler ()
#12 0x080672dc in process_request_internal ()
#13 0x08067353 in ap_process_request ()
#14 0x0805f587 in child_main ()
#15 0x0805f72a in make_child ()
---Type return to continue, or q return to quit---
#16 0x0805f86d in startup_children ()
#17 0x0805fec0 in standalone_main ()
#18 0x080607c3 in main ()
#19 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
Previous Comments:
[2002-10-06 14:47:25] [EMAIL PROTECTED]
(gdb) up
#1 0x40304db2 in pcre_get_compiled_regex (regex=0x8201704 |MSIE
([0-9.]+)|,
extra=0xbfff7cac, preg_options=0xbfff7ca4)
at /tmp/php4-20021006/ext/pcre/php_pcre.c:158
158 if (!strcmp(pce-locale, locale)) {
(gdb) print locale
$1 = 0x8156760 en_US.iso885915
(gdb) print pce
$2 = (pcre_cache_entry *) 0x8133668
(gdb) print pce-locale
$3 = 0x826bde8 Address 0x826bde8 out of bounds
[2002-10-06 07:44:55] [EMAIL PROTECTED]
[EMAIL PROTECTED] :
Can you try that again, but when you hit the segfault,
type the following commands into gdb:
up
print locale
print pce
print pce-locale
[2002-10-06 04:46:27] [EMAIL PROTECTED]
Still getting the segfault at almost the same place. Seems a lot
easier to reproduce now.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 8821)]
0x4207fb88 in strcmp () from /lib/i686/libc.so.6
(gdb) bt
#0 0x4207fb88 in strcmp () from /lib/i686/libc.so.6
#1 0x40304db2 in pcre_get_compiled_regex (
regex=0x819925c |Internet Explorer/([0-9.]+)|, extra=0xbfff8ebc,
preg_options=0xbfff8eb4) at
/tmp/php4-20021006/ext/pcre/php_pcre.c:158
#2 0x40305827 in php_pcre_match (ht=3, return_value=0x81353cc,
this_ptr=0x0,
return_value_used=1, global=0) at
/tmp/php4-20021006/ext/pcre/php_pcre.c:408
#3 0x40305e74 in zif_preg_match (ht=3, return_value=0x81353cc,
this_ptr=0x0,
return_value_used=1) at
/tmp/php4-20021006/ext/pcre/php_pcre.c:559
#4 0x403eafa3 in execute (op_array=0x81e5dfc)
at /tmp/php4-20021006/Zend/zend_execute.c:1597
#5 0x403eb1d6 in execute (op_array=0x8198e24)
at /tmp/php4-20021006/Zend/zend_execute.c:1641
#6 0x403eb1d6 in execute (op_array=0x8223314)
at /tmp/php4-20021006/Zend/zend_execute.c:1641
#7 0x403ed202 in execute (op_array=0x817d5e4)
at /tmp/php4-20021006/Zend/zend_execute.c:2163
#8 0x403d9128 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /tmp/php4-20021006/Zend/zend.c:834
#9 0x403a2b92 in php_execute_script (primary_file=0xb6f0)
at /tmp/php4-20021006/main/main.c:1542
#19482 [Com]: segfault on child process
ID: 19482 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: PCRE related Operating System: Redhat 7.3 PHP Version: 4.2.3,4.3.0-dev New Comment: hello! i have nearly the same problem... i've wondered, that sometimes are segfaults in the error_log. i have installed the newest php (4.2.3) apache (1.3.26) version. now i have found a cause: if this in the mail header: From: () imp shows nbsp; as sender. with the attempt to open the email, the apache- process segfaulted. after some try, i could fetch a strace-log from the process. you can found it here: http://dpits.de/segfault.log thank you! bye daniel prior Previous Comments: [2002-09-27 10:53:40] [EMAIL PROTECTED] I upgraded from 4.1.2 to 4.2.3 yesterday and have seen many seg faults in the error_log when I came in this morning. I am using Apache 1.3.26, mod_ssl 2.8.10, Openssl 0.9.6g, Compaq Tru64 4.0G. My PHP configure is pretty basic: ./configure --with-mysql --with-imap --with-curl --quiet --with-apxs=(path_to_apxs) We, also, are using IMP (2.2.7). I have not tried to produce the seg-faults [2002-09-25 14:51:06] [EMAIL PROTECTED] I'm encounting this same bug using Horde/IMP/Turba (2.1/3.1/1.1) on Red Hat 7.3 with all updates (except mm-1.1.3-8 which seems to cause problems with Apache restarts) and here's what i've tried: - compiling Apache (1.3.26), PHP (4.2.3), and mod_ssl (2.8.10) without mm support - compiling PHP 4.2.3 without mm support and using the pcre library packaged with Red Hat - downloading a fresh pcre library (v3.9) and compiling PHP against that. - compiling everything with mm support and external pcre library (3.9) In each case the same segfault occurs. If i compile the software (Apache, mod_ssl, PHP) with debugging symbols i can't get the segfault to occur. Been through about 300 test messages and it still hasn't segfaulted. This is driving me nuts. [2002-09-20 09:33:51] [EMAIL PROTECTED] Using php.ini-recommended fixed the zlib problem. So now I am able to use the snapshot normally. However, I ran apache within gdb and I got pretty much the exact same backtrace as I got with 4.2.3. I guess it looks like a PCRE problem. Please let me know what I need to do next and thanks for the quick response [2002-09-20 07:09:48] [EMAIL PROTECTED] I guess the zlib issue is with the output buffering. Check your php.ini settings. (and try using the php.ini-dist as base for your new one..) And the original problem, if the backtrace you get now is about the same as the one you already pasted here, don't add another one. Reclassified as PCRE related. [2002-09-20 01:42:06] [EMAIL PROTECTED] sorry, i forgot to mention that I tried running the snapshot without zlib support (and png and dom xml support) and got IMP to somewhat work under that environment. However, like I said previously the snapshot did not fix the seg fault problem I am having. Please let me know what you want to do next Thanks 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 http://bugs.php.net/19482 -- Edit this bug report at http://bugs.php.net/?id=19482edit=1
#19482 [Com]: segfault on child process
ID: 19482 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: PCRE related Operating System: Redhat 7.3 PHP Version: 4.2.3,4.3.0-dev New Comment: I'm encounting this same bug using Horde/IMP/Turba (2.1/3.1/1.1) on Red Hat 7.3 with all updates (except mm-1.1.3-8 which seems to cause problems with Apache restarts) and here's what i've tried: - compiling Apache (1.3.26), PHP (4.2.3), and mod_ssl (2.8.10) without mm support - compiling PHP 4.2.3 without mm support and using the pcre library packaged with Red Hat - downloading a fresh pcre library (v3.9) and compiling PHP against that. - compiling everything with mm support and external pcre library (3.9) In each case the same segfault occurs. If i compile the software (Apache, mod_ssl, PHP) with debugging symbols i can't get the segfault to occur. Been through about 300 test messages and it still hasn't segfaulted. This is driving me nuts. Previous Comments: [2002-09-20 09:33:51] [EMAIL PROTECTED] Using php.ini-recommended fixed the zlib problem. So now I am able to use the snapshot normally. However, I ran apache within gdb and I got pretty much the exact same backtrace as I got with 4.2.3. I guess it looks like a PCRE problem. Please let me know what I need to do next and thanks for the quick response [2002-09-20 07:09:48] [EMAIL PROTECTED] I guess the zlib issue is with the output buffering. Check your php.ini settings. (and try using the php.ini-dist as base for your new one..) And the original problem, if the backtrace you get now is about the same as the one you already pasted here, don't add another one. Reclassified as PCRE related. [2002-09-20 01:42:06] [EMAIL PROTECTED] sorry, i forgot to mention that I tried running the snapshot without zlib support (and png and dom xml support) and got IMP to somewhat work under that environment. However, like I said previously the snapshot did not fix the seg fault problem I am having. Please let me know what you want to do next Thanks [2002-09-20 01:40:23] [EMAIL PROTECTED] unfortunately, this does not fix the original problem, I still get seg faults when viewing messages (no particular message). I'll try to post a backtrace a little later [2002-09-20 01:22:45] [EMAIL PROTECTED] Ok, did this with the new snapshot, however I've figured out what causes the PHP 4.3.0-dev to hang. Basically if I use the --with-zlib configure option, a simple ?phpinfo()? fails to load correctly. If I take this option out, then the ?phpinfo()? displays correctly. I then tried to reinstall zlib (in case it was somehow messed up in RedHat) but that made no difference. I tried different variations of --with-zlib such as: * --with-zlib * --with-zlib=/usr/local * --with-zlib=/usr * --with-zlib=/usr/local --with-zlib-dir=/usr/local * --with-zlib=/usr --with-zlib-dir=/usr If I use any of these, PHP scripts fail to load with the new dev snapshot. However, I am using this option with 4.2.3 with no problems. Maybe its a bug in the dev snapshot? If you need any more information let me know. Thanks 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 http://bugs.php.net/19482 -- Edit this bug report at http://bugs.php.net/?id=19482edit=1
#19482 [Com]: segfault on child process
ID: 19482 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Redhat 7.3 PHP Version: 4.2.3 New Comment: Forgot to mention in there I actually did compile the snapshot :) Previous Comments: [2002-09-19 08:53:03] [EMAIL PROTECTED] Sorry if I wasn't specific enough. Here is what I did * configure the snapshot with the following options ./configure --with-apxs=/usr/local/apache/bin/apxs --enable-track-vars --with-openssl=/usr/local/ssl --with-zlib --with-bz2 --with-pspell --with-db3=/usr/lib --enable-ftp --with-gd --with-imap=/usr/local/imap-2001a --with-imap-ssl=/usr/local/ssl --with-ldap --with-jpeg-dir=/usr/lib --with-xpm-dir=/usr/lib --with-png-dir=/usr/lib --with-freetype-dir=/usr/lib --enable-sigchild --with-gettext --with-mcrypt --with-xml --with-mysql=/usr/local/mysql --enable-cli --with-dom --with-dom-xslt --with-dom-exslt --with-mhash --with-mm --enable-debug * shutdown the web server * run make install * start up the web server * restart the web server again for good measure * request a PHP file with ?phpinfo()? in it Basically what happens is that the browser hangs while trying to load the ?phpinfo()? file. It sits there trying to load the file, and nothing happens. Nothing gets printed to the error_log except the following: [Thu Sep 19 09:27:41 2002] [notice] Apache/1.3.26 (Unix) PHP/4.3.0-dev mod_ssl/2.8.10 OpenSSL/0.9.6g configured -- resuming normal operations [Thu Sep 19 09:27:41 2002] [notice] Accept mutex: sysvsem (Default: sysvsem) So after a minute, I shutdown the web server and now lots of stuff starts spitting out to the error_log /usr/local/software/php4-200209181500/main/spprintf.c(143) : Freeing 0x081804D4 (257 bytes), script=/usr/local/apache/htdocs/web/test.php Last leak repeated 2 times /usr/local/software/php4-200209181500/main/output.c(415) : Freeing 0x081802AC (23 bytes), script=/usr/local/apache/htdocs/web/test.php /usr/local/software/php4-200209181500/main/output.c(409) : Freeing 0x0817EA74 (6145 bytes), script=/usr/local/apache/htdocs/web/test.php Last leak repeated 1 time /usr/local/software/php4-200209181500/Zend/zend_stack.c(27) : Freeing 0x0817E6F4 (256 bytes), script=/usr/local/apache/htdocs/web/test.php Last leak repeated 7 times /usr/local/software/php4-200209181500/Zend/zend_opcode.c(295) : Freeing 0x08182B44 (120 bytes), script=/usr/local/apache/htdocs/web/test.php Zend/zend_language_scanner.c(4433) : Freeing 0x08183A74 (8 bytes), script=/usr/local/apache/htdocs/web/test.php /usr/local/software/php4-200209181500/Zend/zend_opcode.c(65) : Freeing 0x08182B0C (4 bytes), script=/usr/local/apache/htdocs/web/test.php /usr/local/software/php4-200209181500/Zend/zend_hash.c(262) : Freeing 0x08182A7C (89 bytes), script=/usr/local/apache/htdocs/web/test.php Last leak repeated 66 times /usr/local/software/php4-200209181500/Zend/zend_compile.c(136) : Freeing 0x0817E9BC (54 bytes), script=/usr/local/apache/htdocs/web/test.php /usr/local/software/php4-200209181500/Zend/zend_execute.c(1597) : Freeing 0x0817E864 (12 bytes), script=/usr/local/apache/htdocs/web/test.phpZend/zend_language_scanner.c(3054) : Freeing 0x0817E604 (84 bytes), script=/usr/local/apache/htdocs/web/test.php /usr/local/software/php4-200209181500/main/output.c(336) : Freeing 0x0817E53C (1 bytes), script=/usr/local/apache/htdocs/web/test.php /usr/local/software/php4-200209181500/main/output.c(340) : Freeing 0x0817E4F4 (24 bytes), script=/usr/local/apache/htdocs/web/test.php /usr/local/software/php4-200209181500/ext/mbstring/mbstring.c(773) : Freeing 0x0817E474 (20 bytes), script=/usr/local/apache/htdocs/web/test.php /usr/local/software/php4-200209181500/Zend/zend_hash.c(178) : Freeing 0x0817E424 (32 bytes), script=/usr/local/apache/htdocs/web/test.php Last leak repeated 10 times /usr/local/software/php4-200209181500/main/main.c(1345) : Freeing 0x0817E2C4 (44 bytes), script=/usr/local/apache/htdocs/web/test.php /usr/local/software/php4-200209181500/Zend/zend_API.c(565) : Actual location (location was relayed) /usr/local/software/php4-200209181500/main/main.c(1344) : Freeing 0x0817E284 (12 bytes), script=/usr/local/apache/htdocs/web/test.php /usr/local/software/php4-200209181500/main/main.c(1327) : Freeing 0x0817DD34 (44 bytes), script=/usr/local/apache/htdocs/web/test.php /usr/local/software/php4-200209181500/Zend/zend_API.c(565) : Actual location (location was relayed) /usr/local/software/php4-200209181500/main/main.c(1326) : Freeing 0x0817DCF4 (12 bytes), script=/usr/local/apache/htdocs/web/test.php /usr/local/software/php4-200209181500/main/main.c(1429) : Freeing 0x0817DC04 (12 bytes), script=/usr/local/apache/htdocs/web/test.php /usr/local/software/php4-200209181500/main/main.c(1382) : Freeing 0x0817DB54 (44 bytes),
