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 AddModule mod_php3.c. 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 mod_perl.
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 called. 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.