Red Hat Bugzilla – Bug 10335
Loading custom libphp3.so segfaults on startup
Last modified: 2008-05-01 11:37:55 EDT
Using secure-web-server 3.1-2 i386 distribution.
Building libphp3.so (php-3.0.14 or 3.0.15) --with-apxs --with-mysql --with-
openlink on RedHat 6.1. httpd.conf has LoadModule libphp3.so and
Running "httpsd -t" or "httpsd" with or without "-D SSL" causes core dump
(segmentation fault). Depending on settings in php3.ini, core dump occurs
in seemingly random places. Apparently does not depend on mod_ssl or
Created attachment 160 [details]
Stack trace after fault from gdb
I found out that the bug is only present when i compile libphp3.so with
configuration option "--with-openlink". I'm guessing that the openlink
libraries are causing some linkage problems. I'm kind of a newbie at the unix
linker/loader. Openlink sdk is available for libc5, glibc2 and glibc2.1. I'm
using the glibc2.1 version. Is that right?
Yes, the 2.1 SDK is correct version to use with 3.1.
Looking at the stack trace shows the server dying when calling the mysql
initialization routine, which dies in a glibc internal function. Because glibc
usually doesn't die in getservbyname(), this would indicate that memory is being
overwritten or the stack is getting trashed somewhere before this function is
Whether this is due to problems with openlink or interactions between openlink
and MySQL, I can't tell.
It was a link problem. I had several copies of libiodbc.so floating around on
my system, and I didn't specify explicitly which one to use when configuring
mod_php. For RedHat 6.1, use the libiodbc source distribution at
http://www.iodbc.org, and point the mod_php build to the compiled shared
libaries, with a "--with-iodbc=<path to libidobc>" configuration parameter.
You can close this one, I guess.