php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #8144 apache dumps core after libphp.so loaded
Submitted: 2000-12-06 16:57 UTC Modified: 2001-01-31 07:09 UTC
From: davidb at chelsea dot net Assigned:
Status: Closed Package: Apache related
PHP Version: 4.0.3pl1 OS: Solaris 2.6
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: davidb at chelsea dot net
New email:
PHP Version: OS:

 

 [2000-12-06 16:57 UTC] davidb at chelsea dot net 
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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-12-06 19:42 UTC] sniper@php.net 
Could you please try the latest release candidate: 

http://www.php.net/distributions/php-4.0.4RC4.tar.gz

I have been running PHP on Solaris 2.6 as Apache DSO for
a long time without any kind of problems..

To get useful backtraces, add --enable-debug to your configure line.

--Jani
 [2001-01-30 04:18 UTC] sniper@php.net 
No feedback.

--Jani
 [2001-01-31 07:09 UTC] sniper@php.net 
User feedback:
--------------
Oops.  This problem was due to LARGEFILE being enabled in the web server.Patches to 4.0.4RC4 were supplied by another 
developer, who said he was going to put them into CVS, but I 
do not know if they made it in yet.
After several rounds of testing/updating, the patches appear 
to fix the problem.
---------------

The patches were committed -> this is fixed in 
PHP >= 4.0.4pl1

--Jani
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Tue Oct 28 16:00:01 2025 UTC