ID: 37716 User updated by: john dot cecere at sun dot com Reported By: john dot cecere at sun dot com Status: Bogus Bug Type: Reproducible crash Operating System: Solaris 10 PHP Version: 5.1.4 New Comment:
Interesting. I was able to make the problem go away by adding -xdepend (my previous compilation used no optimizations). The problem also went away when I used -fast (which is a macro that includes -xdepend). I will log a bug on SunStudio and see where it goes. Previous Comments: ------------------------------------------------------------------------ [2006-06-14 16:58:52] [EMAIL PROTECTED] Quick search revealed that there really has been problems with the SunStudio. (especially with -xdepend it seems) ------------------------------------------------------------------------ [2006-06-08 13:47:19] john dot cecere at sun dot com I've done a little digging on this problem and found out a few things. First of all, this only affects SPARC. The AMD64 version that I built didn't have this problem. I also tried debugging this via dbx. Here's the result: [EMAIL PROTECTED] ([EMAIL PROTECTED]) signal SEGV (no mapping at the fault address) in ldap_unbind_ext at line 49 in file "unbind.c" 49 assert( LDAP_VALID( ld ) ); (dbx) where current thread: [EMAIL PROTECTED] =>[1] ldap_unbind_ext(ld = 0x9fdf00, sctrls = (nil), cctrls = (nil)), line 49 in "unbind.c" [2] ldap_unbind_s(ld = 0x9fdf00), line 210 in "unbind.c" [3] _close_ldap_link(rsrc = 0x1009f3238), line 194 in "ldap.c" [4] list_entry_destructor(ptr = 0x1009f3238), line 184 in "zend_list.c" [5] zend_hash_del_key_or_index(ht = 0x1008a6ae0, arKey = (nil), nKeyLength = 0, h = 1U, flag = 1), line 492 in "zend_hash.c" [6] _zend_list_delete(id = 1), line 58 in "zend_list.c" [7] _zval_dtor_func(zvalue = 0x1009f31f8), line 60 in "zend_variables.c" [8] _zval_dtor(zvalue = 0x1009f31f8), line 35 in "zend_variables.h" [9] _zval_ptr_dtor(zval_ptr = 0x1009fc710), line 395 in "zend_execute_API.c" [10] zend_hash_apply_deleter(ht = 0x1008a6988, p = 0x1009fc6f8), line 576 in "zend_hash.c" [11] zend_hash_graceful_reverse_destroy(ht = 0x1008a6988), line 642 in "zend_hash.c" [12] shutdown_executor(), line 221 in "zend_execute_API.c" [13] zend_deactivate(), line 854 in "zend.c" [14] php_request_shutdown(0x0, 0x2000, 0x130814, 0xffffffff7d5b27b8, 0xffffffff7d6e4000, 0x1009fd080), at 0x1004dccec [15] main(argc = 2, argv = 0xffffffff7ffff9f8), line 1666 in "cgi_main.c" I put a stop in list_entry_destructor (btw this wasn't arbitrary. I'm just trying to make this story as short as I can) and took a look at what was happening to ld: (dbx) print *ld *ld = { list_dtor = (nil) plist_dtor = (nil) list_dtor_ex = 0x100276a80 = &`php`ldap.c`_close_ldap_link(zend_rsrc_list_entry *rsrc) plist_dtor_ex = (nil) type_name = 0x100887b68 "ldap link" module_number = 15 resource_id = 18 type = '\002' } (dbx) step [EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in list_entry_destructor at line 184 in file "zend_list.c" 184 ld->list_dtor_ex(le TSRMLS_CC); (dbx) print *ld *ld = { list_dtor = (nil) plist_dtor = (nil) list_dtor_ex = 0x100276a80 = &`php`ldap.c`_close_ldap_link(zend_rsrc_list_entry *rsrc) plist_dtor_ex = (nil) type_name = 0x100887b68 "ldap link" module_number = 15 resource_id = 18 type = '\002' } (dbx) step [EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in _close_ldap_link at line 192 in file "ldap.c" 192 ldap_linkdata *ld = (ldap_linkdata *)rsrc->ptr; (dbx) print *ld dbx: cannot access address 0x12 (dbx) step [EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in _close_ldap_link at line 194 in file "ldap.c" 194 ldap_unbind_s(ld->link); (dbx) print *ld *ld = { link = 0x9fdf00 rebindproc = (nil) } (dbx) step [EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in ldap_unbind_s at line 210 in file "unbind.c" 210 return( ldap_unbind_ext( ld, NULL, NULL ) ); (dbx) print *ld dbx: cannot access address 0x9fdf00 (dbx) My guess is that the address 0x9fdf00 is supposed to point to an LDAP structure, but it doesn't for some reason. I'll leave this to someone else to figure out why. It looks like something is getting stepped on in Zend's hash tables. Since I only had this problem in 64-bit SPARC, I decided to play around with some of the compiler optimizations. I found out that adding -xdepend to CFLAGS and rebuilding PHP makes this problem go away. ------------------------------------------------------------------------ [2006-06-06 18:11:24] john dot cecere at sun dot com 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 this bug report at http://bugs.php.net/?id=37716&edit=1