openldap-bugs October 2011

openldap-bugs@openldap.org

27 participants
41 discussions

Re: (ITS#7065) changeType: modify "replace/delete" trick causes segmentation fault in cn=config
by h.b.furuseth＠usit.uio.no 23 Oct '11

23 Oct '11

Reproduced in master by trying to change olcSaslHost: config_modify_internal() does this with a == NULL: 5827 a->a_flags |= SLAP_ATTR_IXADD; jeffreyc(a)ucsc.edu writes: > To guarantee the removal of an attribute when I don't know if the attribute > exists already or not I often employ the following LDIF: > > ============== > dn: cn=config > changeType: modify > replace: attrToDelete > attrToDelete: dummy > - > delete: attrToDelete > ============== You can use this instead: dn: cn=config changeType: modify replace: attrToDelete - -- Hallvard

1 0

Re: (ITS#6763) slapd does not clear sr_entry/ctrls on sizelimit/busy
by h.b.furuseth＠usit.uio.no 23 Oct '11

23 Oct '11

I wrote: > slap_send_search_entry() does not always free/release the entry and > call slap_cleanup_play() on error. > > slap_send_search_reference() calls slap_cleanup_play(), but does not > always free/release the entry. > > I expect both functions always should do both, but don't know enough > myself to be sure. > > Resolution needed for ITS#6758 (SlapReply) - who should be responsible > for clearing out the entry? Nobody else were picking this up, and it was making back-monitor hang in ITS#7053. So I've made result.c always clean up. The code is still inconsistent: slap_send_search_entry() may flush the entry either before or after slap_cleanup_play(), while slap_send_search_reference() always flushes first. If anyone feels that should be regularized, feel free. I'm leaving it alone for now. -- Hallvard

1 0

Re: (ITS#7053) back-monitor blocks
by h.b.furuseth＠usit.uio.no 23 Oct '11

23 Oct '11

Fixed in master, dup of ITS#6763. Thank you for the simple test case. The '-z 10' identified the problem. slap_send_search_entry() did not call rs_flush_entry() when sizeLimitExceeded. I have not traced exactly what happened, but I expect this means some back-monitor entry kept its locks. -- Hallvard

1 0

Re: (ITS#7053) back-monitor blocks
by michael＠stroeder.com 22 Oct '11

22 Oct '11

This is still an issue also in HEAD.

1 0

Re: (ITS#7053) back-monitor blocks
by michael＠stroeder.com 22 Oct '11

22 Oct '11

But just for the records... Finally I managed to reproduce this with OpenLDAP's ldapsearch command-line tool. The bound entity needs read access to cn=monitor. Try this more than one time: ldapsearch -x -H ldapi://%2Ftmp%2Fopenldap-socket -b "cn=monitor" -z 10 -s one "(objectClass=*)" cn objectclass Do this as many times as you have threads configured and slapd becomes completely unresponsive and has to be stopped by kill -9. This was tested on my local install under openSUSE 11.4 but also on an installation running on HP-UX (64 bit build). Both running 2.4.26. Ciao, Michael.

1 0

Re: (ITS#7070) test058-syncrepl-asymmetric failed for hdb
by quanah＠zimbra.com 21 Oct '11

21 Oct '11

--On Friday, October 21, 2011 6:34 PM +0000 michael(a)stroeder.com wrote: > hyc(a)symas.com wrote: >> There's no evidence of an OpenLDAP bug here. All we can see from the >> testrun/slapd.1.log is that it took 15 seconds for slap_sasl_init to >> complete, which was long enough for the initial startup check to time >> out. You need to check your system to see why SASL took so long to >> initialize, most likely a DNS failure or some other transient issue. > > Hmm, this was with a local build of cyrus-sasl 2.1.25 which seg faulted on > GSSAPI in another test. I will retry with cyrus-sasl package shipped with > openSUSE 11.4. There was a patch posted to the cyrus-sasl list the other day for issues with the gssapi plugin in 2.1.25. It's working fine for me once it is fixed up. quanah@zre-ldap001:~/p4/main/ThirdParty/cyrus-sasl/patches$ cat gssapi.patch --- cyrus-sasl-2.1.25/plugins/gssapi.c.orig 2011-10-07 14:47:07.461866240 -0700 +++ cyrus-sasl-2.1.25/plugins/gssapi.c 2011-10-07 14:47:45.891872589 -0700 @@ -370,7 +370,7 @@ } if (output_token->value && output) { - unsigned char * p = (unsigned char *) text->encode_buf; + unsigned char * p; ret = _plug_buf_alloc(text->utils, &(text->encode_buf), @@ -384,6 +384,8 @@ return ret; } + p = (unsigned char *) text->encode_buf; + p[0] = (output_token->length>>24) & 0xFF; p[1] = (output_token->length>>16) & 0xFF; p[2] = (output_token->length>>8) & 0xFF; --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7070) test058-syncrepl-asymmetric failed for hdb
by michael＠stroeder.com 21 Oct '11

21 Oct '11

hyc(a)symas.com wrote: > There's no evidence of an OpenLDAP bug here. All we can see from the > testrun/slapd.1.log is that it took 15 seconds for slap_sasl_init to complete, > which was long enough for the initial startup check to time out. You need to > check your system to see why SASL took so long to initialize, most likely a > DNS failure or some other transient issue. Hmm, this was with a local build of cyrus-sasl 2.1.25 which seg faulted on GSSAPI in another test. I will retry with cyrus-sasl package shipped with openSUSE 11.4. Ciao, Michael.

1 0

Re: (ITS#7069) test061-syncreplication-initiation failed for hdb
by hyc＠symas.com 21 Oct '11

21 Oct '11

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD (from git) > OS: openSUSE 11.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.45.214) > > >>>>>> test061-syncreplication-initiation failed for hdb > (exit 255) > make[2]: *** [hdb-mod] Error 255 > make[2]: Leaving directory `/usr/src/michael/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/tests' > make: *** [test] Error 2 Not enough info in your testrun directory, what was the output from the script up this point? From reading the slapd.?.log files, it also looks like something in your environment is slowing down the SASL init here, enough to make the script timeout. On all of my tests here the timestamp for slap_sasl_init is always identical to the preceding timestamp, i.e., slap_sasl_init should never even take as long as 1 second. Fix your environment before submitting any more bug reports. -- -- 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

Re: (ITS#7070) test058-syncrepl-asymmetric failed for hdb
by hyc＠symas.com 21 Oct '11

21 Oct '11

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD (from git master) > OS: openSUSE 11.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.51.243) > > >>>>>> Starting test058-syncrepl-asymmetric for hdb... > running defines.sh > Initializing master configurations... > Initializing search configurations... > Starting central master slapd on TCP/IP port 9011... > Using ldapsearch to check that central master slapd is running... > Waiting 1 seconds for slapd to start... > Waiting 2 seconds for slapd to start... > Waiting 3 seconds for slapd to start... > Waiting 4 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > ldapsearch failed (255)! >>>>>> test058-syncrepl-asymmetric failed for hdb > (exit 255) > make[2]: *** [hdb-mod] Error 255 > make[2]: Leaving directory `/usr/src/michael/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/tests' > make: *** [test] Error 2 There's no evidence of an OpenLDAP bug here. All we can see from the testrun/slapd.1.log is that it took 15 seconds for slap_sasl_init to complete, which was long enough for the initial startup check to time out. You need to check your system to see why SASL took so long to initialize, most likely a DNS failure or some other transient issue. Closing this ITS. -- -- 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

Re: (ITS#7070) test058-syncrepl-asymmetric failed for hdb
by michael＠stroeder.com 21 Oct '11

21 Oct '11

See testrun/ here: http://www.stroeder.com/temp/openldap-its7070-testrun.tar.gz

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2011