#37716 [NEW]: PHP + OpenLDAP crash

From: john dot cecere at sun dot com Operating system: Solaris 10 PHP version: 5.1.4 PHP Bug Type: Reproducible crash Bug description: PHP + OpenLDAP crash Description: ------------ When I build PHP 5.1.4 with OpenLDAP (2.3.23) support in 64-bit mode in Solaris 10 using SunStudio (10 or 11) on SPARC (I haven't tested AMD64 yet), PHP core dumps when I try to run this program: <?php print '<P>PHP works!!!</P>'; $ds=ldap_connect("ldap-server"); ?> (ldap-server is the name of a valid ldap server) # php tst.php <P>PHP works!!!</P>Segmentation Fault(coredump) # mdb in Solaris reveals this as the last call in the stacktrace: libldap-2.3.so.0.2.11`ldap_unbind_ext+0x74(8c75d0, 0, 0, 0, 0, 0) One might conclude that this is a problem with OpenLDAP. However, if I do nothing else (i.e. use the same SunStudio-built OpenLDAP) but rebuild PHP in 64-bit mode using gcc (3.4.3), the problem goes away. My general conclusion is that this is either a compiler bug or a PHP bug. This happens whether I build LDAP support directly into PHP or as an extension. Changes to how I build OpenLDAP have no effect on this problem one way or the other. I've trimmed the parameters down to remove irrelevant variables for the purpose of simplifying this bug report. This may or may not be a PHP bug, but it's worth investigating. I will also pursue the course of opening a bug against the C compiler and attempt to keep this bug updated with the results. The versions of software used in building PHP with parameters used to build them: Berkeley DB 4.4.20: CC="/opt/SUNWspro/bin/cc" CFLAGS="-xarch=v9" export CC CFLAGS cd build_unix ../dist/configure libxml2 2.6.23: CC="/opt/SUNWspro/bin/cc" CFLAGS="-xarch=v9" export CC CFLAGS ./configure --without-python OpenLDAP 2.3.23: CC="/opt/SUNWspro/bin/cc" CFLAGS="-xarch=v9" CPPFLAGS="-I/usr/local/BerkeleyDB.4.4/include" LDFLAGS="-L/usr/local/BerkeleyDB.4.4/lib -R/usr/local/BerkeleyDB.4.4/lib" export CC CFLAGS CPPFLAGS LDFLAGS ./configure PHP 5.1.4: CC="/opt/SUNWspro/bin/cc" CFLAGS="-xarch=v9" CPPFLAGS="-I/usr/local/BerkeleyDB.4.4/include -I/usr/local/include/libxml2" LDFLAGS="-L/usr/local/BerkeleyDB.4.4/lib -R/usr/local/BerkeleyDB.4.4/lib" export CC CFLAGS CPPFLAGS LDFLAGS ./configure \ --with-libxml-dir=/usr/local \ --enable-dba=/usr/local \ --with-db4=/usr/local/BerkeleyDB.4.4 \ --with-ldap=/usr/local Reproduce code: --------------- Contents of tst.php: <?php print '<P>PHP works!!!</P>'; $ds=ldap_connect("ldap-server"); ?> Expected result: ---------------- I expected it not to core dump. Actual result: -------------- Stack trace of core file generated by php using mdb utility in Solaris 10: # file core core: ELF 64-bit MSB core file SPARCV9 Version 1, from 'php' # mdb core Loading modules: [ libc.so.1 ld.so.1 ] > $c libldap-2.3.so.0.2.11`ldap_unbind_ext+0x74(8c75d0, 0, 0, 0, 0, 0) libldap-2.3.so.0.2.11`ldap_unbind_s+0x10(8c75d0, 10084b330, 10088d260, ffffffff7d5f2df0, 2, 10072eaa8) ldap.so`_close_ldap_link+0x24(1008c0dc8, 17, ffffffff7fffec88, 0, 1008c7878, 1008c0c88) 0x10045dcbc(1008c0dc8, 1008c0dc8, 1008c7808, 0, 0, 1008c0dc8) 0x1004594d0(100735be0, 0, 0, 4, 1, 1008c7808) 0x10045d7b4(4, ffffffff7ffff7d8, 0, 0, 0, 0) 0x1004418d0(1008c0d88, ffffffff7d9f3f38, 100040670, ffffffff7d75a0a0, ffffffff7a7014f8, 1) 0x100426208(1008c0d88, 1003d4ca8, 40, 8, 1, 1008c0590) 0x1004286bc(1008c7890, 10020ded0, 10, 0, 1, 0) 0x100459870(100735a88, 1008c7878, 21d8, ffffffff7d5f2df0, 2, 10072eaa8) 0x100459b00(100735a88, 100427298, 0, 0, 1008c7878, 0) 0x100427aa0(100735b18, ffffffff7ffff4a0, 0, 0, 0, 0) 0x10044645c(100735b18, ffffffff7ffff5c0, 0, 0, 0, 0) php_request_shutdown+0x4b4(0, ffffffff7ffff7d8, 0, 0, 0, 0) 0x1004f76e8(2, ffffffff7ffff9a8, ffffffff7ffff9c0, ffffffff7d4491e8, ffffffff7f400140, ffffffff7f400180) _start+0x17c(0, 0, 0, 0, 0, 0) -- Edit bug report at http://bugs.php.net/?id=37716&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37716&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37716&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37716&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37716&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37716&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37716&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=37716&r=needscript Try newer version: http://bugs.php.net/fix.php?id=37716&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37716&r=support Expected behavior: http://bugs.php.net/fix.php?id=37716&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37716&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37716&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37716&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37716&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37716&r=dst IIS Stability: http://bugs.php.net/fix.php?id=37716&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37716&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37716&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37716&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=37716&r=mysqlcfg