PHP 4.0 Bug #8144: apache dumps core after libphp.so loaded
| From: | davidb at chelsea dot net | Date: | Wed, 06 Dec 2000 21:57:34 +0000 |
| Subject: | PHP 4.0 Bug #8144: apache dumps core after libphp.so loaded | ||
| Groups: | php.dev | ||
| Request: | Send a blank email to php-dev+get-40263@lists.php.net to get a copy of this message | ||
From: davidb@chelsea.net
Operating system: Solaris 2.6
PHP version: 4.0.3pl1
PHP Bug Type: Apache related
Bug description: apache dumps core after libphp.so loaded
We've been trying to get PHP installed into our web server configuration, and been having a
devil of a time. We're able to get everything compiled:
./configure
--prefix=/opt/php/4.0.3pl1
--with-apxs=/opt/httpd/1.3.14/sbin/apxs
--with-mysql=/usr/local
--without-gd
--with-config-file-path=/usr/local/httpd/etc/php.ini
but as soon as the module is enabled in the srm.conf, apache starts to dump core. Almost any
content - not just PHP - starts to cause a core dump. Even if .php is never called, we seem to have
the problem.
A truss isn't entirely useful:
close(12) = 0
Incurred fault #6, FLTBOUNDS %pc = 0xEF15DAD4
siginfo: SIGSEGV SEGV_MAPERR addr=0x00000068
Received signal #11, SIGSEGV [caught]
siginfo: SIGSEGV SEGV_MAPERR addr=0x00000068
chdir("/export/httpd") = 0
sigaction(SIGSEGV, 0xEFFFF160, 0xEFFFF1E0) = 0
getpid() = 9894 [9887]
kill(9894, SIGSEGV) = 0
setcontext(0xEFFFF360)
Received signal #11, SIGSEGV [default]
siginfo: SIGSEGV pid=9894 uid=72
*** process killed ***
It seems to happen after a lstat64() or a close() on a file. Apache refused to dump core, even
though permissions seem to be set fine, etc.
We've also spend a couple of hours with gdb trying to step through it, but we're having no
luck getting symbols to show up (it's a bit out of our abilities, I guess, since it's
running as a DSO). We have a baseline httpd server that we only put DSOs into, so I can't
really rebuild it statically without much gnashing of teeth; at this point, I don't know if
that would fix the problem.
I'm not sure where to turn next. Web and bug searchs show up a few similar-sounding problems
related FDs, but our httpd has plenty of room for more file descriptors. Any suggestions as to what
could be causing this bug, or how to track it down, would be most helpful.
--
Edit Bug report at: http://bugs.php.net/?id=8144&edit=1