|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2000-08-11 00:19 UTC] yml at dtlink dot com
[2000-08-23 05:34 UTC] sniper@php.net
[2000-09-18 06:16 UTC] sniper@php.net
[2000-11-02 07:09 UTC] zeev@php.net
|
|||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Sat Dec 21 16:01:28 2024 UTC |
On an Ultra 2 running Solaris 8, PHP sits in some kind of endless loop in zend_append_version_info() in a longjump(). It seems to happen at random and apparently occurs on a variety of pages. The installation uses Mysql 3.22.32. The bug reproduces itself very reliably on the Ultra 2 here. After a day I'll have as many as 7 stuck httpd processes just chewing up endless amounts of CPU time (and making the machine noticeably slow with loads over 7 . . ) I do not know what combination of events causes the problem. It seems to happen on random pages judging by the output of the gdb backtrace. From top: 23943 nobody 1 0 0 4712K 3088K run 6:54 98.49% httpd My setup according to phpinfo(): PHP Version 4.0.1pl2 System SunOS www.xxx.xxx 5.8 Beta_Refresh sun4u sparc SUNW,Ultra-60 Build Date Jul 12 2000 Configure Command './configure' '--with-apxs=/usr/local/apache_php_4.0.1pl2/bin/apxs' '--with-mysql=/usr/local' '--disable-xml' '--enable-track-vars' '--without-gd' Server API Apache Virtual Directory Support disabled Configuration File (php.ini) Path /usr/local/lib ZEND_DEBUG disabled Thread Safety disabled The php.ini is the box-stock one distributed with PHP. Apache version is 1.3.12 compiled using: configure --prefix=/usr/local/apache_php_4.0.1.pl2 --enable-shared=max Mysql is 3.22.32 The GDB back-trace is: #0 0xff1b7164 in longjmp () from /lib/libc.so.1 #1 0xfee42c68 in zend_append_version_info (extension=0x1) at zend.c:452 #2 0xfeeba7dc in php_ub_body_write ( str=0x1c00 <Address 0x1c00 out of bounds>, str_length=4277187616) at output.c:291 #3 0xfeeba7dc in php_ub_body_write ( str=0x11b718 "<!--Site Designed and Developed by Nuts & Bolts Interactive, LLC http://www.nbinteractive.com-->\n<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\">\n<html>\n<head>\n\t<title>!-800-714-SCSI - D"..., str_length=3423) at output.c:291 #4 0xfeebaacc in php_ob_send () at output.c:224 #5 0xfeeba54c in php_end_ob_buffering (send_buffer=1) at output.c:118 #6 0xfee51ff8 in apache_php_module_main (r=0x0, fd=63, display_source_mode=0) at sapi_apache.c:97 #7 0xfee52b48 in send_php (r=0x115680, display_source_mode=0, filename=0x115bf8 "/export/home/virtual01/dsd/index.html") at mod_php4.c:515 #8 0xfee52b84 in send_parsed_php (r=0x115680) at mod_php4.c:527 #9 0x20ba8 in ap_invoke_handler () #10 0x3d34c in process_request_internal () #11 0x3d86c in ap_internal_redirect () #12 0xff080c54 in handle_dir () from /usr/local/apache_php_4.0.1pl2/libexec/mod_dir.so #13 0x20ba8 in ap_invoke_handler () #14 0x3d34c in process_request_internal () #15 0x3d3d0 in ap_process_request () #16 0x30e28 in child_main () #17 0x311b4 in make_child () #18 0x3172c in perform_idle_server_maintenance () #19 0x31f90 in standalone_main () #20 0x328c4 in main () single stepping from the longjump produces: (gdb) s Single stepping until exit from function longjmp, which has no line number information. php_execute_script (primary_file=0xffbef2b8) at main.c:1159 1159 } (gdb) s apache_php_module_main (r=0x0, fd=63, display_source_mode=0) at sapi_apache.c:96 96 php_header(); /* Make sure headers have been sent */ (gdb) s php_header () at head.c:80 80 if (sapi_send_headers()==FAILURE || SG(request_info).headers_only) { (gdb) s sapi_send_headers () at SAPI.c:448 448 if (SG(headers_sent)) { (gdb) s 443 { (gdb) s 0xfee5be78 in sapi_globals_ctor (sapi_globals=0x0) at SAPI.c:62 62 memset(sapi_globals,0,sizeof(*sapi_globals)); (gdb) s sapi_send_headers () at SAPI.c:448 448 if (SG(headers_sent)) { (gdb) s 445 int ret = FAILURE; (gdb) s 448 if (SG(headers_sent)) { (gdb) s 449 return SUCCESS; (gdb) s 492 return ret; (gdb) s php_header () at head.c:81 81 return 0; /* don't allow output */ (gdb) s 83 return 1; /* allow output */ (gdb) s apache_php_module_main (r=0x0, fd=63, display_source_mode=0) at sapi_apache.c:97 97 php_end_ob_buffering(1); (gdb) s php_end_ob_buffering (send_buffer=1) at output.c:109 109 if (!OG(ob_buffer)) { (gdb) s 105 { (gdb) s 0xfeeba360 in readdir_r (__dp=0x1, __ent=0xfef0b420, __res=0x1) at /usr/include/dirent.h:151 151 } (gdb) s php_end_ob_buffering (send_buffer=1) at output.c:109 109 if (!OG(ob_buffer)) { (gdb) s 112 if (SG(headers_sent) && !SG(request_info).headers_only) { (gdb) s 115 OG(php_body_write) = php_ub_body_write; (gdb) s 117 if (send_buffer) { (gdb) s 118 php_ob_send(); (gdb) s php_ob_send () at output.c:224 224 OG(php_body_write)(OG(ob_buffer), OG(ob_text_length)); (gdb) s 220 { (gdb) s 0xfeeba360 in readdir_r (__dp=0x1dac, __ent=0xfeeba7a4, __res=0x1b8c) at /usr/include/dirent.h:151 151 } (gdb) s php_ob_send () at output.c:224 224 OG(php_body_write)(OG(ob_buffer), OG(ob_text_length)); (gdb) s php_ub_body_write (str=0x0, str_length=3423) at output.c:290 290 if (SG(request_info).headers_only) { (gdb) s 285 { (gdb) s 0xfeeba360 in readdir_r (__dp=0x11b718, __ent=0xd5f, __res=0xfef0b618) at /usr/include/dirent.h:151 151 } (gdb) s php_ub_body_write (str=0x0, str_length=3423) at output.c:290 290 if (SG(request_info).headers_only) { (gdb) s 285 { (gdb) s 290 if (SG(request_info).headers_only) { (gdb) s 291 zend_bailout(); (gdb) s zend_bailout () at zend.c:452 452 longjmp(EG(bailout), FAILURE); (gdb) s 447 { (gdb) s 0xfee4221c in ctime_r (__time=0x1, __buf=0xfef0b420 "") at /usr/include/time.h:267 267 } (gdb) s zend_bailout () at zend.c:452 452 longjmp(EG(bailout), FAILURE); (gdb) s 451 CG(unclean_shutdown) = 1; (gdb) s 452 longjmp(EG(bailout), FAILURE); (gdb) s and then it just sits for eternity chewing up CPU time. It never comes back from the longjmp(). Solaris libc bug maybe? Any pointers would be greatly appreciated. This is a live production machine and I need to come up with either a fix or some workaround. I can be reached at yml@dtlink.com. Let me know what I can do to help track down this problem. thanks, -- Yermo