[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback

Steve Paras-Charlton wrote:
> Thanks, that was sooo helpful.
> What I'm trying to do is port your software package to a platform where
> it obviously fails to work properly using the vendor's supplied SSL
> libraries, and you're giving me a PFO.

The ITS is for tracking problems in the actual OpenLDAP code base. Since 
you're not reporting an actual issue in OpenLDAP code, this is the wrong forum 
for this discussion.

You can get help on interoperability issues elsewhere, e.g. the 
openldap-technical mailing list.

> So now I get to go to IBM and say "your library is broken but I can't
> tell you how/why" (gee... I wonder how that call will go) or abandon
> open source and install their LDAP server package (which is what they'll
> tell me to do anyhow).
> Now you might tell me (as you've already implied) to compile my own SSL
> libraries, which I may try, but doing so opens me up to a world of
> interop issues as IBM tends to compile their tools with links to
> specific versions of shared libraries (I've been there and done that in
> AIX this year once already).

> Do I sound frustrated yet? Cause I am...
> Sorry to anyone else who reads this rant.

You obviously have to ask the right questions to the right people who can 
actually help you. We can't fix your OpenSSL build for you.
> Steve
> On Thu, 2009-07-23 at 14:15 -0700, Howard Chu wrote:
>> Steve Paras-Charlton wrote:
>>> I tried re-compiling with CC="gcc -g" and got the following backtrace
>>> from gdb:
>>> Program received signal SIGSEGV, Segmentation fault.
>>> [Switching to Thread 1]
>>> 0xd26d07d0 in SSL_CTX_set_info_callback ()
>>> from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2)
>>> (gdb) bt
>>> #0  0xd26d07d0 in SSL_CTX_set_info_callback ()
>>> from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2)
>>> #1  0xd26cdedc in tlso_ctx_init (lo=0x200c087c, lt=0x2ff22970,
>>> is_server=1) at tls_o.c:320
>>> #2  0xd26ca50c in ldap_int_tls_init_ctx (lo=0x200c087c, is_server=1) at
>>> tls2.c:245
>>> #3  0xd26cc1cc in ldap_pvt_tls_set_option (ld=0x200c0878, option=24591,
>>> arg=0x2ff22ae8) at tls2.c:800
>>> #4  0x10001f90 in main (argc=9, argv=0x2ff22b94) at main.c:826
>>> This one seems much more useful from a debugging perspective.
>>> I noticed that the configure program has some options along the lines of
>>> "--with-PIC" which defaults to "both PIC and non-PIC".  Could I use this
>>> to help debug the issue perhaps?  How would I use it (not sure what
>>> options it takes).
>> This trace is the kind that we would normally look for, yes. But the crash is
>> in an OpenSSL function, and you haven't got debug symbols for that since you
>> haven't recompiled that yet. Anyway, it still has nothing to do with OpenLDAP,
>> your OpenSSL library is broken. Since this is not an OpenLDAP bug this ITS
>> will be closed.

   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/