Re: PHP 4.0 Bug #8144 Updated: apache dumps core after libphp.so loaded

Howdy, Now I'm having a runtime problem, where 4.0.4RC4 fails with the following missing symbol: Syntax error on line 31 of /export/httpd/etc/srm.conf: Cannot load /opt/httpd/1.3.14/libexec/libphp4.so into server: ld.so.1: /opt/httpd/1.3.14/sbin/httpd: fatal: relocation error: file /opt/httpd/1.3.14/libexec/libphp4.so: symbol php_if_stat64: referenced symbol not found I was unable to track down where this is supposed to come from. Another person mentioned that my core dumping might be due to the LARGEFILE support running an apache, which 4.0.4 is supposed to handle properly. David. ----- ** PLEASE NOTE ** This message was composed with the aid of a speech recognition system. Please be aware there may be some strange word usage. Many thanks.... On 7 Dec 2000, Bug Database wrote: > ID: 8144 > Updated by: sniper > Reported By: davidb@chelsea.net > Status: Feedback > Bug Type: Apache related > Assigned To: > Comments: > > 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 > > Previous Comments: > --------------------------------------------------------------------------- > > [2000-12-06 16:57:34] davidb@chelsea.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. > > --------------------------------------------------------------------------- > > > Full Bug description available at: http://bugs.php.net/?id=8144 > >