Bug 10335 - Loading custom libphp3.so segfaults on startup
Loading custom libphp3.so segfaults on startup
Product: Red Hat Secure Web Server
Classification: Retired
Component: secureweb (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
Depends On:
  Show dependency treegraph
Reported: 2000-03-24 19:19 EST by Peter Zingg
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-03-27 12:48:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Stack trace after fault from gdb (1.21 KB, text/plain)
2000-03-24 19:22 EST, Peter Zingg
no flags Details

  None (edit)
Description Peter Zingg 2000-03-24 19:19:57 EST
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
Comment 1 Peter Zingg 2000-03-24 19:22:59 EST
Created attachment 160 [details]
Stack trace after fault from gdb
Comment 2 Peter Zingg 2000-03-24 22:20:59 EST
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 07:50:59 EST
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.
Comment 4 Peter Zingg 2000-03-27 12:48:59 EST
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.

Note You need to log in before you can comment on or make changes to this bug.