On Wed, 25 Aug 2010, jan.gr...@bristol.ac.uk wrote: > On Wed, 25 Aug 2010, jan.gr...@bristol.ac.uk wrote: > > [on Net::LDAP segfaulting...] > > > In other words: this bug appears to only get tickled inside RT for some > > reason. > > > > I take it that RT (or RT::Authen::ExternalAuth) don't muck around with > > internal SSLeay settings that might cause this, in a way that I've missed? > > Looks like my guess was almost right. We're (for better or worse) an > oracle shop. The backtrace looks like this: > > > [[[ > % sudo -u www-data gdb --args perl ./try-ldap-canonicalize.pl > (gdb) run > Starting program: /usr/bin/perl ./try-ldap-canonicalize.pl > [Thread debugging using libthread_db enabled] > > Program received signal SIGSEGV, Segmentation fault. > 0xb6cb51bb in ?? () from /usr/lib/oracle/10.2.0.4/client/lib/libnnz10.so > (gdb) bt > #0 0xb6cb51bb in ?? () from > /usr/lib/oracle/10.2.0.4/client/lib/libnnz10.so > #1 0xb6cb48be in ?? () from > /usr/lib/oracle/10.2.0.4/client/lib/libnnz10.so > #2 0xb2255bfc in BN_MONT_CTX_set () from > /usr/lib/i686/cmov/libcrypto.so.0.9.8 > #3 0xb2255ee9 in BN_MONT_CTX_set_locked () > from /usr/lib/i686/cmov/libcrypto.so.0.9.8 > #4 0xb226c8f4 in ?? () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 > #5 0xb226d2ae in RSA_public_encrypt () from > /usr/lib/i686/cmov/libcrypto.so.0.9.8 > #6 0xb2349140 in ssl3_send_client_key_exchange () > from /usr/lib/i686/cmov/libssl.so.0.9.8 > #7 0xb234cb4b in ssl3_connect () from /usr/lib/i686/cmov/libssl.so.0.9.8 > #8 0xb23626ea in SSL_connect () from /usr/lib/i686/cmov/libssl.so.0.9.8 > #9 0xb23540e3 in ssl23_connect () from /usr/lib/i686/cmov/libssl.so.0.9.8 > #10 0xb23626ea in SSL_connect () from /usr/lib/i686/cmov/libssl.so.0.9.8 > #11 0xb23c4605 in XS_Net__SSLeay_connect () > from /usr/lib/perl5/auto/Net/SSLeay/SSLeay.so > #12 0x080d5d7b in Perl_pp_entersub () > #13 0x080d4358 in Perl_runops_standard () > #14 0x08079355 in perl_run () > #15 0x080642fd in main () > ]]] > > So the question is, has anyone seen this and do they have a workaround? (I > ask here because that's where the original question was. If my esteemed > colleague Dr. Google comes up with an answer, I'll follow up.)
Okay. Looking at it, the suggestion is (since this is a symbol conflict in the oracle client library) to set LD_PRELOAD=/usr/lib/libcrypto.{version} to force that to load first. Whether that'll kill the oracle client library at the same time, I'm about to find out. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ I am now available for general use under a modified BSD licence. RT Training in Washington DC, USA on Oct 25 & 26 2010 Last one this year -- Learn how to get the most out of RT!