Bug 10335 - Loading custom libphp3.so segfaults on startup
Summary: Loading custom libphp3.so segfaults on startup
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Secure Web Server
Classification: Retired
Component: secureweb
Version: 3.1
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-03-25 00:19 UTC by Peter Zingg
Modified: 2008-05-01 15:37 UTC (History)
0 users

(edit)
Clone Of:
(edit)
Last Closed: 2000-03-27 17:48:35 UTC


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

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.


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