#36472 [Opn]: Memory fault
ID: 36472 User updated by: Eskil dot Swahn at LDC dot lu dot se Reported By: Eskil dot Swahn at LDC dot lu dot se Status: Open Bug Type: Apache related Operating System: Tru64 UNIX V5.1B PHP Version: 4.4.2 New Comment: Something that was interesting as well was that 'httpd -X' doesn't coredump, it's not until I run 'apachectl startssl' that I trigger the memory fault.. Previous Comments: ---- [2006-02-21 15:05:52] Eskil dot Swahn at LDC dot lu dot se I have generated a core file and I am waiting on help from HP on how to handle the debugger. My session so far: dbx version 5.1 Type 'help' for help. Core file created by program "httpd" thread 0x4 signal Segmentation fault at >*[strcmp, 0x3ff800d8334] ldq_u t1, 0(a1) (dbx) help Command syntax: "help ", is one of the following list: most_used, quit, alias, record, playback, history, lineedit, run, rerun, stop, step, next, trace, delete, catch, ignore, cont, return, when, goto, print, printx, printo, printd, printf, printregs, where, status, whatis, which, whereis, assign, tag, up, down, func, dump, display, list, search, edit, file, use, set, setenv, sh, stopi, conti, stepi, nexti, tracei, listobj, enable, disable, kernel, tlist, tset, tstack, call, attach, detach, plist, switch, variable, register, builtin, expression (dbx) trace trace ^ syntax error (dbx) help trace trace - print when it changes trace at - print when is reached trace in - print when call trace at if - print when is reached and trace in if - print when call and (dbx) quit Does this help in any way so far? [2006-02-21 11:17:43] [EMAIL PROTECTED] No, you're on your own for that... but your best bet would be to start apache in single process mode (-X) in the debugger and then request your script. The debugging should capture it when it segfaults and i guess there is a command to make a backtrace then. ---------------------------- [2006-02-21 11:12:28] Eskil dot Swahn at LDC dot lu dot se Checked the instructions for generating a backtrace. Any chance of instructions for T64's dbx instead of gdb? [2006-02-21 10:51:03] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. -------------------------------- [2006-02-21 10:44:34] Eskil dot Swahn at LDC dot lu dot se Description: I have failed to upgrade our PHP-installation on Tru64 UNIX to 4.4.1 or 4.4.2 (successful on Linux and Solaris). When I try to restart Apache after copying a new libphp4.so I get a crash which only lists the following: bin/apachectl: 814341 Memory fault bin/apachectl startssl: httpd could not be started This setup has worked flawlessly upto 4.4.0 but both 4.4.1 and 4.4.2 triggers this behaviour. Config: ./configure --with-apache=../apache_1.3.33 --with-prefix=/usr/local/php --with-oci8=/usr/users/dba/oracle/product/9.2.0 --with-openssl I can find no further information in any of Apache's logfiles. This is a setup with Apache 1.3.33 and mod_ssl 2.8.22. -- Edit this bug report at http://bugs.php.net/?id=36472&edit=1
#36472 [Fbk->Opn]: Memory fault
ID: 36472 User updated by: Eskil dot Swahn at LDC dot lu dot se Reported By: Eskil dot Swahn at LDC dot lu dot se -Status: Feedback +Status: Open Bug Type: Apache related Operating System: Tru64 UNIX V5.1B PHP Version: 4.4.2 New Comment: I have generated a core file and I am waiting on help from HP on how to handle the debugger. My session so far: dbx version 5.1 Type 'help' for help. Core file created by program "httpd" thread 0x4 signal Segmentation fault at >*[strcmp, 0x3ff800d8334] ldq_u t1, 0(a1) (dbx) help Command syntax: "help ", is one of the following list: most_used, quit, alias, record, playback, history, lineedit, run, rerun, stop, step, next, trace, delete, catch, ignore, cont, return, when, goto, print, printx, printo, printd, printf, printregs, where, status, whatis, which, whereis, assign, tag, up, down, func, dump, display, list, search, edit, file, use, set, setenv, sh, stopi, conti, stepi, nexti, tracei, listobj, enable, disable, kernel, tlist, tset, tstack, call, attach, detach, plist, switch, variable, register, builtin, expression (dbx) trace trace ^ syntax error (dbx) help trace trace - print when it changes trace at - print when is reached trace in - print when call trace at if - print when is reached and trace in if - print when call and (dbx) quit Does this help in any way so far? Previous Comments: [2006-02-21 11:17:43] [EMAIL PROTECTED] No, you're on your own for that... but your best bet would be to start apache in single process mode (-X) in the debugger and then request your script. The debugging should capture it when it segfaults and i guess there is a command to make a backtrace then. -------- [2006-02-21 11:12:28] Eskil dot Swahn at LDC dot lu dot se Checked the instructions for generating a backtrace. Any chance of instructions for T64's dbx instead of gdb? [2006-02-21 10:51:03] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. ------------------------ [2006-02-21 10:44:34] Eskil dot Swahn at LDC dot lu dot se Description: I have failed to upgrade our PHP-installation on Tru64 UNIX to 4.4.1 or 4.4.2 (successful on Linux and Solaris). When I try to restart Apache after copying a new libphp4.so I get a crash which only lists the following: bin/apachectl: 814341 Memory fault bin/apachectl startssl: httpd could not be started This setup has worked flawlessly upto 4.4.0 but both 4.4.1 and 4.4.2 triggers this behaviour. Config: ./configure --with-apache=../apache_1.3.33 --with-prefix=/usr/local/php --with-oci8=/usr/users/dba/oracle/product/9.2.0 --with-openssl I can find no further information in any of Apache's logfiles. This is a setup with Apache 1.3.33 and mod_ssl 2.8.22. -- Edit this bug report at http://bugs.php.net/?id=36472&edit=1
#36472 [Fbk->Opn]: Memory fault
ID: 36472 User updated by: Eskil dot Swahn at LDC dot lu dot se Reported By: Eskil dot Swahn at LDC dot lu dot se -Status: Feedback +Status: Open Bug Type: Apache related Operating System: Tru64 UNIX V5.1B PHP Version: 4.4.2 New Comment: Checked the instructions for generating a backtrace. Any chance of instructions for T64's dbx instead of gdb? Previous Comments: [2006-02-21 10:51:03] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2006-02-21 10:44:34] Eskil dot Swahn at LDC dot lu dot se Description: I have failed to upgrade our PHP-installation on Tru64 UNIX to 4.4.1 or 4.4.2 (successful on Linux and Solaris). When I try to restart Apache after copying a new libphp4.so I get a crash which only lists the following: bin/apachectl: 814341 Memory fault bin/apachectl startssl: httpd could not be started This setup has worked flawlessly upto 4.4.0 but both 4.4.1 and 4.4.2 triggers this behaviour. Config: ./configure --with-apache=../apache_1.3.33 --with-prefix=/usr/local/php --with-oci8=/usr/users/dba/oracle/product/9.2.0 --with-openssl I can find no further information in any of Apache's logfiles. This is a setup with Apache 1.3.33 and mod_ssl 2.8.22. -- Edit this bug report at http://bugs.php.net/?id=36472&edit=1
#36472 [NEW]: Memory fault
From: Eskil dot Swahn at LDC dot lu dot se Operating system: Tru64 UNIX V5.1B PHP version: 4.4.2 PHP Bug Type: Apache related Bug description: Memory fault Description: I have failed to upgrade our PHP-installation on Tru64 UNIX to 4.4.1 or 4.4.2 (successful on Linux and Solaris). When I try to restart Apache after copying a new libphp4.so I get a crash which only lists the following: bin/apachectl: 814341 Memory fault bin/apachectl startssl: httpd could not be started This setup has worked flawlessly upto 4.4.0 but both 4.4.1 and 4.4.2 triggers this behaviour. Config: ./configure --with-apache=../apache_1.3.33 --with-prefix=/usr/local/php --with-oci8=/usr/users/dba/oracle/product/9.2.0 --with-openssl I can find no further information in any of Apache's logfiles. This is a setup with Apache 1.3.33 and mod_ssl 2.8.22. -- Edit bug report at http://bugs.php.net/?id=36472&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36472&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36472&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36472&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36472&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36472&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36472&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36472&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36472&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36472&r=support Expected behavior:http://bugs.php.net/fix.php?id=36472&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36472&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36472&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36472&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36472&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36472&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36472&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36472&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36472&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36472&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36472&r=mysqlcfg