|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2000-07-29 02:21 UTC] sniper@php.net
[2000-08-06 16:07 UTC] sniper@php.net
|
|||||||||||||||||||||||||||
Copyright © 2001-2026 The PHP GroupAll rights reserved. |
Last updated: Mon Oct 12 10:00:01 2026 UTC |
Apache + PHP4 seems to be running rampant on one of my machines whenever a MySQL query fails. Debian machine. Upgrades are done by a semi-proficient user, more of a toy/learning box than anything... Anyways, the process that is getting the SIGPIPE runs up to about 160MB of memory, freezing everything else on said machine, then terminates. GDB output below... [ root@dan ] /usr/local/apache/bin 621-->gdb httpd (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X Program received signal SIGPIPE, Broken pipe. 0x40173b47 in writev () from /lib/libc.so.6 (gdb) bt #0 0x40173b47 in writev () from /lib/libc.so.6 #1 0x80fbc8e in writev_it_all () #2 0x80fc0cb in large_write () #3 0x80fc1a7 in ap_bwrite () #4 0x810e391 in ap_rwrite () #5 0x8084c35 in zend_apache_ub_write () #6 0x80eacd2 in php_ub_body_write_no_header ( str=0xbfff820c "<br>\n<b>Parse error</b>: parse error, expecting `T_VARIABLE' or `'$'' in <b>header.php3</b> on line <b>0</b><br>\n", str_length=114) at output.c:318 #7 0x80eaa38 in php_body_write ( str=0xbfff820c "<br>\n<b>Parse error</b>: parse error, expecting `T_VARIABLE' or `'$'' in <b>header.php3</b> on line <b>0</b><br>\n", str_length=114) at output.c:149 #8 0x8085a1d in php_printf (format=0x814b3a0 "<br>\n<b>%s</b>: %s in <b>%s</b> on line <b>%d</b><br>\n") at main.c:336 #9 0x8085c9c in php_error (type=4, format=0x8410688 "parse error, expecting `T_VARIABLE' or `'$''") at main.c:434 #10 0x80972d2 in zenderror (error=0x8410688 "parse error, expecting `T_VARIABLE' or `'$''") at zend.c:399 #11 0x80efc72 in zendparse () at /usr/share/misc/bison.simple:590 #12 0x809ddf8 in compile_string (source_string=0xbfffbaac) at ./zend-scanner.l:479 #13 0x80f47d9 in execute (op_array=0x821bec8) at ./zend_execute.c:1998 #14 0x80f48cb in execute (op_array=0x81db6e8) at ./zend_execute.c:2008 #15 0x80f48cb in execute (op_array=0x81ce4a8) at ./zend_execute.c:2008 #16 0x8087239 in php_execute_script (primary_file=0xbffff68c) at main.c:1274 #17 0x80a1833 in apache_php_module_main (r=0x81ca8dc, fd=19, display_source_mode=0) at sapi_apache.c:86 #18 0x80852e4 in send_php () #19 0x808532e in send_parsed_php () #20 0x80fd499 in ap_invoke_handler () #21 0x811162f in process_request_internal () #22 0x811169a in ap_process_request () #23 0x8108976 in child_main () #24 0x8108b31 in make_child () #25 0x8108cac in startup_children () #26 0x810930d in standalone_main () #27 0x8109b2c in main () #28 0x400f67e2 in __libc_start_main () from /lib/libc.so.6 (gdb) ./configure --with-apache=/usr/src/apache \ --enable-trans-sid --with-db2 \ --enable-versioning --with-ftp \ --with-mysql Also, when using the mysql command line tool, I have a segfault, don't know if that is important. If it is, let me know, I will add MySQL gdb output. (I really have no idea what this guy has done to his machine, but it appears to be halfway upgraded to the "unstable" tree, while other things are obviously from "stable", so I don't know what kind of conflicts may be going on here...this machine is the "worst case" I can find for testing PHP4.)