Hello David, On Thu, Dec 17, 2009 at 01:06:28PM +1100, David N wrote: > Thats a long list of extensions, > > try adding one of them to the end of extensions.ini one by one.
> The ordering of it matters, you need to re-arrange the order in which > the extensions are loaded. You may need to play around with it until > it stops core dumping. I re-enabled at the end of extensions.ini: extension=mysqli.so extension=pdo_mysql.so extension=curl.so extension=imap.so extension=ldap.so extension=ftp.so extension=openssl.so I wasn't still able to find a working location for extension=mhash.so ... coredumps regardless of any position in extensions.ini, from top to bottom. It's - again - kind of noticeable that all of this "complicated" modules are linkend against openssl: [r...@freebsd /usr/local/lib/php/20060613]# for SO in ./*.so ; do if ldd $SO | grep -i ssl >/dev/null; then echo $SO; fi ; done ./curl.so ./ftp.so ./imap.so ./ldap.so ./mysql.so ./mysqli.so ./openssl.so ./pdo_mysql.so ... hmm, ./mysql.so was inconspicuous before *strange* Lets have a closer look on all modules depending on *ssl*: [r...@freebsd /usr/local/lib/php/20060613]# for SO in ./*.so ; do if ldd $SO | grep -i ssl >/dev/null; t en echo $SO; fi ; done | xargs ldd --------------------------------------------------- ./curl.so: libcurl.so.5 => /usr/local/lib/libcurl.so.5 (0x68190000) libidn.so.16 => /usr/local/lib/libidn.so.16 (0x68300000) libssh2.so.1 => /usr/local/lib/libssh2.so.1 (0x681d9000) libssl.so.5 => /usr/local/lib/libssl.so.5 (0x68330000) !!!! libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x68374000) !!!! libz.so.4 => /lib/libz.so.4 (0x684c4000) libc.so.7 => /lib/libc.so.7 (0x68080000) libintl.so.8 => /usr/local/lib/libintl.so.8 (0x684d6000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x684df000) libthr.so.3 => /lib/libthr.so.3 (0x685d5000) ./ftp.so: libssl.so.5 => /usr/local/lib/libssl.so.5 (0x6818d000) !!!! libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x68300000) !!!! libc.so.7 => /lib/libc.so.7 (0x68080000) libz.so.4 => /lib/libz.so.4 (0x681d1000) libthr.so.3 => /lib/libthr.so.3 (0x681e3000) ./imap.so: libssl.so.5 => /usr/local/lib/libssl.so.5 (0x68199000) !!!! libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x68300000) !!!! libc-client4.so.9 => /usr/local/lib/libc-client4.so.9 (0x68447000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x681dd000) libpam.so.4 => /usr/lib/libpam.so.4 (0x681f6000) libc.so.7 => /lib/libc.so.7 (0x68080000) libz.so.4 => /lib/libz.so.4 (0x68548000) libthr.so.3 => /lib/libthr.so.3 (0x6855a000) ./ldap.so: libldap-2.4.so.7 => /usr/local/lib/libldap-2.4.so.7 (0x6818c000) liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x681c6000) libc.so.7 => /lib/libc.so.7 (0x68080000) libssl.so.5 => /usr/local/lib/libssl.so.5 (0x68300000) !!!! libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x68344000) !!!! libz.so.4 => /lib/libz.so.4 (0x681d2000) libthr.so.3 => /lib/libthr.so.3 (0x6848b000) ./mysql.so: (***) libmysqlclient.so.15 => /usr/local/lib/mysql/libmysqlclient.so.15 (0x6818d000) libc.so.7 => /lib/libc.so.7 (0x68080000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x68300000) libm.so.5 => /lib/libm.so.5 (0x68319000) libssl.so.5 => /usr/lib/libssl.so.5 (0x6832e000) !!!! libcrypto.so.5 => /lib/libcrypto.so.5 (0x6836f000) !!!! libz.so.4 => /lib/libz.so.4 (0x684c8000) ./mysqli.so: libmysqlclient.so.15 => /usr/local/lib/mysql/libmysqlclient.so.15 (0x6819a000) libz.so.4 => /lib/libz.so.4 (0x68300000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x68312000) libm.so.5 => /lib/libm.so.5 (0x6832b000) libssl.so.5 => /usr/local/lib/libssl.so.5 (0x68340000) !!!! libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x6838d000) !!!! libc.so.7 => /lib/libc.so.7 (0x68080000) libthr.so.3 => /lib/libthr.so.3 (0x684d4000) ./openssl.so: libssl.so.5 => /usr/local/lib/libssl.so.5 (0x68196000) !!!! libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x68300000) !!!! libc.so.7 => /lib/libc.so.7 (0x68080000) libz.so.4 => /lib/libz.so.4 (0x681da000) libthr.so.3 => /lib/libthr.so.3 (0x68447000) ./pdo_mysql.so: libmysqlclient.so.15 => /usr/local/lib/mysql/libmysqlclient.so.15 (0x68189000) libz.so.4 => /lib/libz.so.4 (0x681ea000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x68300000) libm.so.5 => /lib/libm.so.5 (0x68319000) libssl.so.5 => /usr/local/lib/libssl.so.5 (0x6832e000) !!!! libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x6837b000) !!!! libc.so.7 => /lib/libc.so.7 (0x68080000) libthr.so.3 => /lib/libthr.so.3 (0x684c2000) --------------------------------------------------- All modules but mysql.so will load libssl.so.5 from /usr/local/lib/libssl.so.5, mysql.so is linked to libssl.so.5 => /usr/lib/libssl.so.5 This is kind of interesting! If disable(!) ./mysql.so from extensions.ini, php will segfault again! So what seems to happen? libssl.so.5 get loaded by mysql.so and won't get loaded by one of the following modules, which are "hard-linked" to /usr/local/lib/libssl.so.5 Question: how does "mysql.so" link against another libssl.so.5 than "mysqli.so" would? Is this the RPATH-thing? Am I right with my assumption about mysql.so links to /usr/lib/libssl.so.5 and therefore any other module linking to libssl.so.5 won't link to /usr/local/lib/libssl.so.5 (because it's already provided/loaded by /usr/lib/libssl.so.5)? If so why does /usr/local/lib/libssl.so.5 segfault? mhash isn't explained here. This seems to be another strange thing. I'd appreciate any help and background information on this "libssl.so.5/libcrypto.so.5 - thing". With best regards Raphael -- Raphael Becker <r...@uugrn.org> http://rabe.uugrn.org/ https://www.xing.com/profile/Raphael_Becker GnuPG: E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .........|.........|.........|.........|.........|.........|.........|..
pgp9kItCZvx2T.pgp
Description: PGP signature