#36472 [Opn]: Memory fault

2006-02-21 Thread Eskil dot Swahn at LDC dot lu dot se
 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

2006-02-21 Thread Eskil dot Swahn at LDC dot lu dot se
 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

2006-02-21 Thread Eskil dot Swahn at LDC dot lu dot se
 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

2006-02-21 Thread Eskil dot Swahn at LDC dot lu dot se
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