openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#5840) bdb_online_index and shutdown
by ando＠sys-net.it 08 Dec '08

08 Dec '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> - the index should be invalidated >> - slapd, at the next manual startup, should complain about the need to >> run slapindex first. > > If it knows enough to complain, why not restart the indexing task? There should be an option in doing that. In fact, I suspect running slapindex -q can be much more efficient than letting slapd index while serving without index. Of course, slapd cannot serve while slapindex'ing, so I think human intervention is needed to determine what's most appropriate on a case by case basis. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5840) bdb_online_index and shutdown
by h.b.furuseth＠usit.uio.no 08 Dec '08

08 Dec '08

ando(a)sys-net.it writes: > - the index should be invalidated > - slapd, at the next manual startup, should complain about the need to > run slapindex first. If it knows enough to complain, why not restart the indexing task? -- Hallvard

1 0

Re: slapd hanging upon shutdown (ITS#5841)
by h.b.furuseth＠usit.uio.no 08 Dec '08

08 Dec '08

Yes, this sounds familiar. I guess I mentioned it but didn't have time to check it. The offending if() comes from tpool.c rev 1.81, which was apparently a wrong fix to ITS#5194. rev 1.82 was the right fix. (Except I'm not so sure it was the _complete_ fix - might need to lock ldap_pvt_thread_pool_mutex while changing or even accessing *tpool, or something like that...) Anyway, the patch looks correct to me, undoing rev 1.81. The current code is clear enough in retrospect - a thread pool pause in halts pool_destroy() since pool_resume() doesn't broadcast - and thus a cn=config update (or access?) aborts slapd shutdown:-( -- Hallvard

1 0

Re: slapd hanging upon shutdown (ITS#5841)
by rhafer＠suse.de 08 Dec '08

08 Dec '08

Am Freitag 05 Dezember 2008 09:07:53 schrieb Howard Chu: > I seem to recall there was a race such that the condvar had already been > destroyed before it got here. Don't remember the details at the moment, and > not in a position to look it up either, but perhaps trawling thru -devel > will reveal it. Sounds like something Hallvard brought up in the past. I failed to see how such a race could happen with the current code in HEAD. The condvar is only destroyed after ltp_open_count decreased to 0. There might have been such problems when _thread_pool_destroy just used a simple if statement (instead of a while loop) for checking ltp_open_count. But that has been changed long ago, as part of ITS#4943. Maybe Hallvard can shed some light on this. -- regards, Ralf

1 0

(ITS#5850) adding a new server to ammr pool switches mirror-mode off
by ando＠sys-net.it 06 Dec '08

06 Dec '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando When adding a new value to olcSyncrepl to a member of a mmr pool, in order to configure a new pool member, olcMirrorMode is automatically reset since the URI of the new olcSyncrepl differs from the olcServerID. A workaround consists in explicitly reseting olcMirrorMode to TRUE within the same modify operation. p.

1 0

Re: (ITS#5849) memory leak when using client certificates
by dhawes＠vt.edu 05 Dec '08

05 Dec '08

dhawes(a)vt.edu wrote: > dhawes(a)vt.edu wrote: >> Full_Name: David Hawes >> Version: 2.4.13 >> OS: Debian GNU/Linux 4.0 >> URL: >> Submission from: (NULL) (98.117.88.57) >> >> >> As outlined at: >> >> http://www.openldap.org/lists/openldap-software/200811/msg00136.html >> >> OpenLDAP 2.4 leaks memory when TLS client certificates are used. Running slapd >> under valgrind yields the following: >> >> ==13311== 4,906 (92 direct, 4,814 indirect) bytes in 1 blocks are >> definitely lost in loss record 19 of 23 >> ==13311== at 0x401D898: malloc (vg_replace_malloc.c:207) >> ==13311== by 0x41FCCC4: default_malloc_ex (mem.c:79) >> ==13311== by 0x41FD33F: CRYPTO_malloc (mem.c:304) >> ==13311== by 0x428CA65: asn1_item_ex_combine_new (tasn_new.c:191) >> ==13311== by 0x428C79C: ASN1_item_ex_new (tasn_new.c:85) >> ==13311== by 0x428ECAA: ASN1_item_ex_d2i (tasn_dec.c:399) >> ==13311== by 0x428E5F9: ASN1_item_d2i (tasn_dec.c:134) >> ==13311== by 0x4286A57: d2i_X509 (x_x509.c:136) >> ==13311== by 0x4194F26: ssl3_get_client_certificate (s3_srvr.c:2521) >> ==13311== by 0x4191897: ssl3_accept (s3_srvr.c:462) >> ==13311== by 0x41AD930: SSL_accept (ssl_lib.c:867) >> ==13311== by 0x815D00E: ldap_pvt_tls_accept (tls.c:1594) >> ==13311== by 0x8076926: connection_read_thread (connection.c:1286) >> ==13311== by 0x813CEE5: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==13311== by 0x415823F: start_thread (in >> /lib/tls/i686/cmov/libpthread-2.3.6.so) >> ==13311== by 0x43ED49D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so) >> >> Philip Guenther notes: >> >> In 2.4.x, tls_get_cert_dn() leaks a reference to the client's X509 cert: >> the call to SSL_get_peer_certificate() in tls_get_cert() increments the >> reference count on the cert and it never gets decremented by a call to >> X509_free(). Simply adding the call there might not be safe, depending on >> whether the berval that tls_get_cert_dn() sets up relies on the underlying >> X509 to stay valid for longer than this chain of calls, as the X509 may be >> invalidated by a rehandshake. > > Calling X509_free(x) before the return statement in tls_get_cert_dn() > does fix the memory leak, though I do not know if this is proper, as > Philip noted. My apologies for not checking the ITS before sending that message. The fix in HEAD works.

1 0

Re: (ITS#5849) memory leak when using client certificates
by dhawes＠vt.edu 05 Dec '08

05 Dec '08

dhawes(a)vt.edu wrote: > Full_Name: David Hawes > Version: 2.4.13 > OS: Debian GNU/Linux 4.0 > URL: > Submission from: (NULL) (98.117.88.57) > > > As outlined at: > > http://www.openldap.org/lists/openldap-software/200811/msg00136.html > > OpenLDAP 2.4 leaks memory when TLS client certificates are used. Running slapd > under valgrind yields the following: > > ==13311== 4,906 (92 direct, 4,814 indirect) bytes in 1 blocks are > definitely lost in loss record 19 of 23 > ==13311== at 0x401D898: malloc (vg_replace_malloc.c:207) > ==13311== by 0x41FCCC4: default_malloc_ex (mem.c:79) > ==13311== by 0x41FD33F: CRYPTO_malloc (mem.c:304) > ==13311== by 0x428CA65: asn1_item_ex_combine_new (tasn_new.c:191) > ==13311== by 0x428C79C: ASN1_item_ex_new (tasn_new.c:85) > ==13311== by 0x428ECAA: ASN1_item_ex_d2i (tasn_dec.c:399) > ==13311== by 0x428E5F9: ASN1_item_d2i (tasn_dec.c:134) > ==13311== by 0x4286A57: d2i_X509 (x_x509.c:136) > ==13311== by 0x4194F26: ssl3_get_client_certificate (s3_srvr.c:2521) > ==13311== by 0x4191897: ssl3_accept (s3_srvr.c:462) > ==13311== by 0x41AD930: SSL_accept (ssl_lib.c:867) > ==13311== by 0x815D00E: ldap_pvt_tls_accept (tls.c:1594) > ==13311== by 0x8076926: connection_read_thread (connection.c:1286) > ==13311== by 0x813CEE5: ldap_int_thread_pool_wrapper (tpool.c:663) > ==13311== by 0x415823F: start_thread (in > /lib/tls/i686/cmov/libpthread-2.3.6.so) > ==13311== by 0x43ED49D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so) > > Philip Guenther notes: > > In 2.4.x, tls_get_cert_dn() leaks a reference to the client's X509 cert: > the call to SSL_get_peer_certificate() in tls_get_cert() increments the > reference count on the cert and it never gets decremented by a call to > X509_free(). Simply adding the call there might not be safe, depending on > whether the berval that tls_get_cert_dn() sets up relies on the underlying > X509 to stay valid for longer than this chain of calls, as the X509 may be > invalidated by a rehandshake. Calling X509_free(x) before the return statement in tls_get_cert_dn() does fix the memory leak, though I do not know if this is proper, as Philip noted.

1 0

Re: add option for setting minimum TLS/SSL protocol (ITS#5655)
by guenther＠sendmail.com 04 Dec '08

04 Dec '08

I could have sworn I had uploaded the revised version of the patch back in August after some cleaning by Kurt, but have no way of confirming it. So I've uploaded it again as guenther-20081204.patch.

1 0

(ITS#5849) memory leak when using client certificates
by dhawes＠vt.edu 04 Dec '08

04 Dec '08

Full_Name: David Hawes Version: 2.4.13 OS: Debian GNU/Linux 4.0 URL: Submission from: (NULL) (98.117.88.57) As outlined at: http://www.openldap.org/lists/openldap-software/200811/msg00136.html OpenLDAP 2.4 leaks memory when TLS client certificates are used. Running slapd under valgrind yields the following: ==13311== 4,906 (92 direct, 4,814 indirect) bytes in 1 blocks are definitely lost in loss record 19 of 23 ==13311== at 0x401D898: malloc (vg_replace_malloc.c:207) ==13311== by 0x41FCCC4: default_malloc_ex (mem.c:79) ==13311== by 0x41FD33F: CRYPTO_malloc (mem.c:304) ==13311== by 0x428CA65: asn1_item_ex_combine_new (tasn_new.c:191) ==13311== by 0x428C79C: ASN1_item_ex_new (tasn_new.c:85) ==13311== by 0x428ECAA: ASN1_item_ex_d2i (tasn_dec.c:399) ==13311== by 0x428E5F9: ASN1_item_d2i (tasn_dec.c:134) ==13311== by 0x4286A57: d2i_X509 (x_x509.c:136) ==13311== by 0x4194F26: ssl3_get_client_certificate (s3_srvr.c:2521) ==13311== by 0x4191897: ssl3_accept (s3_srvr.c:462) ==13311== by 0x41AD930: SSL_accept (ssl_lib.c:867) ==13311== by 0x815D00E: ldap_pvt_tls_accept (tls.c:1594) ==13311== by 0x8076926: connection_read_thread (connection.c:1286) ==13311== by 0x813CEE5: ldap_int_thread_pool_wrapper (tpool.c:663) ==13311== by 0x415823F: start_thread (in /lib/tls/i686/cmov/libpthread-2.3.6.so) ==13311== by 0x43ED49D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so) Philip Guenther notes: In 2.4.x, tls_get_cert_dn() leaks a reference to the client's X509 cert: the call to SSL_get_peer_certificate() in tls_get_cert() increments the reference count on the cert and it never gets decremented by a call to X509_free(). Simply adding the call there might not be safe, depending on whether the berval that tls_get_cert_dn() sets up relies on the underlying X509 to stay valid for longer than this chain of calls, as the X509 may be invalidated by a rehandshake.

1 0

ITS#5847 back-ndb indexing
by hyc＠symas.com 04 Dec '08

04 Dec '08

This is a known limitation in the current version of back-ndb. (See this message for further details http://www.openldap.org/lists/openldap-devel/200810/msg00094.html ) Note that back-ndb is marked "Experimental". You should not use it unless you're prepared to write fixes for it.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs