Bug 10335

Summary: Loading custom libphp3.so segfaults on startup
Product: [Retired] Red Hat Secure Web Server Reporter: Peter Zingg <pzingg>
Component: securewebAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED NOTABUG QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 3.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-03-27 17:48:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Stack trace after fault from gdb none

Description Peter Zingg 2000-03-25 00:19:57 UTC 
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.
Comment 1 Peter Zingg 2000-03-25 00:22:59 UTC 
Created attachment 160 [details]
Stack trace after fault from gdb
Comment 2 Peter Zingg 2000-03-25 03:20:59 UTC 
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?
Comment 3 Nalin Dahyabhai 2000-03-27 12:50:59 UTC 
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.
Comment 4 Peter Zingg 2000-03-27 17:48:59 UTC 
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.