openldap-bugs July 2009

openldap-bugs@openldap.org

49 participants
166 discussions

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 23 Jul '09

23 Jul '09

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. 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. 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. >

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by hyc＠symas.com 23 Jul '09

23 Jul '09

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/

1 0

ITS#6226
by masarati＠aero.polimi.it 23 Jul '09

23 Jul '09

Duplicate of ITS#5941? p.

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 23 Jul '09

23 Jul '09

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). Thanks, Steve

1 0

(ITS#6200)
by imf＠u.washington.edu 23 Jul '09

23 Jul '09

The changes made to 2.4.17 seem to have fixed the crashes in the caching module. Thanks for that. We still are able to crash 2.4.17, however. It only happens after a heavy load is placed on the producer for >24 hours continuous. Unfortunately, we've not been able to get good tracebacks. They all look like this, (gdb) where #0 0x00869410 in __kernel_vsyscall () #1 0x00390d80 in raise () from /lib/libc.so.6 #2 0x00392691 in abort () from /lib/libc.so.6 #3 0x0038a1fb in __assert_fail () from /lib/libc.so.6 #4 0x0808d532 in malloc () #5 0x0822c93f in ?? () #6 0x0822c933 in ?? () #7 0x00000039 in ?? () #8 0x0822c908 in ?? () #9 0x00000000 in ?? () The producer slowly grows its memory footprint. I can't tell if it's from just normal operations or memory leaks. I suspect it's a little of both. The end result, as you can see from the core above, is that there's likely some corrupted (or unfreed) memory somewhere. Sorry I can't nail it down further. The load profile that we placed on the server is documented in my prior report. See above. --- Tracy Stenvik University Computing Services 354843. University of Washington email: imf(a)u.washington.edu voice: (206) 685-3344

1 0

(ITS#6226) Double free() with translucent+rwm
by test.007＠seznam.cz 23 Jul '09

23 Jul '09

Full_Name: Test Seven Version: 2.4.17 OS: Linux/Windows URL: Submission from: (NULL) (195.113.184.10) Have sample setup with bdb database, add the following to the bottom of slapd.conf: overlay translucent overlay rwm uri "ldap://127.6.6.6/" # (the server 127.6.6.6 must not exist) Run any search query against the server (with correct credentials). Slapd tries to contact the remote server, then it properly returns an error (32, or 52...) to the client, but then it aborts. Variations: a) Change .conf: uri "ldap://something.that.resolves.but.doesnt.respond" b) Add to the bottom of .conf: idassert-bind binddn="cn=doesnt,ou=matter" credentials=secret The variations return different errors to the client, and may crash elsewhere. Problem in the code (for Variation a): ldap_back_dobind_int() calls send_ldap_result(op,rs), which eventually free-s ((*op).o_request).oq_search.rs_filterstr.bv_val; the same string is later free-d after return to translucent_search() after being retrieved from local variable "fbv".

1 0

(ITS#6225) GSSAPI support for client library (fixes)
by mimir＠samba.org 22 Jul '09

22 Jul '09

Full_Name: Rafal Szczesniak Version: Stable (2.4.16) OS: GNU/Linux URL: http://www.samba.org/~mimir/gssapi-bugfix.diff Submission from: (NULL) (67.51.54.234) This is a bugfix patch for OpenLDAP's gssapi support.

1 0

Re: (ITS#6223) [patch] snprint() fix in guess_service_principal()
by jerry＠plainjoe.org 22 Jul '09

22 Jul '09

Correction to the URL. Should be: ftp://ftp.openldap.org/incoming/openldap-2.4.16-guess_service_principal.diff

1 0

(ITS#6224) [patch] snprint() fix in guess_service_principal()
by jerry＠plainjoe.org 22 Jul '09

22 Jul '09

Full_Name: Gerald Carter Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/openldap-2.4.6-guess_service_principal.diff Submission from: (NULL) (71.12.192.77) There's an off by one error in guess_service_principal() when copying and checking the return value from snprintf(). Trivial patch is included.

1 0

(ITS#6223) [patch] snprint() fix in guess_service_principal()
by jerry＠plainjoe.org 22 Jul '09

22 Jul '09

1 0

← Newer
1
2
3
4
5
6
7
8
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2009