June 2009 - openldap-bugs

Re: (ITS#6161) test058-syncrepl-asymmetric failed (exit 6)

by michael＠stroeder.com

rein(a)OpenLDAP.org wrote: > michael(a)stroeder.com wrote: > >> Found 6 errors >>>>>>> ./scripts/test058-syncrepl-asymmetric failed (exit 6) > > Do you have the entire output from the test script? You mean the console output? Unfortunately not. As said I've generated a tar.gz of the whole testrun/ directory though: http://www.stroeder.com/temp/openldap/its6161-testrun.tar.gz > [..] without it I'm tempted to assume it > failed due to some timing glitch within the test script itself.. Hmm, how to find out? Ciao, Michael.

13 years, 9 months

1
0
0 / 0

(ITS#6165) Support offline modify (slapmodify) for cn=config

by quanah＠OpenLDAP.org

Full_Name: Quanah Gibson-Mount Version: 2.4.16 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) The slapmodify function already exists, but we've never built a tool around it. It would be useful to be able to have a utility that validates commands that users can use to modify cn=config while slapd is offline, rather than resorting to text editors that don't do validation of the changes being made.

13 years, 9 months

1
0
0 / 0

Re: (ITS#6161) test058-syncrepl-asymmetric failed (exit 6)

by rein＠OpenLDAP.org

michael(a)stroeder.com wrote: > Found 6 errors >>>>>> ./scripts/test058-syncrepl-asymmetric failed (exit 6) Do you have the entire output from the test script? It is required to tell what actually went wrong, and without it I'm tempted to assume it failed due to some timing glitch within the test script itself.. Rein

13 years, 9 months

1
0
0 / 0

(ITS#6164) send_ldap_ber() spins holding c_write1_mutex

by h.b.furuseth＠usit.uio.no

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard send_ldap_ber() has a suspicious-looking waitloop doing this: if ( ldap_pvt_thread_mutex_trylock( &conn->c_mutex )) { ldap_pvt_thread_mutex_unlock( &conn->c_write1_mutex ); ldap_pvt_thread_mutex_lock( &conn->c_write1_mutex ); Unlock does not mean a thread waiting for c_write1_mutex will acquire it immediately. Such a thread may have to wait until it is scheduled, at which time the looping thread has locked the mutex again. On the Linux box on my desk, a pure unlock-lock loop goes through 50000-100000 iterations before another thread waiting for the lock acquires it. OTOH, on a heavily used box it takes ~50 iterations. A sched_yield() between the unlock and lock reduces #iterations to 1. No idea if that is the right solution, nor how serious the problem is. The lock/unlock statements themselves are from result.c rev 1.323, but then with some more locking between them which disappeared in later revisions. My lock-unlock test program: #include <pthread.h> #include <sched.h> #include <stdio.h> #include <stdlib.h> #include <sys/select.h> static pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER; static unsigned count; static void *waiter(void *arg) { pthread_mutex_lock(&m); printf("Locked after %u iterations.\n", count); exit(0); } int main() { pthread_t t; pthread_mutex_lock(&m); pthread_create(&t, NULL, waiter, NULL); select(0, NULL, NULL, NULL, &(struct timeval){0, 100000}); for (count = 1 ;; ++count) { pthread_mutex_unlock(&m); pthread_mutex_lock(&m); } }

13 years, 9 months

1
0
0 / 0

(ITS#6163) back-sql DoS when searching for empty attr

by karavelov＠spnet.net

Full_Name: Luben Karavelov Version: 2.4.11-15 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.83.96.32) We use ldap for some user accounts authentication here and we have found that queries of this kind : ldapsearch -b "dc=users,dc=example,dc=com" "(&(objectClass=posixAccount)(uid=))" kill slapd. It exits on assert( 0 ) at line 1366 of back-sql/search.c It is even nastier because it could be remotely triggered with ssh -l "" server-with-ldap-accounts-in-nss.example.com or through ftp using the same technique.

13 years, 9 months

1
0
0 / 0

Re: (ITS#6151) Update cosine.schema to RFC 4524

by michael＠stroeder.com

Kurt Zeilenga wrote: > > On Jun 1, 2009, at 4:30 AM, michael(a)stroeder.com wrote: >> Updated schema file cosine-update.schema attached. > > I note that differs are generally preferred, even where the file is > mostly changed. This helps ensure changes that others might make to the > file you started with are not lost. I thought about sending a diff but the file in this form is more readable for easy review. Could someone please look at it whether that's ok? Another approach would be to have two schema files, one which only contains the schema descriptions from RFC 4524 and one with the missing schema descriptions from RFC 1274 with the latter obviously being dependent on the former. >> IPR notice: >> This patch file is derived from OpenLDAP Software and RFC 4524 and RFC >> 1274. All of the modifications to OpenLDAP Software represented in the >> attached file were developed by Michael Ströder <michael(a)stroeder.com>. >> I have not assigned rights and/or interest in this work to any party. > > While this notice of origin is fine, you did not include a rights > statement. I, Michael Ströder, hereby place the modified schema file cosine.schema attached to ITS#6151 (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. Ciao, Michael.

13 years, 9 months

1
0
0 / 0

(ITS#6162) hexadecimal log levels are not recognized in configuration

by jonathan＠phillipoux.net

Full_Name: Jonathan Clarke Version: RE24 and HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-bconfig-20090608.patch Submission from: (NULL) (80.65.230.146) The slapd-config(5) and slapd.conf(5) man pages state: olcLogLevel: <integer> [...] The desired log level can be input as a single integer that combines the (ORed) desired levels, both in decimal or in hexadecimal notation [...] as a list of integers (that are ORed internally), or as a list of the names that are shown between brackets, This is not the case. Integers and names (strings) are accepted, but hex notation is refused, with, from slapd.conf: /opt/openldap-RE24/etc/openldap/slapd.conf: line 10: <loglevel> unable to parse level "0x40" And using ldapmodify on cn=config: ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcLogLevel> unable to parse level Hexadecimal values are, however, accepted as arguments to the -d argument to slapd on the command line. The above patch fixes bconfig.c to accept hex values. On a side note, according to man strtol(3), this also means that loglevels can be typed in octal, for the more masochist among us :)

13 years, 9 months

1
0
0 / 0

Re: (ITS#6161) test058-syncrepl-asymmetric failed (exit 6)

by michael＠stroeder.com

Download content of directory testrun/ here: http://www.stroeder.com/temp/openldap/its6161-testrun.tar.gz I cannot reproduce this within directory tests/. It usually ends with this message: ERROR: Entry not removed on central search! Race error found after 1 of 10 iterations Found 3 errors >>>>>> Exiting with a false success status for now

13 years, 9 months

1
0
0 / 0

(ITS#6161) test058-syncrepl-asymmetric failed (exit 6)

by michael＠stroeder.com

Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.113.91) Found 6 errors >>>>> ./scripts/test058-syncrepl-asymmetric failed (exit 6) make[2]: *** [hdb-mod] Error 6 make[2]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make: *** [test] Error 2

13 years, 9 months

1
0
0 / 0

Re: (ITS#6104) race condition with cancel operation

by h.b.furuseth＠usit.uio.no

Hrmph, the placement of the 'so->s_op->o_abandon = 1;' which I wanted to move out of the mutex lock derives from syncprov.c rev 1.20 commented "Fix abandon sequencing":-( -- Hallvard

13 years, 9 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2009