php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #31617 oci8 ldap causes crash
Submitted: 2005-01-19 22:26 UTC Modified: 2005-01-24 05:15 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:2 (100.0%)
From: guym at arizona dot edu Assigned:
Status: Not a bug Package: Reproducible crash
PHP Version: 4.3.10 OS: Solaris 9
Private report: No CVE-ID: None
 [2005-01-19 22:26 UTC] guym at arizona dot edu
Description:
------------
Compiling oci8 into the php LoadableModule causes each apache child to segfault immediately. Here is the gdb output:

#0  0xfd7007b8 in gslufpFLog () from /home/oracle/product/9.2.0/lib32/libclntsh.so.9.0
#1  0xfd6efb30 in ldap_init () from /home/oracle/product/9.2.0/lib32/libclntsh.so.9.0
#2  0xfe9a20ac in openConnection () from /usr/lib/libsldap.so.1

It seems it is not using Oracle's LDAP, even though that was specified during configuration. Here is my configure command:

./configure --prefix=/opt/httpd/php --with-apxs2=/opt/httpd/apache/bin/apxs --with-config-file-path=/opt/httpd/apache/conf --enable-safe-mode --with-dom-xslt --with-ldap=$ORACLE_HOME --with-oci8 --with-pgsql=/opt/httpd/postgres --with-dom --with-zlib-dir --with-openssl-dir


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-01-21 13:00 UTC] sniper@php.net
Does the crash happen with some script or in apache startup?
Is the gdb output really all of it? No more frames after #2 ?

Try find out what binary / module is linking with 
/usr/lib/libsldap.so.1 using ldd. Check httpd and all the modules that are in use.


 [2005-01-21 18:16 UTC] guym at arizona dot edu
The php cli works fine:

echo $LD_LIBRARY_PATH ; ldd php ; ./php -v
/opt/httpd/apache/lib:/opt/gnu/lib:/home/oracle/product/9.2.0/lib32:/usr/lib:/opt/httpd/postgresql/lib
        libpq.so.3 =>    /opt/httpd/postgres/lib/libpq.so.3
        libxml2.so.2 =>  /usr/lib/libxml2.so.2
        libxslt.so.1 =>  /usr/lib/libxslt.so.1
        libresolv.so.2 =>        /usr/lib/libresolv.so.2
        libm.so.1 =>     /usr/lib/libm.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libgcc_s.so.1 =>         /opt/gnu/lib/libgcc_s.so.1
        libpthread.so.1 =>       /usr/lib/libpthread.so.1
        libz.so.1 =>     /usr/lib/libz.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        /usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1
        libthread.so.1 =>        /usr/lib/libthread.so.1
        librt.so.1 =>    /usr/lib/librt.so.1
        libaio.so.1 =>   /usr/lib/libaio.so.1
        libmd5.so.1 =>   /usr/lib/libmd5.so.1
        /usr/platform/SUNW,Sun-Fire-280R/lib/libmd5_psr.so.1
PHP 4.3.10 (cli) (built: Jan 19 2005 12:24:34)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
 [2005-01-21 18:27 UTC] guym at arizona dot edu
The crash happens at apache startup (whether from apachectl or within gdb), the logged errors are like '[notice] child pid NNNN exit signal Segmentation fault (11)'.
 [2005-01-21 19:16 UTC] guym at arizona dot edu
What I suspect is when the server comes up to process the apache User / Group directives, then the solaris auth system calls sldap -- I think that is Solaris LDAP. The problem goes away if I comment out the User/Group directives... but then of course I can't start it as root, can't bind to a port less than 1024, etc.

Does that give anyone a clue how it might be worked around?
 [2005-01-24 04:55 UTC] sniper@php.net
What if you change your LD_LIBRARY_PATH to have /usr/lib as
first entry? Any help?

 [2005-01-24 05:15 UTC] sniper@php.net
As this really isn't PHP bug, closing as bogus.
I think you really should ask Sun support for help how to prevent this problem.

 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Oct 17 19:01:28 2024 UTC