php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #44499 Crash occurred in function strlen from module /lib/libc.so.1
Submitted: 2008-03-21 17:14 UTC Modified: 2008-03-24 18:45 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: bdgregg at pitt dot edu Assigned:
Status: Wont fix Package: iPlanet related
PHP Version: 4.4.8 / 5.2.5 OS: Solaris 10u4 SPARC
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: bdgregg at pitt dot edu
New email:
PHP Version: OS:

 

 [2008-03-21 17:14 UTC] bdgregg at pitt dot edu
Description:
------------
Compiled php using nsapi as follows:
1.) Install openssl
	NOTE: the "shared" option below is REQUIRED for SASL.
	PATH=$PATH:/usr/sfw/bin:/usr/ccs/bin
	export PATH
	./config --prefix=/usr/local/ssl shared
	make 
	make install

2.) Install BerkeleyDB
	cd build_unix
	../dist/configure 
	make
	make install

3.) Set Environment now.
	LD_LIBRARY_PATH=/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.6/lib:$LD_LIBRARY_PATH
	LDFLAGS="-L/usr/local/ssl/lib -R/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.6/lib -R/usr/local/BerkeleyDB.4.6/lib"
	export LDFLAGS
	CFLAGS="-I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.6/include"
	export CFLAGS
	CPPFLAGS=$CFLAGS
	export CPPFLAGS
	PATH=/usr/local/ssl/bin:/usr/local/BerkeleyDB.4.6/bin:$PATH
	export PATH

	

4.) Install SASL
	./configure --prefix=/usr/local/sasl --with-openssl=/usr/local/ssl
	make
	make install

5.) Update Environment.
	LD_LIBRARY_PATH=/usr/local/sasl/lib:/usr/local/ssl/lib:/usr/local/BerkelyDB.4.6/lib:
	exoprt LD_LIBRARY_PATH
	LDFLAGS="-L/usr/local/sasl/lib -R/usr/local/sasl/lib -L/usr/local/ssl/lib -R/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.6/lib -R/usr/local/BerkeleyDB.4.6/lib"
	export LDFLAGS
	CFLAGS="-I/usr/local/sasl/include -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.6/include"
	export CFLAGS
	CPPFLAGS=$CFLAGS
	export CPPFLAGS
	PATH=/usr/local/sasl/sbin:/usr/local/ssl/bin:/usr/local/BerkeleyDB.4.6/bin:/usr/sbin:/usr/bin:/usr/sfw/bin:/usr/ccs/bin
	export PATH

6.) Install openldap
	./configure --prefix=/usr/local/ldap --with-tls --enable-wrappers --enable-crypt --enable-bdb --disable-slapd --disable-slurpd
	make depend
	make
	make install

7.) Update Environment
	LD_LIBRARY_PATH=/usr/local/webserver/lib:/usr/local/ldap/lib:/usr/local/sasl/lib:/usr/local/ssl/lib:/usr/local/BerkelyDB.4.6/lib:
	export LD_LIBRARY_PATH
	LDFLAGS="-L/usr/local/webserver/lib -R /usr/local/webserver/lib -L/usr/local/ldap/lib -R /usr/local/ldap/lib -L/usr/local/sasl/lib -R/usr/local/sasl/lib -L/usr/local/ssl/lib -R/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.6/lib -R/usr/local/BerkeleyDB.4.6/lib"
	export LDFLAGS
	CFLAGS="-I/usr/local/webserver/include -I/usr/local/ldap/include -I/usr/local/sasl/include -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.6/include"
	export CFLAGS
	CPPFLAGS=$CFLAGS
	export CPPFLAGS
	PATH=/usr/local/webserver/bin:/usr/local/ldap/bin:/usr/local/sasl/sbin:/usr/local/ssl/bin:/usr/local/BerkeleyDB.4.6/bin:/usr/sbin:/usr/bin:/usr/sfw/bin:/usr/ccs/bin
	export PATH

8.) Install php
	./configure  --with-ldap=/usr/local/ldap --with-gettext --with-openssl=/usr/local/ssl --with-nsapi=/usr/local/webserver 
	--enable-track-vars --enable-force-cgi-redirect --with-zlib --with-gd --with-mysql  --with-ldap-sasl=/usr/local/sasl --enable-libgcc
	make
	make install

Modified the magnus.conf and obj.conf for the web server and instance.  This goes well and I'm able to load a simple phpinfo.php file <?php phpinfo(); ?> without issue.  

We are trying to perform LDAPS connection to MS Active Directory.  We have this code running under Apache on another server.  For support reasons we are trying now to use Sun Java System Web Server 7.0 update 2 (newest) to achieve the same thing.

Our code runs fine from command line.  But when run inside the web server the following shows in the error log (BTW, yes it is reporting php5 as I've also tried version 5 as well, both produce the same results).

[21/Mar/2008:12:52:02] catastrophe (15965): CORE3260: Server crash detected (signal SIGSEGV)
[21/Mar/2008:12:52:02] info (15965): CORE3261: Crash occurred in NSAPI SAF php5_execute
[21/Mar/2008:12:52:02] info (15965): CORE3262: Crash occurred in function strlen from module /lib/libc.so.1

I have captured a core file and can send it on (489MB in size) or provide information from the stack trace.

I am looking for any information of what I may have done wrong or if there is a bug that I have hit.

Thanks in advance.




Reproduce code:
---------------
The source of php code is very simple.
<?php

# Set server name.
$ldaphost = "ldaps://pittad.univ.pitt.edu";

# Make Connection Handle
$ldapconn = ldap_connect ($ldaphost) or die("Could not connect to $ldaphost");

# Make sure to use version 3 of LDAP Protocol.
ldap_set_option($ldapconn, LDAP_OPT_PROTOCOL_VERSION, 3) or die ("Could not set
version 3");
ldap_set_option($ldapconn, LDAP_OPT_DEBUG_LEVEL, 7) or die ("Could not set ldap
debug level 7");
ldap_set_option($ldapconn, LDAP_OPT_REFERRALS, 0) or die ("Could not set referrals 0");

# Username and Password
$user='cn=blahuser,ou=Accounts,dc=company,dc=com';
$password='blahpassword';

# filter
$filter='(cn=blahuser)';

print "2<br>\n";

# Authenticate to AD.
$ldapbind=ldap_bind($ldapconn,$user,$password);
   if ($ldapbind) {
       # LDAP Authentication/Bind Successful.
       print "LDAP Authentication/Bind Successful...\n<br>";
       #$sr=ldap_search($ldapconn,$base_dn,$filter,$attributes);
       $sr=ldap_search($ldapconn,$base_dn,$filter);
       $info = ldap_get_entries($ldapconn,$sr);
   } else {
       print "LDAP Authentication/Bind Unsuccessful.\n<br>";
   }
ldap_close($ldapconn);
?>


Expected result:
----------------
LDAP Authentication/Bind Successful...\n<br>

Actual result:
--------------
Web Page hangs and no results in the browser, however error log grows by the three lines that I have indicated:
[21/Mar/2008:12:52:02] catastrophe (15965): CORE3260: Server crash detected (signal SIGSEGV)
[21/Mar/2008:12:52:02] info (15965): CORE3261: Crash occurred in NSAPI SAF php5_execute
[21/Mar/2008:12:52:02] info (15965): CORE3262: Crash occurred in function strlen from module /lib/libc.so.1

Stack trace:
# mdb /var/cores/webservd.victory.15928.1206115501.core
mdb: core file data for mapping at ff400000 not saved: Bad address
Loading modules: [ libumem.so.1 libc.so.1 libuutil.so.1 ld.so.1 ]
> $c
libc.so.1`strlen+0x14(286f626a, fef0093c, 3a10bfdc, feec7730, 286f626a, 0)
libldap60.so`ldap_charray_dup+0x80(feef0898, 62617365, 3a10bff0, 286f626a, 15a7bd8, feef0898)
libldap-2.3.so.0.2.26`ldap_url_dup+0x274(15a7c00, 15a9ea0, 0, 65676700, 10, 80808080)
libldap-2.3.so.0.2.26`ldap_url_duplist+0x2c(15a7c00, 0, 0, 0, 1, ac010)
libldap-2.3.so.0.2.26`ldap_create+0x354(f542ee90, 0, 0, 0, 0, 0)
libldap-2.3.so.0.2.26`ldap_initialize+0x1c(f542ef0c, 802b230, 5b13feff, 80808080, ff00, ff0000)
libphp5.so`zif_ldap_connect+0x1fc(1, 802b568, 0, 0, 1, bf2da0)
libphp5.so`zend_do_fcall_common_helper_SPEC+0x698(f542f3a8, bf2da0, d, f542f3b0, 7eaa648, d)
libphp5.so`ZEND_DO_FCALL_SPEC_CONST_HANDLER+0x110(f542f3a8, bf2da0, ffffffff, fffffff8, bf2da0, f542f3a8)
libphp5.so`execute+0x484(802af78, bf2da0, 25, fbec3f48, bf2da0, fbd1ab44)
libphp5.so`zend_execute_scripts+0x294(8, bf2da0, 0, 3, 0, f542fb10)
libphp5.so`php_execute_script+0x560(f542fb10, bf2da0, 6d, 73, bf2da0, 8000)
libphp5.so`php5_execute+0x8b0(2b54a8, ea08e0, ea0958, 2b7048, 1, 68db8800)
libns-httpd40.so`func_exec_str+0x220(0, 0, 2b54a8, ea08e0, ea0958, 0)
libns-httpd40.so`INTfunc_exec_directive+0x2a8(3cd9c, 2b54a8, ea08e0, ea0958, ea0c68, 1)
libns-httpd40.so`INTservact_service+0x37c(ff25aa80, ea08e0, 1, ea0958, 2b54a8, 3)
libns-httpd40.so`INTservact_handle_processed+0x48(ea08e0, ea0958, 29dd08, 8000000, 0, 80648)
libns-httpd40.so`__1cLHttpRequestUUnacceleratedRespond6M_v_+0x860(ea08c8, 7ebc380, ea0958, 31e7354, ff228068,
ea08e0)
libns-httpd40.so`__1cLHttpRequestNHandleRequest6MpnGnetbuf_I_i_+0x7d0(ea08c8, 7eba008, ffffffff, ea0c68, 31e7354,
ff25c878)
libns-httpd40.so`__1cNDaemonSessionDrun6M_v_+0x4bc(ea0c48, 1, ea0c68, 7eba008, 0, 1e1)
libnsprwrap.so`ThreadMain+0x1c(ea0c48, 88ef0, 0, fef29c00, ff10306c, ff264960)
libnspr4.so`_pt_root+0xd4(88ef0, fef16cb0, f542ff9c, fe8ca0bc, fe8c89ec, 0)
libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0)


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-03-22 10:28 UTC] thetaphi@php.net
I will try to reproduce this with my SJSWS 7.0u2 on Sol AMD64 with PHP 5.3 the next days.
At the moment I think, it is not fixable, because it looks like one of the typical multithread/SJSWS shared library problem. SJSWS has its own LDAP engine build into the webserver executable. Loading another one may bring problems. A second problem may be that the used LDAP shared object is not compatible with multithreading used in webserver. Be sure to enable pthreads when building it!
I recomend to use libs from /opt/csw which are installed with blastwave (www.blastwave.org), the open source repository for solaris. With these libraries I got littlest problems linking thema against SJSWS.
 [2008-03-22 10:43 UTC] thetaphi@php.net
Looking at your stack trace it looks like the problem with two different LDAP shared libs in your webserver process. libldap60.so is part of SJSWS, but libldap-2.3*.so is part of openldap. Because both libs seem to export ldap_charray_dup the earlier loaded (from SUN named libldap60.so which is part of SJSWS 7.0 @ /.../webserver7/lib/libldap60.so):

libc.so.1`strlen+0x14(286f626a, fef0093c, 3a10bfdc, feec7730, 286f626a, 0)
libldap60.so`ldap_charray_dup+0x80(feef0898, 62617365, 3a10bff0,
286f626a, 15a7bd8, feef0898)
libldap-2.3.so.0.2.26`ldap_url_dup+0x274(15a7c00, 15a9ea0, 0, 65676700, 10, 80808080)

There is nothing that I can fix about this. I recommend not to use openldap, instead use the SUN version of ldap e.g. by installing SUN development libraries.
 [2008-03-24 13:23 UTC] bdgregg at pitt dot edu
I will try to point php ldap to Sun's LDAP to see if that resolves the issue and get back to you.

Thanks for pointing me in the right direction.
 [2008-03-24 18:45 UTC] thetaphi@php.net
As far as I can remember a colleague of mine had a similar problem and told me that she cannot use OpenLDAP with iPlanet Webserver Version 4. This is now a long time ago, but if you do have success, I could ask her, how this was done.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 26 01:01:30 2024 UTC