- openldap-bugs - openldap.org

(ITS#8000) Warnings building contrib overlay passwd/sha2
by michael＠stroeder.com 10 Dec '14

10 Dec '14

Full_Name: Version: RE24 OS: URL: Submission from: (NULL) (79.227.174.182) HI! I'm trying to package passwd/sha2 for openSUSE. The default compiler options in their build system results in these warnings: [ 193s] + CFLAGS='-fomit-frame-pointer -fmessage-length=0 -grecord-gcc-switches -fstack-protector -O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -Wno-format-extra-args -fno-strict-aliasing' [ 193s] + make -j4 sysconfdir=/etc/openldap libdir=/usr/lib libexecdir=/usr/lib [ 193s] ../../../../libtool --mode=compile gcc -g -O2 -Wall -I..%2.%./../../include -I../../../../include -I../../../../servers/slapd -c slapd-sha2.c [ 193s] ../../../../libtool --mode=compile gcc -g -O2 -Wall -I../../../../include -I../../../../include -I../../../../servers/slapd -c sha2.c [ 193s] mkdir .libs [ 193s] mkdir .libs [ 193s] mkdir: cannot create directory '.libs': File exists [ 193s] gcc -g -O2 -Wall -I../../../../include -I../../../../include -I../../../../servers/slapd -c sha2.c -fPIC -DPIC -o .libs/sha2.o [ 193s] gcc -g -O2 -Wall -I../../../../include -I../../../../include -I../../../../servers/slapd -c slapd-sha2.c -fPIC -DPIC -o .libs/slapd-sha2.o [ 193s] sha2.c: In function 'SHA256_Final': [ 193s] sha2.c:608:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] [ 193s] *(sha2_word64*)&context->buffer[SHA256_SHORT_BLOCK_LENGTH] = context->bitcount; [ 193s] ^ [ 193s] sha2.c: In function 'SHA512_Last': [ 193s] sha2.c:925:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] [ 193s] *(sha2_word64*)&context->buffer[SHA512_SHORT_BLOCK_LENGTH] = context->bitcount[1]; [ 193s] ^ [ 193s] sha2.c:926:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] [ 193s] *(sha2_word64*)&context->buffer[SHA512_SHORT_BLOCK_LENGTH+8] = context->bitcount[0]; [ 193s] ^ [ 193s] gcc -g -O2 -Wall -I../../../../include -I../../../../include -I../../../../servers/slapd -c slapd-sha2.c -o slapd-sha2.o >/dev/null 2>&1 [ 193s] gcc -g -O2 -Wall -I../../../../include -I../../../../include -I../../../../servers/slapd -c sha2.c -o sha2.o >/dev/null 2>&1 [ 194s] ../../../../libtool --mode=link gcc -g -O2 -Wall -version-info 0:0:0 \ [ 194s] -rpath /usr/lib/openldap -module -o pw-sha2.la slapd-sha2.lo sha2.lo ../../../../libraries/libldap_r/libldap_r.la ../../../../libraries/liblber/liblber.la [ 194s] cc -shared .libs/slapd-sha2.o .libs/sha2.o -Wl,--rpath -Wl,/home/abuild/rpmbuild/BUILD/openldap-2.4.40/libraries/libldap_r/.libs -Wl,--rpath -Wl,/home/abuild/rpmbuild/BUILD/openldap-2.4.40/libraries/liblber/.libs -L/home/abuild/rpmbuild/BUILD/openldap-2.4.40/libraries/liblber/.libs ../../../../libraries/libldap_r/.libs/libldap_r.so ../../../../libraries/liblber/.libs/liblber.so -Wl,-soname -Wl,pw-sha2.so.0 -o .libs/pw-sha2.so.0.0.0 [ 194s] (cd .libs && rm -f pw-sha2.so.0 && ln -s pw-sha2.so.0.0.0 pw-sha2.so.0) [ 194s] (cd .libs && rm -f pw-sha2.so && ln -s pw-sha2.so.0.0.0 pw-sha2.so) [ 194s] ar cru .libs/pw-sha2.a slapd-sha2.o sha2.o [ 194s] ranlib .libs/pw-sha2.a [ 194s] creating pw-sha2.la Overall RPM build fails with: [ 262s] I: Program is likely to break with new gcc. Try -fno-strict-aliasing. [ 262s] W: openldap2 strict-aliasing-punning sha2.c:608, 925, 926

1 0

(ITS#7999) proxycache failed for bdb while testing
by yjd＠zjca.com.cn 10 Dec '14

10 Dec '14

Full_Name: edong Version: 2.4.40 OS: CentOS 6.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (60.190.254.10) BerkeleyDB version: 5.3.28 ./configure --enable-crypt --enable-lmpasswd --enable-spasswd --enable-modules --enable-backends=mod --enable-perl=no --enable-ndb=no --enable-overlays=mod --enable-dynamic The "make test" fails as follow3A3A ... Testing Bind caching Query 19: cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,dc=com Query 20: (Bind should be cached) Refresh failed >>>>> test020-proxycache failed for bdb (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/root/Downloads/openldap-2.4.40/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/root/Downloads/openldap-2.4.40/tests' make: *** [test] Error 2

1 0

Re: (ITS#7998) no-return-in-nonvoid-function noopsrch.c:145
by michael＠stroeder.com 10 Dec '14

10 Dec '14

As I read noopsrch_response there's a else {} clause missing. But I'm not sure.

1 0

(ITS#7998) no-return-in-nonvoid-function noopsrch.c:145
by michael＠stroeder.com 10 Dec '14

10 Dec '14

Full_Name: Version: RE24 OS: URL: Submission from: (NULL) (79.227.174.182) Building slapo- (contrib/) with strict warnings results in: no-return-in-nonvoid-function noopsrch.c:145

1 0

(ITS#7997) no-return-in-nonvoid-function dupent.c:367
by michael＠stroeder.com 10 Dec '14

10 Dec '14

Full_Name: Version: OS: URL: Submission from: (NULL) (79.227.174.182) Building slapo-dupent (contrib/) with strict warnings results in: no-return-in-nonvoid-function dupent.c:367

1 0

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by hyc＠symas.com 09 Dec '14

09 Dec '14

Leonid Yuriev wrote: > I saw that the master is lost some changes of the my original patch > (that was early attached to ITS). > > Please see attached diff. > I think it is a race condition around si_cookieState inside for-loop. Prove it. The fields being accessed inside the loop are for the pending values, and the pending mutex has already been acquired outside the loop. -- -- 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#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 09 Dec '14

09 Dec '14

This is a multi-part message in MIME format. --------------090602010509010401080002 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I saw that the master is lost some changes of the my original patch (that was early attached to ITS). Please see attached diff. I think it is a race condition around si_cookieState inside for-loop. --------------090602010509010401080002 Content-Type: text/x-patch; name="its#7968-lost.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="its#7968-lost.patch" diff --git a/servers/slapd/syncrepl.c b/servers/slapd/syncrepl.c --- a/servers/slapd/syncrepl.c +++ b/servers/slapd/syncrepl.c @@ -958,15 +958,17 @@ do_syncrep2( ldap_pvt_thread_yield(); } + ldap_pvt_thread_mutex_lock( &si->si_cookieState->cs_mutex ); for ( i =0; i<si->si_cookieState->cs_pnum; i++ ) { if ( sid < si->si_cookieState->cs_psids[i] ) break; if ( si->si_cookieState->cs_psids[i] == sid ) { if ( ber_bvcmp( syncCookie.ctxcsn, &si->si_cookieState->cs_pvals[i] ) <= 0 ) { - ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_pmutex ); bdn.bv_val[bdn.bv_len] = '\0'; Debug( LDAP_DEBUG_SYNC, "do_syncrep2: %s CSN pending, ignoring %s (%s)\n", si->si_ridtxt, syncCookie.ctxcsn->bv_val, bdn.bv_val ); + ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_mutex ); + ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_pmutex ); ldap_controls_free( rctrls ); rc = 0; goto done; @@ -983,6 +985,7 @@ do_syncrep2( (struct sync_cookie *)&si->si_cookieState->cs_pvals, i, sid, syncCookie.ctxcsn ); } + ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_mutex ); assert( punlock < 0 ); punlock = i; } else if (si->si_too_old) { --------------090602010509010401080002--

1 0

Re: (ITS#7995) of-by-one error in schema
by hyc＠symas.com 09 Dec '14

09 Dec '14

Леонид Юрьев wrote: > (2) > But let see to lines 570-575 of mdb-back/attr.c and lines 764-772 of slapd/ad.c: > - does the mdb-value include a NUL byte = > https://github.com/leo-yuriev/openldap-lmdb-challenge/blob/2.4-devel/server… > - if "YES" then "+1" at slapd/ad.c:764 is wrong = > https://github.com/leo-yuriev/openldap-lmdb-challenge/blob/2.4-devel/server… > - but if "NO" then "strcpy()" at slapd/ad.c:772 (and more) is wrong = > https://github.com/leo-yuriev/openldap-lmdb-challenge/blob/2.4-devel/server… And the answer is no, back-mdb/attr.c mdb_ad_get() doesn't store the trailing NUL byte, > diff --git a/servers/slapd/ad.c b/servers/slapd/ad.c > index 246b900..fd60483 100644 > --- a/servers/slapd/ad.c > +++ b/servers/slapd/ad.c > @@ -118,7 +118,7 @@ AttributeDescription * ad_find_tags( > for (ad = type->sat_ad; ad; ad=ad->ad_next) > { > if (ad->ad_tags.bv_len == tags->bv_len && > - !strcasecmp(ad->ad_tags.bv_val, tags->bv_val)) > + !strncasecmp( ad->ad_tags.bv_val, tags->bv_val, ad->ad_tags.bv_len )) > break; > } Unnecessary. > ldap_pvt_thread_mutex_unlock( &type->sat_ad_mutex ); > @@ -742,14 +742,13 @@ int slap_bv2undef_ad( > /* use the appropriate type */ > if ( flags & SLAP_AD_PROXIED ) { > at = slap_schema.si_at_proxied; > - > } else { > at = slap_schema.si_at_undefined; > } > > for( desc = at->sat_ad; desc; desc=desc->ad_next ) { > if( desc->ad_cname.bv_len == bv->bv_len && > - !strcasecmp( desc->ad_cname.bv_val, bv->bv_val ) ) > + !strncasecmp( desc->ad_cname.bv_val, bv->bv_val, desc->ad_cname.bv_len) ) Unnecessary. We've already checked that the two lengths are equal; even if bv->bv_val is non-terminated the compare will stop because desc->ad_cname is terminated. > { > break; > } > @@ -769,7 +768,8 @@ int slap_bv2undef_ad( > > desc->ad_cname.bv_len = bv->bv_len; > desc->ad_cname.bv_val = (char *)(desc+1); > - strcpy(desc->ad_cname.bv_val, bv->bv_val); > + strncpy( desc->ad_cname.bv_val, bv->bv_val, desc->ad_cname.bv_len ) > + [desc->ad_cname.bv_len] = '\0'; This is a valid fix. > > /* canonical to upper case */ > ldap_pvt_str2upper( desc->ad_cname.bv_val ); > @@ -806,9 +806,10 @@ slap_bv2tmp_ad( > slap_sl_mfuncs.bmf_malloc( sizeof(AttributeDescription) + > bv->bv_len + 1, memctx ); > > - ad->ad_cname.bv_val = (char *)(ad+1); > - strncpy( ad->ad_cname.bv_val, bv->bv_val, bv->bv_len+1 ); > ad->ad_cname.bv_len = bv->bv_len; > + ad->ad_cname.bv_val = (char *)(ad+1); > + strncpy( ad->ad_cname.bv_val, bv->bv_val, ad->ad_cname.bv_len) > + [ad->ad_cname.bv_len] = '\0'; > ad->ad_flags = SLAP_DESC_TEMPORARY; > ad->ad_type = slap_schema.si_at_undefined; > Unnecessary. > @@ -887,7 +888,7 @@ an_find( > > for ( ; a->an_name.bv_val; a++ ) { > if ( a->an_name.bv_len != s->bv_len) continue; > - if ( strcasecmp( s->bv_val, a->an_name.bv_val ) == 0 ) { > + if ( strncasecmp( s->bv_val, a->an_name.bv_val, s->bv_len ) == 0 ) { > return( 1 ); > } > } Unnecessary. -- -- 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#7995) of-by-one error in schema
by leo＠yuriev.ru 09 Dec '14

09 Dec '14

--001a11c27ac2dcc7420509ced83c Content-Type: text/plain; charset=UTF-8 2014-12-09 18:57 GMT+03:00 Howard Chu <hyc(a)symas.com>: > leo(a)yuriev.ru wrote: >> >> Full_Name: Leonid Yuriev >> Version: 2.4.40 >> OS: RHEL7 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (31.130.36.33) >> >> >> In some cases (presumably when a database contains more attributes than >> defined >> in the scheme) a heap error may be detected at stop of slapd. >> >> Below is the result of attempts to find a bug(s) with Valgrind. >> It is enough to corrupt a malloc's heap! > > > Please provide a test case. Unable to reproduce this on a local database > with commented out schema. I get: > > violino:~/OD/o24/tests> valgrind ../servers/slapd/slapd -Tc -f > /tmp/testr/slapd.1.conf > /tmp/out > ==25499== Memcheck, a memory error detector > ==25499== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==25499== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright > info > ==25499== Command: ../servers/slapd/slapd -Tc -f /tmp/testr/slapd.1.conf > ==25499== > 54871b4f UNKNOWN attributeDescription "HOMEPOSTALADDRESS" inserted. > 54871b4f UNKNOWN attributeDescription "DRINK" inserted. > 54871b4f UNKNOWN attributeDescription "HOMEPHONE" inserted. > 54871b4f UNKNOWN attributeDescription "PAGER" inserted. > ==25499== > ==25499== HEAP SUMMARY: > ==25499== in use at exit: 2,746 bytes in 78 blocks > ==25499== total heap usage: 10,335 allocs, 10,257 frees, 1,649,999 bytes > allocated > ==25499== > ==25499== LEAK SUMMARY: > ==25499== definitely lost: 0 bytes in 0 blocks > ==25499== indirectly lost: 0 bytes in 0 blocks > ==25499== possibly lost: 0 bytes in 0 blocks > ==25499== still reachable: 2,746 bytes in 78 blocks > ==25499== suppressed: 0 bytes in 0 blocks > ==25499== Rerun with --leak-check=full to see details of leaked memory > ==25499== > ==25499== For counts of detected and suppressed errors, rerun with: -v > ==25499== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > > -- > -- 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) Unfortunately it was reproduced only in production-like environment, therefore a testcase or complete info is not available yet. (2) But let see to lines 570-575 of mdb-back/attr.c and lines 764-772 of slapd/ad.c: - does the mdb-value include a NUL byte = https://github.com/leo-yuriev/openldap-lmdb-challenge/blob/2.4-devel/server… - if "YES" then "+1" at slapd/ad.c:764 is wrong = https://github.com/leo-yuriev/openldap-lmdb-challenge/blob/2.4-devel/server… - but if "NO" then "strcpy()" at slapd/ad.c:772 (and more) is wrong = https://github.com/leo-yuriev/openldap-lmdb-challenge/blob/2.4-devel/server… (3) Next, I had added a couple of assert-check into mdb-back/attr.c and right away got "slapcat: attr.c:573: mdb_ad_read: Assertion `bdata.bv_val[bdata.bv_len-1] == 0' failed" diff --git a/servers/slapd/back-mdb/attr.c b/servers/slapd/back-mdb/attr.c index 07b64a6..7979b9d 100644 --- a/servers/slapd/back-mdb/attr.c +++ b/servers/slapd/back-mdb/attr.c @@ -569,6 +569,8 @@ int mdb_ad_read( struct mdb_info *mdb, MDB_txn *txn ) while ( rc == MDB_SUCCESS ) { bdata.bv_len = data.mv_size; bdata.bv_val = data.mv_data; + assert(bdata.bv_len > 0); + assert(bdata.bv_val[bdata.bv_len-1] == 0); ad = NULL; rc = slap_bv2ad( &bdata, &ad, &text ); if ( rc ) { (4) Ok, this is a off-by-one bug. Then I looked for "sizeof(AttributeDescription)" and has found only 3 places in slapd/ad.c ... and fix a few places of str-calls to n-form. Patch is attached, please review it. Leonid. --- The attached files is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Peter-Service LLC, Moscow, Russia. Peter-Service LLC has not assigned rights and/or interest in this work to any party. I, Leonid Yuriev am authorized by Peter-Service LLC, my employer, to release this work under the following terms. Peter-Service LLC hereby places the following modifications to OpenLDAP Software (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. --001a11c27ac2dcc7420509ced83c Content-Type: text/x-patch; charset=US-ASCII; name="its7995.patch" Content-Disposition: attachment; filename="its7995.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i3hr0n7l0 Y29tbWl0IDkxMzk4NmZjZGI3NGFlMjcyNjk5ZjI0NzA0MzBmMGRjNmM0NTkxM2YKQXV0aG9yOiBM ZW8gWXVyaWV2IDxsZW9AeXVyaWV2LnJ1PgpEYXRlOiAgIDIwMTQtMTItMDkgMjM6Mzg6NDQgKzAz MDAKCiAgICBJVFMjNzk5NSBoZWFwIGNvcnJ1cHRpb24gYW5kIG9mZi1ieS1vbmUgZXJyb3JzIGlu IGF0dHJpYnV0ZS1kZXNjcmlwdGlvbiBoYW5kbGluZy4KCmRpZmYgLS1naXQgYS9zZXJ2ZXJzL3Ns YXBkL2FkLmMgYi9zZXJ2ZXJzL3NsYXBkL2FkLmMKaW5kZXggMjQ2YjkwMC4uZmQ2MDQ4MyAxMDA2 NDQKLS0tIGEvc2VydmVycy9zbGFwZC9hZC5jCisrKyBiL3NlcnZlcnMvc2xhcGQvYWQuYwpAQCAt MTE4LDcgKzExOCw3IEBAIEF0dHJpYnV0ZURlc2NyaXB0aW9uICogYWRfZmluZF90YWdzKAogCWZv ciAoYWQgPSB0eXBlLT5zYXRfYWQ7IGFkOyBhZD1hZC0+YWRfbmV4dCkKIAl7CiAJCWlmIChhZC0+ YWRfdGFncy5idl9sZW4gPT0gdGFncy0+YnZfbGVuICYmCi0JCQkhc3RyY2FzZWNtcChhZC0+YWRf dGFncy5idl92YWwsIHRhZ3MtPmJ2X3ZhbCkpCisJCQkhc3RybmNhc2VjbXAoIGFkLT5hZF90YWdz LmJ2X3ZhbCwgdGFncy0+YnZfdmFsLCBhZC0+YWRfdGFncy5idl9sZW4gKSkKIAkJCWJyZWFrOwog CX0KIAlsZGFwX3B2dF90aHJlYWRfbXV0ZXhfdW5sb2NrKCAmdHlwZS0+c2F0X2FkX211dGV4ICk7 CkBAIC03NDIsMTQgKzc0MiwxMyBAQCBpbnQgc2xhcF9idjJ1bmRlZl9hZCgKIAkvKiB1c2UgdGhl IGFwcHJvcHJpYXRlIHR5cGUgKi8KIAlpZiAoIGZsYWdzICYgU0xBUF9BRF9QUk9YSUVEICkgewog CQlhdCA9IHNsYXBfc2NoZW1hLnNpX2F0X3Byb3hpZWQ7Ci0KIAl9IGVsc2UgewogCQlhdCA9IHNs YXBfc2NoZW1hLnNpX2F0X3VuZGVmaW5lZDsKIAl9CiAKIAlmb3IoIGRlc2MgPSBhdC0+c2F0X2Fk OyBkZXNjOyBkZXNjPWRlc2MtPmFkX25leHQgKSB7CiAJCWlmKCBkZXNjLT5hZF9jbmFtZS5idl9s ZW4gPT0gYnYtPmJ2X2xlbiAmJgotCQkgICAgIXN0cmNhc2VjbXAoIGRlc2MtPmFkX2NuYW1lLmJ2 X3ZhbCwgYnYtPmJ2X3ZhbCApICkKKwkJICAgICFzdHJuY2FzZWNtcCggZGVzYy0+YWRfY25hbWUu YnZfdmFsLCBidi0+YnZfdmFsLCBkZXNjLT5hZF9jbmFtZS5idl9sZW4pICkKIAkJewogCQkgICAg CWJyZWFrOwogCQl9CkBAIC03NjksNyArNzY4LDggQEAgaW50IHNsYXBfYnYydW5kZWZfYWQoCiAK IAkJZGVzYy0+YWRfY25hbWUuYnZfbGVuID0gYnYtPmJ2X2xlbjsKIAkJZGVzYy0+YWRfY25hbWUu YnZfdmFsID0gKGNoYXIgKikoZGVzYysxKTsKLQkJc3RyY3B5KGRlc2MtPmFkX2NuYW1lLmJ2X3Zh bCwgYnYtPmJ2X3ZhbCk7CisJCXN0cm5jcHkoIGRlc2MtPmFkX2NuYW1lLmJ2X3ZhbCwgYnYtPmJ2 X3ZhbCwgZGVzYy0+YWRfY25hbWUuYnZfbGVuICkKKwkJCVtkZXNjLT5hZF9jbmFtZS5idl9sZW5d ID0gJ1wwJzsKIAogCQkvKiBjYW5vbmljYWwgdG8gdXBwZXIgY2FzZSAqLwogCQlsZGFwX3B2dF9z dHIydXBwZXIoIGRlc2MtPmFkX2NuYW1lLmJ2X3ZhbCApOwpAQCAtODA2LDkgKzgwNiwxMCBAQCBz bGFwX2J2MnRtcF9hZCgKIAkJIHNsYXBfc2xfbWZ1bmNzLmJtZl9tYWxsb2MoIHNpemVvZihBdHRy aWJ1dGVEZXNjcmlwdGlvbikgKwogCQkJYnYtPmJ2X2xlbiArIDEsIG1lbWN0eCApOwogCi0JYWQt PmFkX2NuYW1lLmJ2X3ZhbCA9IChjaGFyICopKGFkKzEpOwotCXN0cm5jcHkoIGFkLT5hZF9jbmFt ZS5idl92YWwsIGJ2LT5idl92YWwsIGJ2LT5idl9sZW4rMSApOwogCWFkLT5hZF9jbmFtZS5idl9s ZW4gPSBidi0+YnZfbGVuOworCWFkLT5hZF9jbmFtZS5idl92YWwgPSAoY2hhciAqKShhZCsxKTsK KwlzdHJuY3B5KCBhZC0+YWRfY25hbWUuYnZfdmFsLCBidi0+YnZfdmFsLCBhZC0+YWRfY25hbWUu YnZfbGVuKQorCQlbYWQtPmFkX2NuYW1lLmJ2X2xlbl0gPSAnXDAnOwogCWFkLT5hZF9mbGFncyA9 IFNMQVBfREVTQ19URU1QT1JBUlk7CiAJYWQtPmFkX3R5cGUgPSBzbGFwX3NjaGVtYS5zaV9hdF91 bmRlZmluZWQ7CiAKQEAgLTg4Nyw3ICs4ODgsNyBAQCBhbl9maW5kKAogCiAJZm9yICggOyBhLT5h bl9uYW1lLmJ2X3ZhbDsgYSsrICkgewogCQlpZiAoIGEtPmFuX25hbWUuYnZfbGVuICE9IHMtPmJ2 X2xlbikgY29udGludWU7Ci0JCWlmICggc3RyY2FzZWNtcCggcy0+YnZfdmFsLCBhLT5hbl9uYW1l LmJ2X3ZhbCApID09IDAgKSB7CisJCWlmICggc3RybmNhc2VjbXAoIHMtPmJ2X3ZhbCwgYS0+YW5f bmFtZS5idl92YWwsIHMtPmJ2X2xlbiApID09IDAgKSB7CiAJCQlyZXR1cm4oIDEgKTsKIAkJfQog CX0K --001a11c27ac2dcc7420509ced83c--

1 0

(ITS#7996) Global initialisation race in ldap_int_initialize
by a.cudbardb＠freeradius.org 09 Dec '14

09 Dec '14

Full_Name: Arran Cudbard-Bell Version: 2.4.40 OS: OSX 10.10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.196.165.104) Issue is fully documented here: https://github.com/arr2036/ldapperf/issues/2 As libldap lacks a global initialisation function, the global config struct and other global resources are initialised on the first call to either ldap_create, ldap_get_option or ldap_set_option via a call to ldap_int_initialize. Where multiple threads are spawned and each allocate a new handle using a function that calls ldap_create, the lack of concurrent access protection in ldap_int_initialize causes memory corruption. There are a few ways this could be fixed. One is documented in the issue tracker link above. There are likely better ones. An alternative of fixing this would be to have public functions that can be used to initialise any global resources before creating handles, and to free them explicitly (instead of relying on atexit or a similar mechanism). In terms of writing dynamically loadable/unloadable modules around libldap, the second approach is preferred as any memory allocated on the heap could be cleaned up prior to the module being unloaded.

1 0

Re: (ITS#7995) of-by-one error in schema
by hyc＠symas.com 09 Dec '14

09 Dec '14

leo(a)yuriev.ru wrote: > Full_Name: Leonid Yuriev > Version: 2.4.40 > OS: RHEL7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (31.130.36.33) > > > In some cases (presumably when a database contains more attributes than defined > in the scheme) a heap error may be detected at stop of slapd. > > Below is the result of attempts to find a bug(s) with Valgrind. > It is enough to corrupt a malloc's heap! Please provide a test case. Unable to reproduce this on a local database with commented out schema. I get: violino:~/OD/o24/tests> valgrind ../servers/slapd/slapd -Tc -f /tmp/testr/slapd.1.conf > /tmp/out ==25499== Memcheck, a memory error detector ==25499== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==25499== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info ==25499== Command: ../servers/slapd/slapd -Tc -f /tmp/testr/slapd.1.conf ==25499== 54871b4f UNKNOWN attributeDescription "HOMEPOSTALADDRESS" inserted. 54871b4f UNKNOWN attributeDescription "DRINK" inserted. 54871b4f UNKNOWN attributeDescription "HOMEPHONE" inserted. 54871b4f UNKNOWN attributeDescription "PAGER" inserted. ==25499== ==25499== HEAP SUMMARY: ==25499== in use at exit: 2,746 bytes in 78 blocks ==25499== total heap usage: 10,335 allocs, 10,257 frees, 1,649,999 bytes allocated ==25499== ==25499== LEAK SUMMARY: ==25499== definitely lost: 0 bytes in 0 blocks ==25499== indirectly lost: 0 bytes in 0 blocks ==25499== possibly lost: 0 bytes in 0 blocks ==25499== still reachable: 2,746 bytes in 78 blocks ==25499== suppressed: 0 bytes in 0 blocks ==25499== Rerun with --leak-check=full to see details of leaked memory ==25499== ==25499== For counts of detected and suppressed errors, rerun with: -v ==25499== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) -- -- 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#7995) of-by-one error in schema
by leo＠yuriev.ru 09 Dec '14

09 Dec '14

Full_Name: Leonid Yuriev Version: 2.4.40 OS: RHEL7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (31.130.36.33) In some cases (presumably when a database contains more attributes than defined in the scheme) a heap error may be detected at stop of slapd. Below is the result of attempts to find a bug(s) with Valgrind. It is enough to corrupt a malloc's heap! ==29701== Invalid write of size 1 ==29701== at 0x4A089AF: strcpy (vg_replace_strmem.c:458) ==29701== by 0x45ECC6: slap_bv2undef_ad (ad.c:772) ==29701== by 0x4C3649: mdb_ad_read (attr.c:575) ==29701== by 0x4949D7: mdb_db_open (init.c:278) ==29701== by 0x482D86: over_db_open (backover.c:149) ==29701== by 0x42DA58: backend_startup_one (backend.c:224) ==29701== by 0x42DD22: backend_startup (backend.c:325) ==29701== by 0x44ABB0: slap_startup (init.c:219) ==29701== by 0x406C55: main (main.c:988) ==29701== Address 0x57d9187 is 0 bytes after a block of size 71 alloc'd ==29701== at 0x4A0720A: malloc (vg_replace_malloc.c:296) ==29701== by 0x549A18: ber_memalloc_x (memory.c:228) ==29701== by 0x43901A: ch_malloc (ch_malloc.c:54) =979701== by 0x45EC93: slap_bv2undef_ad (ad.c:764) ==29701== by 0x4C3649: mdb_ad_read (attr.c:575) ==29701== by 0x4949D7: mdb_db_open (init.c:278) ==29701== by 0x482D86: over_db_open (backover.c:149) ==29701== by 0x42DA58: backend_startup_one (backend.c:224) ==29701== by 0x42DD22: backend_startup (backend.c:325) ==29701== by 0x44ABB0: slap_startup (init.c:219) ==29701== by 0x406C55: main (main.c:988) ==29701== ==29701== Invalid read of size 1 ==29701== at 0x53BE9F: ldap_pvt_str2upper (string.c:116) ==29701== by 0x45ECCF: slap_bv2undef_ad (ad.c:775) ==29701== by 0x4C3649: mdb_ad_read (attr.c:575) ==29701== by 0x4949D7: mdb_db_open (init.c:278) ==29701== by 0x482D86: over_db_open (backover.c:149) ==29701== by 0x42DA58: backend_startup_one (backend.c:224) ==291%1== by 0x42DD22: backend_startup (backend.c:325) ==29701== by 0x44ABB0: slap_startup (init.c:219) ==29701== by 0x406C55: main (main.c:988) ==29701== Address 0x57d9187 is 0 bytes after a block of size 71 alloc'd ==29701== at 0x4A0720A: malloc (vg_replace_malloc.c:296) ==29701== by 0x549A18: ber_memalloc_x (memory.c:228) ==29701== by 0x43901A: ch_malloc (ch_malloc.c:54) ==29701== by 0x45EC93: slap_bv2undef_ad (ad.c:764) ==29701== by 0x4C3649: mdb_ad_read (attr.c:575) ==29701== by 0x4949D7: mdb_db_open (init.c:278) ==29701== by 0x482D86: over_db_open (backover.c:149) ==29701== by 0x42DA58: backend_startup_one (backend.c:224) ==29701== by 0x42DD22: backend_startup (backend.c:325) ==29701== by 0x44ABB0: slap_startup (init.c:219) ==29703D%3= by 0x406C55: main (main.c:988) ==29701== Invalid read of size 1 ==29701== at 0x30E184812C: vfprintf (in /lib64/libc-2.12.so) ==29701== by 0x30E186FA51: vsnprintf (in /lib64/libc-2.12.so) ==29701== by 0x5498DA: lutil_debug (debug.c:67) ==29701== by 0x45ED34: slap_bv2undef_a(a8ad.c:785) ==29701== by 0x4C3649: mdb_ad_read (attr.c:575) ==29701== by 0x4949D7: mdb_db_open (init.c:278) ==29701== by 0x482D86: over_db_open (backover.c:149) ==29701== by 0x42DA58: backend_startup_one (backend.c:224) ==29701== by 0x42DD22: backend_startup (backend.c:325) ==29701== by 0x44ABB0: slap_startup (init.c:219) ==29701== by 0x406C55: main (main.c:988) ==29701== Address 0x57d9187 is 0 bytes after a block of size 71 alloc'd ==29701== at 0x4A0720A: malloc (vg_replace_malloc.c:296) ==29701== by 0x549A18: ber_memalloc_x (memory.c:228) ==29701== by 0x43901A: ch_malloc (ch_malloc.c:54) ==29701== by 0x45EC93: slap_bv2undef_ad (ad.c:764) ==29701== by 0x4C3649: mdb_ad_read (attr.c:575) ==29701== by 0x4949D7: mdb_db_open (init.c:278) ==29701== by 0x482D86: over_db_open (backover.c:149) ==29701== by 0x42DA58: backend_startup_one (backend.c:224) ==29701== by 0x42DD22: backend_startup (backend.c:325) ==29701== by 0x44ABB0: slap_startup (init.c:219) ==29701== by 0x406C55: main (main.c:988)

1 0

Re: (ITS#7993) proxyauth with saslmech EXTERNAL not working
by dirk.kastens＠uni-osnabrueck.de 09 Dec '14

09 Dec '14

This is a cryptographically signed message in MIME format. --------------ms060703010908070300060600 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I like to reopen the case. Meanwhile I compiled openldap myself (under RedHat SL 7.0). At first, I compiled openldap-2.4.40. I configured ldap as a replica=20 server. It connects with saslmech EXTERNAL to the master server. When I configure idassert-bind with saslmech EXTERNAL and try to change=20 an entry, ldapmodify fails with ldap_modify: Other (e.g., implementation specific) error (80) slapd.conf logs the message: --------------------------- send_ldap_result:=20 referral=3D"ldap://ldap-master.rz.uni-osnabrueck.de/uid=3Dxmuster,ou=3Dpe= ople,dc=3Duni-osnabrueck,dc=3Dde" >>> dnPrettyNormal: <uid=3Dxmuster,ou=3Dpeople,dc=3Duni-osnabrueck,dc=3D= de> <<< dnPrettyNormal: <uid=3Dxmuster,ou=3Dpeople,dc=3Duni-osnabrueck,dc=3Dd= e>,=20 <uid=3Dxmuster,ou=3Dpeople,dc=3Duni-osnabrueck,dc=3Dde> conn=3D1000 op=3D1 ldap_chain_op:=20 ref=3D"ldap://ldap-master.rz.uni-osnabrueck.de/uid=3Dxmuster,ou=3Dpeople,= dc=3Duni-osnabrueck,dc=3Dde"=20 -> "ldap://ldap-master.rz.uni-osnabrueck.de" conn=3D1000 op=3D1 ldap_chain_op:=20 ref=3D"ldap://ldap-master.rz.uni-osnabrueck.de/uid=3Dxmuster,ou=3Dpeople,= dc=3Duni-osnabrueck,dc=3Dde":=20 URI=3D"ldap://ldap-master.rz.uni-osnabrueck.de" found in cache =3D>ldap_back_getconn: conn=3D1000 op=3D1: lc=3D0x7faca820bc70 inserted r= efcnt=3D1=20 rc=3D0 Error: ldap_back_is_proxy_authz returned 0, misconfigured URI? send_ldap_result: conn=3D1000 op=3D1 p=3D3 send_ldap_result: err=3D80 matched=3D"" text=3D"misconfigured URI?" send_ldap_result: conn=3D1000 op=3D1 p=3D3 send_ldap_result: err=3D80 matched=3D"" text=3D"" send_ldap_response: msgid=3D2 tag=3D103 err=3D80 --------------------------- Then I compiled openldap-2.4.26 and used the same configuration. The=20 modify with saslmech EXTERNAL succeeded: --------------------------- send_ldap_result: conn=3D1001 op=3D1 p=3D3 send_ldap_result: err=3D10 matched=3D"" text=3D"" send_ldap_result:=20 referral=3D"ldap://ldap-master.rz.uni-osnabrueck.de/uid=3Dxmuster,ou=3Dpe= ople,dc=3Duni-osnabrueck,dc=3Dde" >>> dnPrettyNormal: <uid=3Dxmuster,ou=3Dpeople,dc=3Duni-osnabrueck,dc=3D= de> <<< dnPrettyNormal: <uid=3Dxmuster,ou=3Dpeople,dc=3Duni-osnabrueck,dc=3Dd= e>,=20 <uid=3Dxmuster,ou=3Dpeople,dc=3Duni-osnabrueck,dc=3Dde> conn=3D1001 op=3D1 ldap_chain_op:=20 ref=3D"ldap://ldap-master.rz.uni-osnabrueck.de/uid=3Dxmuster,ou=3Dpeople,= dc=3Duni-osnabrueck,dc=3Dde"=20 -> "ldap://ldap-master.rz.uni-osnabrueck.de" conn=3D1001 op=3D1 ldap_chain_op:=20 ref=3D"ldap://ldap-master.rz.uni-osnabrueck.de/uid=3Dxmuster,ou=3Dpeople,= dc=3Duni-osnabrueck,dc=3Dde":=20 URI=3D"ldap://ldap-master.rz.uni-osnabrueck.de" found in cache =3D>ldap_back_getconn: conn=3D1001 op=3D1: lc=3D0x7f4f201fe6f0 inserted r= efcnt=3D1=20 rc=3D0 send_ldap_result: conn=3D1001 op=3D1 p=3D3 send_ldap_result: err=3D0 matched=3D"" text=3D"" send_ldap_response: msgid=3D2 tag=3D103 err=3D0 --------------------------- With a quick look I found out, that the function ldap_back_dobind_int in = server/slapd/back-ldap/bind.c differs. In 2.4.26 you have: --------------------------- if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY( &bindcred ) ) { /* if we got here, it shouldn't return result */= rc =3D ldap_back_is_proxy_authz( op, rs, LDAP_BACK_DONTSEND, &binddn, &bindcred )= ; assert( rc =3D=3D 1 ); } rc =3D ldap_back_proxy_authz_bind( lc, op, rs, sendok,=20 &binddn, &bindcred ); goto done; } --------------------------- while in 2.4.40 there is: --------------------------- if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY(=20 &bindcred ) ) { /* if we got here, it shouldn't return result */= rc =3D ldap_back_is_proxy_authz( op, rs, LDAP_BACK_DONTSEND, &binddn, &bindcred )= ; if ( rc !=3D 1 ) { Debug( LDAP_DEBUG_ANY, "Error:=20 ldap_back_is_proxy_authz " "returned %d, misconfigured=20 URI?\n", rc, 0, 0 ); rs->sr_err =3D LDAP_OTHER; rs->sr_text =3D "misconfigured URI?"; LDAP_BACK_CONN_ISBOUND_CLEAR( lc ); if ( sendok & LDAP_BACK_SENDERR ) { send_ldap_result( op, rs ); } goto done; } rc =3D ldap_back_proxy_authz_bind( lc, op, rs, sendok,=20 &binddn, &bindcred ); goto done; } --------------------------- This is where the error message comes from ("misconfigured URI?") --=20 Regards, Dirk Kastens Universitaet Osnabrueck, Rechenzentrum (Computer Center) Albrechtstr. 28, 49069 Osnabrueck, Germany Tel.: +49-541-969-2347, FAX: -2470 --------------ms060703010908070300060600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJDCC BCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBa Fw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAw DgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U 1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6 fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869 080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqD oZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkh nSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDov L3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNy bF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX 3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iR M347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6ba hWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyH xQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIFcDCCBFigAwIBAgIHF6QkfFey qDANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MB4XDTE0MDUyNzE0NTMzM1oXDTE5MDcwOTIzNTkwMFowgZExCzAJBgNVBAYTAkRFMSAwHgYD VQQKExdVbml2ZXJzaXRhZXQgT3NuYWJydWVjazEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEj MCEGA1UEAxMaVW5pLU9zbmFicnVlY2sgUlotQ0EgRy0wMDIxIzAhBgkqhkiG9w0BCQEWFGNh QHVuaS1vc25hYnJ1ZWNrLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApLZx V6i214uWBb3c16AMckkujPKMXxl9Z4XsEIhrA47tG5YL9upeUrj+duDcrbEQvphvSXJFveVk LK1JMANHJuu/Wa32Bc8IRljYBqhaKMTGRO1q5L6jkMBDwBwenozhlGAaqG+8Cy+qcFoUaoWB RCH2++t5FtXyS1/1GKhWu7yQxCblFul7VXvnLKyaNlOaTalREXb9pQk2N31+rrOgwkbogxc2 z30gQAJXeJ2Ra0SlReqINMmcDd4lfluXjBpFmiJa4xHhQIVJpW2vF8dbqmeKqxIoYziBh78N GaqMSC8IbDPbCM3qaDaGUWKccgb/SKZvrNTLU+jcW66yGi1YPwIDAQABo4ICATCCAf0wEgYD VR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAowCDAGBgRVHSAAMB0G A1UdDgQWBBSqH9h3FW6Z5F+Q1uxjJk4Z6mcUUDAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp 9/EKcD7eZDAfBgNVHREEGDAWgRRjYUB1bmktb3NuYWJydWVjay5kZTCBiAYDVR0fBIGAMH4w PaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9j YWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHKMIHHMDMGCCsGAQUFBzABhidodHRw Oi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1AwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEApVPS1rUMH9oWu02nJHDV C7jF74wUYbzFaX1ULtkEGXK0MV2HyR8kZ3t19qcmEzgo/eaYv5+OE/nMnNHWUH/ybTN3bQFF K4+L+42SwRkSnyXVQsb38NsUknpDAlUeR9+jv5rkhIF5u+sRIXSB1lzoohtVUkYsC50UO1L4 bWchK7DE++22NDiTgtoFWwC1nn2wt8FYTB4IIbCOogEI6fFXIHZkG6BlLiYmPFmbNfPwNJpv 25g87P0SXpQR1uxSv4giL6o6XWCDJpnCEA4+029ZYLZG0e1bSzk4wI+ho08oxNs8B7NPlH2p jOpq40pZwvVw5rp2nu3W5CaDxgHdxXBX5DCCBYcwggRvoAMCAQICBxWm3SXtmbEwDQYJKoZI hvcNAQEFBQAwgZExCzAJBgNVBAYTAkRFMSAwHgYDVQQKExdVbml2ZXJzaXRhZXQgT3NuYWJy dWVjazEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEjMCEGA1UEAxMaVW5pLU9zbmFicnVlY2sg UlotQ0EgRy0wMDIxIzAhBgkqhkiG9w0BCQEWFGNhQHVuaS1vc25hYnJ1ZWNrLmRlMB4XDTEz MDUwNjA3NDUyNVoXDTE2MDUwNTA3NDUyNVowXjELMAkGA1UEBhMCREUxIDAeBgNVBAoTF1Vu aXZlcnNpdGFldCBPc25hYnJ1ZWNrMRYwFAYDVQQLEw1SZWNoZW56ZW50cnVtMRUwEwYDVQQD EwxEaXJrIEthc3RlbnMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZObhf0kwV d2daq89+nHsASWUXo8iLb+T9y2N5cmwkVMwAjgtTqjJu+P8jQOxxKaK35pWS5CB1HGiNqLms NOdMVqf1PXdnDANE//wGsMTKwKVjhYlj7PoPSuwAZ4NT8eTf/UR3ViPA64r9qCB8pYBO3L1w n6oMiXdWD8Vd7OVEVzGeMoVYstRyv+wzUAPJotGCd5smxEq+LMTv1HQ6xtZW2le5bMub4uk4 UdACPgCDBGP07sQvM8krM5fNOIbzNRyqD7eERnSMGkounpRkHSwoWUkt1njYUrxk1q4qMDBz xEIx4MPGPw57HN0VQ9z/3eUBjmZi+oqlxkDlHwzcvsH3AgMBAAGjggIUMIICEDAvBgNVHSAE KDAmMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIsAgEEAwAwCQYDVR0TBAIwADAL BgNVHQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ4 FSGPMJNnhKKMKGStCzA58jMkmjAfBgNVHSMEGDAWgBSqH9h3FW6Z5F+Q1uxjJk4Z6mcUUDAp BgNVHREEIjAggR5kaXJrLmthc3RlbnNAdW5pLW9zbmFicnVlY2suZGUwgY8GA1UdHwSBhzCB hDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmktb3NuYWJydWVjay1jYS9wdWIv Y3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS91bmktb3NuYWJy dWVjay1jYS9wdWIvY3JsL2NhY3JsLmNybDCBqAYIKwYBBQUHAQEEgZswgZgwSgYIKwYBBQUH MAKGPmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvdW5pLW9zbmFicnVlY2stY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MEoGCCsGAQUFBzAChj5odHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1v c25hYnJ1ZWNrLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEA pJjFnuZVVSPNqukqAI+ZWWClujzCsBdN1Zq95kik17FqjsB8TSqelmmohw1qBQXq3EnDFmWy R6FuNqYOPjborAEkhwRPmUXDDLvCU02TvwtxFuNJZc0ALz41oR8s8l5PBYoNlpPsYz+tsbKX +15XnsH1ftR/wzqaWPMLfWhG0OnLObeEMb+y5EQPO5kKzf+EdM/JmITWnip03FAtcr9JWq3N p6APfIDoWJ4uM5CyOvnEox41V+2a6PuOKY/bPE9seCOBbduWb15pXYZB7EHWM5Hkp5bLsl7s YtnFH++SCDLyutyLq4LCw1ryt7rLzkUEQ/YZOAqkfifDY6OdW3cRqzGCA/gwggP0AgEBMIGd MIGRMQswCQYDVQQGEwJERTEgMB4GA1UEChMXVW5pdmVyc2l0YWV0IE9zbmFicnVlY2sxFjAU BgNVBAsTDVJlY2hlbnplbnRydW0xIzAhBgNVBAMTGlVuaS1Pc25hYnJ1ZWNrIFJaLUNBIEct MDAyMSMwIQYJKoZIhvcNAQkBFhRjYUB1bmktb3NuYWJydWVjay5kZQIHFabdJe2ZsTAJBgUr DgMCGgUAoIICLzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0x NDEyMDkxMjA4MzNaMCMGCSqGSIb3DQEJBDEWBBS1sK6qItYHdIhly5VEIAAfT5rHjTBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGu BgkrBgEEAYI3EAQxgaAwgZ0wgZExCzAJBgNVBAYTAkRFMSAwHgYDVQQKExdVbml2ZXJzaXRh ZXQgT3NuYWJydWVjazEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEjMCEGA1UEAxMaVW5pLU9z bmFicnVlY2sgUlotQ0EgRy0wMDIxIzAhBgkqhkiG9w0BCQEWFGNhQHVuaS1vc25hYnJ1ZWNr LmRlAgcVpt0l7ZmxMIGwBgsqhkiG9w0BCRACCzGBoKCBnTCBkTELMAkGA1UEBhMCREUxIDAe BgNVBAoTF1VuaXZlcnNpdGFldCBPc25hYnJ1ZWNrMRYwFAYDVQQLEw1SZWNoZW56ZW50cnVt MSMwIQYDVQQDExpVbmktT3NuYWJydWVjayBSWi1DQSBHLTAwMjEjMCEGCSqGSIb3DQEJARYU Y2FAdW5pLW9zbmFicnVlY2suZGUCBxWm3SXtmbEwDQYJKoZIhvcNAQEBBQAEggEAhItoc2cm lCWjQhktZSEUd4TZLSMOptusxxA1zlMP6eMuE4YQOqGikpGQiEtCwKCgLlNHf0HxRotAEGro aJirxRgoq1eL8PbmrCJfuKf+kq1QUaz4ntiOHXNfbTyNyJ57nRRkIjP4zc8MQ2Y8E78/4N5p boiUwH68gT/cLE9RkZNgT0d2CCbD8rHi1PxKF0y8EC/a/KqPHYGlPGZGn2VfJD8ghLoXMfp8 nBaxvxonrj36+XFDt7crAq6EJ8rsClxf5Jwavv+2G0fpJaTdiEsw8v3N+AaAF0Dce6U+1sUT Tc06luAwQmtt5wJCSWM4WeWE+p1VmsrEr3mMmHeDticLRQAAAAAAAA== --------------ms060703010908070300060600--

1 0

Re: (ITS#7991) problem trying to call ldap_set_option
by shupilov＠tut.by 05 Dec '14

05 Dec '14

--Apple-Mail=_549A4F30-9945-4952-B8EB-604E90579662 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes, I wasn=E2=80=99t sure that is was a bug but just in the case: = ldap_open (deprecated) works fine with that =E2=80=9Clong=E2=80=9D = address despite of ldap_initialize. Sorry for off topic post. D. On 05 =D0=B4=D0=B5=D0=BA. 2014 =D0=B3., at 22:20, Howard Chu = <openldap-its(a)OpenLDAP.org> wrote: > The OpenLDAP-ITS address is for reporting bugs in OpenLDAP software. > Nothing in your report is indicative of a bug in OpenLDAP. > If you have questions about use of OpenLDAP Software which are > not answered in the documentation, FAQ, and archives, use the > OpenLDAP-technical list (subscription required; instructions here > <http://www.openldap.org/lists/mm/listinfo/openldap-technical>). >=20 > This issue report will be closed. >=20 > p. --Apple-Mail=_549A4F30-9945-4952-B8EB-604E90579662 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space;"><div>Yes, I wasn=E2=80=99t sure that is was a bug = but just in the case: ldap_open (deprecated) works fine with that = =E2=80=9Clong=E2=80=9D address despite of = ldap_initialize.</div><div><br></div><div>Sorry for off topic = post.</div><div><br></div><div>D.</div><br><div><div>On 05 =D0=B4=D0=B5=D0= =BA. 2014 =D0=B3., at 22:20, Howard Chu &lt;<a = href=3D"mailto:openldap-its@OpenLDAP.org">openldap-its(a)OpenLDAP.org</a>&am= p;gt; wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite">The OpenLDAP-ITS address is for reporting bugs in OpenLDAP = software.<br>Nothing in your report is indicative of a bug in = OpenLDAP.<br>If you have questions about use of OpenLDAP Software which = are<br>not answered in the documentation, FAQ, and archives, use = the<br>OpenLDAP-technical list (subscription required; instructions = here<br>&lt;<a = href=3D"http://www.openldap.org/lists/mm/listinfo/openldap-technical&g= t">http://www.openldap.org/lists/mm/listinfo/openldap-technical&gt</a>= ;).<br><br>This issue report will be = closed.<br><br>p.<br></blockquote></div><br></body></html>= --Apple-Mail=_549A4F30-9945-4952-B8EB-604E90579662--

1 0

Fwd: (ITS#7994) [LMDB] Feature Request: Access to current transaction ID.
by dmbarbour＠gmail.com 05 Dec '14

05 Dec '14

--f46d0434c0ba9e39c905097be220 Content-Type: text/plain; charset=UTF-8 I typedef'd MDB_txnid_t at the top of lmdb.h. The patch also tweaks MDB_envinfo. On Fri, Dec 5, 2014 at 11:58 AM, Howard Chu <hyc(a)symas.com> wrote: > > Thanks. There's a slight problem with the patch, your function returns > MDB_txnid_t but that is a private typedef in mdb.c. It is not defined in > lmdb.h, so no one will be able to compile and use this code. > > Easiest change would be to just return size_t, like MDB_envinfo uses. > --f46d0434c0ba9e39c905097be220 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"><br><div dir=3D"ltr">I typedef&= #39;d MDB_txnid_t at the top of lmdb.h. The patch also tweaks MDB_envinfo.<= span class=3D""><div><br></div><div><div class=3D"gmail_extra"><div class= =3D"gmail_quote">On Fri, Dec 5, 2014 at 11:58 AM, Howard Chu <span dir=3D"l= tr"><<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a= >></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"> Thanks. There's a slight problem with the patch, your function returns = MDB_txnid_t but that is a private typedef in mdb.c. It is not defined in lm= db.h, so no one will be able to compile and use this code.<br> <br> Easiest change would be to just return size_t, like MDB_envinfo uses.<span>= <font color=3D"#888888"><br></font></span></blockquote></div></div></div></= span></div> </div><br></div> --f46d0434c0ba9e39c905097be220--

1 0

Re: (ITS#7994) [LMDB] Feature Request: Access to current transaction ID.
by hyc＠symas.com 05 Dec '14

05 Dec '14

dmbarbour(a)gmail.com wrote: > Full_Name: David Barbour > Version: LMDB 0.9.10 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2602:306:80bb:160:d913:da7:da0f:76b3) > > > As discussed on the list [1], I believe access to the current transaction ID > could be very useful for layering features above LMDB, such as concurrent > writers, read-only to read-write promotion, or serving as an e-tag for polling. > > A patch David-Barbour-141205.patch has been uploaded and includes a disclaimer > to public-domain. > > [1] http://www.openldap.org/lists/openldap-devel/201412/msg00000.html > > Thanks. There's a slight problem with the patch, your function returns MDB_txnid_t but that is a private typedef in mdb.c. It is not defined in lmdb.h, so no one will be able to compile and use this code. Easiest change would be to just return size_t, like MDB_envinfo uses. -- -- 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#7994) [LMDB] Feature Request: Access to current transaction ID.
by dmbarbour＠gmail.com 05 Dec '14

05 Dec '14

Full_Name: David Barbour Version: LMDB 0.9.10 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2602:306:80bb:160:d913:da7:da0f:76b3) As discussed on the list [1], I believe access to the current transaction ID could be very useful for layering features above LMDB, such as concurrent writers, read-only to read-write promotion, or serving as an e-tag for polling. A patch David-Barbour-141205.patch has been uploaded and includes a disclaimer to public-domain. [1] http://www.openldap.org/lists/openldap-devel/201412/msg00000.html

1 0

Re: (ITS#7993) proxyauth with saslmech EXTERNAL not working
by hyc＠symas.com 05 Dec '14

05 Dec '14

dkastens(a)uos.de wrote: > Full_Name: Dirk Kastens > Version: 2.4.39 > OS: RedHat SL 6.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:638:508:3d0:12a:32c6:740c:8971) > > > We installed an ldap cluster with a mirrored master and several replicas on > RedHat SL 6.5 with openldap 2.4.23-34.el6_5.1.x86_64. Write requests to the > replicas are referred to the master server. The chain overlay follows the > referral. It connects with the saslmech EXTERNAL to the master. The master maps > the DN of the certificate to the replica admin. The replica admin has its > authzTo attribute set to the write admin. This way the writing perfectly worked > on our replica servers for all admins that are listed in the authzTo attribute. > Shortly the machines were updated to SL 6.6 with openldap 2.4.39-8.el6.x86_64. > The proxyauth stopped working. Write requests to the replica servers end with > the error > "ldap_modify: Other (e.g., implementationpepecific) error (80)". Without debug output from slapd there's no evidence of an OpenLDAP software bug here. Most likely the TLS library changed between your two versions and you're missing a TLS option now. Regardless, you're using a Red Hat build which contains their own unknown patches to the code. The OpenLDAP Project cannot support these builds since we don't know exactly what they are, but they are known to break OpenLDAP functionality on a routine basis. e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1095976 Ask Red Hat for support on their build. 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

(ITS#7993) proxyauth with saslmech EXTERNAL not working
by dkastens＠uos.de 05 Dec '14

05 Dec '14

Full_Name: Dirk Kastens Version: 2.4.39 OS: RedHat SL 6.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:638:508:3d0:12a:32c6:740c:8971) We installed an ldap cluster with a mirrored master and several replicas on RedHat SL 6.5 with openldap 2.4.23-34.el6_5.1.x86_64. Write requests to the replicas are referred to the master server. The chain overlay follows the referral. It connects with the saslmech EXTERNAL to the master. The master maps the DN of the certificate to the replica admin. The replica admin has its authzTo attribute set to the write admin. This way the writing perfectly worked on our replica servers for all admins that are listed in the authzTo attribute. Shortly the machines were updated to SL 6.6 with openldap 2.4.39-8.el6.x86_64. The proxyauth stopped working. Write requests to the replica servers end with the error "ldap_modify: Other (e.g., implementationpepecific) error (80)". I installed another replica under SL 7.0 with openldap-2.4.39-3.el7.x86_64: same result. When I configure the idassertbind attribute to use simple bind with a binddn and credentials, the proxyauth works. This is the chain configuration that doesn't work any longer: olcDbURI: "ldap://ldap-master" olcDbStartTLS: none starttls=no olcDbIDAssertAuthzFrom: {0}* olcDbIDAssertBind: mode=self bindmethod=sasl saslmech=EXTERNAL starttls=yes tls_cert="/etc/openldap/certs/ldap-replica.pem" tls_key="/etc/openldap/certs/ldap-replica.key" tls_cacert="/etc/openldap/cacerts/cacerts.pem" tls_cacertdir="/etc/openldap/cacerts" tls_reqcert=demand This is the configuration that works now: olcDbStartTLS: none starttls=no olcDbURI: "ldap://ldap-master" olcDbIDAssertAuthzFrom: {0}* olcDbIDAssertBind: mode=self bindmethod=simple binddn="cn=proxyuser" credentials="secret" starttls=yes tls_cert="/etc/openldap/certs/ldap-replica.pem" tls_key="/etc/openldap/certs/ldap-replica.key" tls_cacert="/etc/openldap/cacerts/cacerts.pem" tls_cacertdir="/etc/openldap/cacerts" tls_reqcert=demand I looked through the manual pages, but I didn't find a difference between 2.4.23 and 2.4.39. In 2.4.23 we had to load the chain module and now we load the back_ldap module. But that's all. Dirk

1 0

(ITS#7992) lmdb: Windows: assume file paths are UTF-8, encode to UTF-16 for WinAPI and enable compiling when UNICODE is defined
by oskari.timperi＠iki.fi 05 Dec '14

05 Dec '14

Full_Name: Oskari Timperi Version: OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/oskari-timperi-141205.zip Submission from: (NULL) (109.204.204.106) The patches make some changes so that compiling lmdb when UNICODE is defined is possible. This is achieved by using the A-versions of WinApi functions where they are needed. Also use CreateFileW to open files so that one can use exotic characters in paths. The library interface is not modified, but the code makes an assumption that paths passed to lmdb functions are encoded as UTF-8. The UTF-8 encoded paths are encoded to UTF-16 which is then passed to CreateFileW.

1 0

Re: (ITS#7974) LDBM's "laggard reader" flaw still present, in continue of ITS#7904
by h.b.furuseth＠usit.uio.no 04 Dec '14

04 Dec '14

On 12/04/2014 11:31 AM, leo(a)yuriev.ru wrote: > Could you suggest something other instead of "oomkiller"? Don't have a particularly good idea. oom_func, maybe. >> This feature could make it interesting to let readers and writers >> tell each other things: Reserve some unused space in the reader >> table slots for stuff the reader's caller could put there, and >> some space for an impatient writer to leave a note. Could go >> in an independent commit if there is any demand for it though. > > Communications between readers and writers may be interesting, but I > think it is over-engineering in the LMDB context. Yes... I guess I was thinking mostly of the prototype, in case we want to add something like it later. Might be useful to add a void* argument which would be NULL now but could be used later, if needed. -- Hallvard

1 0

Re: (ITS#7974) LDBM's "laggard reader" flaw still present, in continue of ITS#7904
by leo＠yuriev.ru 04 Dec '14

04 Dec '14

Hallvard, thank for your comments. 2014-12-02 14:20 GMT+03:00 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no>: > On 10/23/2014 07:13 AM, leo(a)yuriev.ru wrote: >> >> Subject: [PATCH 1/2] lmdb: ITS#7974 oomkiller feature. >> (...) >> +typedef int (MDB_oomkiller_func)(MDB_env *env, int pid, void* thread_id, >> size_t txn); > > > Some thoughts about this: > > Instead of trusting the return value, it seems safer to re-check > with mdb_reader_pid(). Like mdb_reader_check0() does. Maybe > except on Windows, where file locks from dead processes may > linger for a while until the OS reclaims them. I agree that usign mdb_reader_pid() is a better way. > Don't call it OOMkiller just because that's how you use it. > Others might do something else, like sending a reader a signal > which it interprets as "please wake up and finish your txn". > Or it might decide this process is the one which should give up. Could you suggest something other instead of "oomkiller"? Be noted, the "dreamcatcher" feature has a critical bug, which I has found and made fix while work on ITS#7968 & ITS#7987. Currently we hard testing a new code. So, in a week I plan to update both of the patches. > This feature could make it interesting to let readers and writers > tell each other things: Reserve some unused space in the reader > table slots for stuff the reader's caller could put there, and > some space for an impatient writer to leave a note. Could go > in an independent commit if there is any demand for it though. Communications between readers and writers may be interesting, but I think it is over-engineering in the LMDB context. IMHO the LMDB's code has a lot of technical debt, so it is more usefull to re-implement all of from a scratch, under a rules of perfectly-clean codestyle. May be I will do this, but on a basis and after a release of 1Hippeus - it is a extreme performance engine for zero-copy mesaging in a shared memory, partially like Intel DPDK. Leonid.

1 0

(ITS#7991) problem trying to call ldap_set_option
by shupilov＠tut.by 03 Dec '14

03 Dec '14

Full_Name: Dmitry Shupilov Version: 2.4.39 OS: RHEL 6.5 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.57.254.70) Hello all! It's my first time to post here, so sorry if I will do something wrong :) I have to write shared library which task is to check if the user is correct LDAP user. First of all I prepare env and call ldap_initialize - nothing special here. The ldap_create function sets ld properly (e.g. ld = '0x7fffe40837d0') and in gdb I can read it by (p *ld) or even deeper (p *ld.ldc). But the next function cannot do its job - ldap_set_option failed with "-1" status. I tried to create separate binary which use my shared *.so to do the same job - check a user in LDAP and it works fine: ldap_create assigns "short" address (e.g. 0x602a30). In this case ldap_set_option do what it needs to do. My question is: is the problem of ldap_set_option in that "very long value of address" or is something else? How can I catch the reason of this problem and solve it? BR, Dmitry

1 0

(ITS#7990) (docs) Admin guide: bad link in password policy overlay section
by frederic.poisson＠admin.gmessaging.net 02 Dec '14

02 Dec '14

Full_Name: Frederic POISSON Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.51.12.20) Hello, I'm looking to Password Policy overlay and admin guide 2.4, and i see that Howard CHU has corrected a link (ITS#6264) about "Password Management Issues". But on that link on Symas blog i do not see anything on that subject ? I have also another question about Password policy draft. Does OpenLDAP project already receive a feature request to support the draft in release 10 ? Thanks, Regards,

1 0

Re: (ITS#7974) LDBM's "laggard reader" flaw still present, in continue of ITS#7904
by h.b.furuseth＠usit.uio.no 02 Dec '14

02 Dec '14

On 10/23/2014 07:13 AM, leo(a)yuriev.ru wrote: > Subject: [PATCH 1/2] lmdb: ITS#7974 oomkiller feature. > (...) > +typedef int (MDB_oomkiller_func)(MDB_env *env, int pid, void* thread_id, size_t txn); Some thoughts about this: Instead of trusting the return value, it seems safer to re-check with mdb_reader_pid(). Like mdb_reader_check0() does. Maybe except on Windows, where file locks from dead processes may linger for a while until the OS reclaims them. Don't call it OOMkiller just because that's how you use it. Others might do something else, like sending a reader a signal which it interprets as "please wake up and finish your txn". Or it might decide this process is the one which should give up. This feature could make it interesting to let readers and writers tell each other things: Reserve some unused space in the reader table slots for stuff the reader's caller could put there, and some space for an impatient writer to leave a note. Could go in an independent commit if there is any demand for it though. -- Hallvard

1 0

Re: (ITS#7987) SIGSEGV in LMDB while adding ldap-entries
by leo＠yuriev.ru 02 Dec '14

02 Dec '14

This is a multi-part message in MIME format. --------------090506050608000200000309 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit (1) I can сonfirm once again - the bug is fixed. (2) Previously noted failure "DN index delete failed" caused by another (local) bug. (3) Feature "single write txn" need a minor fix, patch attached. Leonid. --- The attached files is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Peter-Service LLC, Moscow, Russia. Peter-Service LLC has not assigned rights and/or interest in this work to any party. I, Leonid Yuriev am authorized by Peter-Service LLC, my employer, to release this work under the following terms. Peter-Service LLC hereby places the following modifications to OpenLDAP Software (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. --------------090506050608000200000309 Content-Type: text/x-patch; name="excessive-space-single-write-txn.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="excessive-space-single-write-txn.patch" commit 02094a10018e1ebcae32b920f9d93d300a810f29 Author: Leo Yuriev <leo(a)yuriev.ru> Date: 2014-12-02 14:02:02 +0300 fix excessive space (likely a typo) for single write txn. diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 6e9119d..7587434 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -4589,7 +4589,7 @@ mdb_env_open(MDB_env *env, const char *path, unsigned int flags, mdb_mode_t mode if (!(flags & MDB_RDONLY)) { MDB_txn *txn; int tsize = sizeof(MDB_txn), size = tsize + env->me_maxdbs * - (sizeof(MDB_db)+sizeof(MDB_cursor)+sizeof(unsigned int)+1); + (sizeof(MDB_db)+sizeof(MDB_cursor *)+sizeof(unsigned int)+1); txn = calloc(1, size); if (txn) { txn->mt_dbs = (MDB_db *)((char *)txn + tsize); --------------090506050608000200000309--

1 0

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 02 Dec '14

02 Dec '14

> 2014-12-02 6:09 GMT+03:00 Howard Chu <hyc(a)symas.com>: >> Leonid Yuriev wrote: >>> Partially fixed. >>> Patch is for current OPENLDAP_REL_ENG_2_4, but applicable for master. >> >> Thanks, the patch makes sense. But if only partial, what else is still >> crashing? > Stable crash in a 5 seconds after the 4x-cluster resumes from > split-brain condition: > > Program terminated with signal SIGSEGV, Segmentation fault. > #0 __memcpy_sse2_unaligned () at > ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116 > 116 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: Нет такого > файла или каталога. > (gdb) bt > #0 __memcpy_sse2_unaligned () at > ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116 > #1 0x00000000004aee11 in memcpy (__len=<optimised out>, > __src=<optimised out>, __dest=<optimised out>) at > /usr/include/x86_64-linux-gnu/bits/string3.h:51 > #2 mdb_search (op=0x7f16b4ffa7c0, rs=0x7f16b4e697b0) at search.c:993 Seems to be fixed completely. The last SIGSEGV is inducted by a "dreamcatcher" feature (ITS#7974). I already fixed the "dreamcatcher", currently we are re-testing it. Leonid.

1 0

Fwd: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 01 Dec '14

01 Dec '14

2014-12-02 6:09 GMT+03:00 Howard Chu <hyc(a)symas.com>: > Leonid Yuriev wrote: >> >> Partially fixed. >> Patch is for current OPENLDAP_REL_ENG_2_4, but applicable for master. > > > Thanks, the patch makes sense. But if only partial, what else is still > crashing? Stable crash in a 5 seconds after the 4x-cluster resumes from split-brain condition: Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116 116 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: =D0=9D=D0=B5=D1=82= =D1=82=D0=B0=D0=BA=D0=BE=D0=B3=D0=BE =D1=84=D0=B0=D0=B9=D0=BB=D0=B0 =D0=B8=D0=BB=D0=B8 =D0=BA=D0=B0=D1=82=D0=B0= =D0=BB=D0=BE=D0=B3=D0=B0. (gdb) bt #0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116 #1 0x00000000004aee11 in memcpy (__len=3D<optimised out>, __src=3D<optimised out>, __dest=3D<optimised out>) at /usr/include/x86_64-linux-gnu/bits/string3.h:51 #2 mdb_search (op=3D0x7f16b4ffa7c0, rs=3D0x7f16b4e697b0) at search.c:993 #3 0x000000000048a52a in overlay_op_walk (op=3Dop@entry=3D0x7f16b4ffa7c0, rs=3D0x7f16b4ff9c40, which=3Dop_search, oi=3D0xc31a30, on=3D<optimised out>= ) at backover.c:676 #4 0x000000000048a681 in over_op_func (op=3D0x7f16b4ffa7c0, rs=3D<optimised out>, which=3D<optimised out>) at backover.c:729 #5 0x000000000047de37 in syncrepl_del_nonpresent (op=3D0x7f16b4ffa7c0, si=3D0xc31490, uuids=3D<optimised out>, m=3D3, sc=3D<optimised out>, sc=3D<optimised out>) at syncrepl.c:3400 #6 0x0000000000481a0e in do_syncrep2 (op=3D0x7f16b4ffa7c0, si=3D0xc31490) at syncrepl.c:1346 #7 0x00000000004839e3 in do_syncrepl (ctx=3D<optimised out>, arg=3D0xc319d0) at syncrepl.c:1550 #8 0x00007f170283ecf2 in ldap_int_thread_pool_wrapper (xpool=3D0xbe4090) at tpool.c:688

1 0

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by hyc＠symas.com 01 Dec '14

01 Dec '14

Leonid Yuriev wrote: > Partially fixed. > Patch is for current OPENLDAP_REL_ENG_2_4, but applicable for master. Thanks, the patch makes sense. But if only partial, what else is still crashing? > > Leonid. > > -- > > The attached files is derived from OpenLDAP Software. All of the > modifications > to OpenLDAP Software represented in the following patch(es) were > developed by > Peter-Service LLC, Moscow, Russia. Peter-Service LLC has not assigned > rights > and/or interest in this work to any party. I, Leonid Yuriev am > authorized by > Peter-Service LLC, my employer, to release this work under the following > terms. > > Peter-Service LLC hereby places the following modifications to OpenLDAP > Software > (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. > > > -- -- 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#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 01 Dec '14

01 Dec '14

This is a multi-part message in MIME format. --------------040002050003040401050402 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Partially fixed. Patch is for current OPENLDAP_REL_ENG_2_4, but applicable for master. Leonid. -- The attached files is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Peter-Service LLC, Moscow, Russia. Peter-Service LLC has not assigned rights and/or interest in this work to any party. I, Leonid Yuriev am authorized by Peter-Service LLC, my employer, to release this work under the following terms. Peter-Service LLC hereby places the following modifications to OpenLDAP Software (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. --------------040002050003040401050402 Content-Type: text/x-patch; name="slapd-syncrepl-locking.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="slapd-syncrepl-locking.patch" commit e845cfba8b8c17d291fb810b762e2d2bdb22b016 Author: Leo Yuriev <leo(a)yuriev.ru> Date: 2014-12-01 19:26:08 +0300 ITS#7968: add locking into syncrepl. Mutex must be held even for a read-access of a cookie state, as there may be a race with write in other thread. diff --git a/servers/slapd/syncrepl.c b/servers/slapd/syncrepl.c index caab9f5..eb7bec2 100644 --- a/servers/slapd/syncrepl.c +++ b/servers/slapd/syncrepl.c @@ -926,6 +926,7 @@ do_syncrep2( if ( syncCookie.ctxcsn ) { int i, sid = slap_parse_csn_sid( syncCookie.ctxcsn ); check_syncprov( op, si ); + ldap_pvt_thread_mutex_lock( &si->si_cookieState->cs_mutex ); for ( i =0; i<si->si_cookieState->cs_num; i++ ) { /* new SID */ if ( sid < si->si_cookieState->cs_sids[i] ) @@ -935,15 +936,18 @@ do_syncrep2( bdn.bv_val[bdn.bv_len] = '\0'; Debug( LDAP_DEBUG_SYNC, "do_syncrep2: %s CSN too old, ignoring %s (%s)\n", si->si_ridtxt, syncCookie.ctxcsn->bv_val, bdn.bv_val ); + si->si_too_old = 1; + ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_mutex ); ldap_controls_free( rctrls ); rc = 0; - si->si_too_old = 1; goto done; } si->si_too_old = 0; break; } } + ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_mutex ); + /* check pending CSNs too */ while ( ldap_pvt_thread_mutex_trylock( &si->si_cookieState->cs_pmutex )) { if ( slapd_shutdown ) { @@ -953,6 +957,8 @@ do_syncrep2( if ( !ldap_pvt_thread_pool_pausecheck( &connection_pool )) ldap_pvt_thread_yield(); } + + ldap_pvt_thread_mutex_lock( &si->si_cookieState->cs_mutex ); for ( i =0; i<si->si_cookieState->cs_pnum; i++ ) { if ( sid < si->si_cookieState->cs_psids[i] ) break; @@ -961,9 +967,10 @@ do_syncrep2( bdn.bv_val[bdn.bv_len] = '\0'; Debug( LDAP_DEBUG_SYNC, "do_syncrep2: %s CSN pending, ignoring %s (%s)\n", si->si_ridtxt, syncCookie.ctxcsn->bv_val, bdn.bv_val ); + ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_mutex ); + ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_pmutex ); ldap_controls_free( rctrls ); rc = 0; - ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_pmutex ); goto done; } ber_bvreplace( &si->si_cookieState->cs_pvals[i], @@ -978,6 +985,7 @@ do_syncrep2( (struct sync_cookie *)&si->si_cookieState->cs_pvals, i, sid, syncCookie.ctxcsn ); } + ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_mutex ); assert( punlock < 0 ); punlock = i; } else if (si->si_too_old) { @@ -1032,6 +1040,7 @@ do_syncrep2( /* on failure, revert pending CSN */ if ( rc != LDAP_SUCCESS ) { int i; + ldap_pvt_thread_mutex_lock( &si->si_cookieState->cs_mutex ); for ( i = 0; i<si->si_cookieState->cs_num; i++ ) { if ( si->si_cookieState->cs_sids[i] == si->si_cookieState->cs_psids[punlock] ) { ber_bvreplace( &si->si_cookieState->cs_pvals[punlock], @@ -1041,6 +1050,7 @@ do_syncrep2( } if ( i == si->si_cookieState->cs_num ) si->si_cookieState->cs_pvals[punlock].bv_val[0] = '\0'; + ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_mutex ); } ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_pmutex ); } --------------040002050003040401050402--

1 0

Re: (ITS#7989) wrong search results "scope one" with mdb backend
by quanah＠zimbra.com 01 Dec '14

01 Dec '14

--On Monday, December 01, 2014 4:04 PM +0000 dab1818(a)gmail.com wrote: > Full_Name: Dmitry Bakshaev > Version: 2.4.38, 2.4.40 > OS: gentoo linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (87.249.250.7) Duplicate of ITS#7975, fixed in master, closing. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7989) wrong search results "scope one" with mdb backend
by dab1818＠gmail.com 01 Dec '14

01 Dec '14

Full_Name: Dmitry Bakshaev Version: 2.4.38, 2.4.40 OS: gentoo linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.249.250.7) slapd.conf: include /etc/openldap/schema/core.schema pidfile /tmp/openldap-data-test/slapd.pid argsfile /tmp/openldap-data-test/slapd.args database mdb directory /tmp/openldap-data-test suffix "c=ru" index objectClass eq test.ldif: dn: c=ru objectClass: country c: ru dn: o=org,c=ru objectClass: organization o: org dn: ou=unit,o=org,c=ru objectClass: organizationalUnit ou: unit dn: ou=subunit,ou=unit,o=org,c=ru objectClass: organizationalUnit ou: subunit dn: cn=pers,ou=unit,o=org,c=ru objectClass: person cn: pers sn: pers load test.ldif: slapadd -f slapd.conf -l test.ldif -q run slapd: /usr/lib/openldap/slapd -f slapd.conf -d 127 -h "ldap:///" execute query: ldapsearch -H ldaps://localhost -b ou%ununit,o=org,c=ru -s one "(objectclass=organizationalUnit)" result contains wrong data (expects only ou=subunit,ou=unit,o=org,c=ru): # unit, org, ru dn: ou=unit,o=org,c=ru objectClass: organizationalUnit ou: unit # subunit, unit, org, ru dn: ou=subunit,ou=unit,o=org,c=ru objectClass: organizationalUnit ou: subunit # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 worked as expected: 1. on openldap-2.4.35 (with mdb 0.9.6) or below; or 2. with "database bdb"; or 3. without "index objectClass eq".

1 0

Re: (ITS#7832) Proposing ppolicy extended module for OpenLDAP
by dcoutadeur＠linagora.com 01 Dec '14

01 Dec '14

Hi, I am considering solutions to give the password policy module its configuration in cn=config, and not in a flat configuration file. However, If I create a ppm.la overlay to register a ppm configuration schema, I won't be able to read it in the ppm.so which is loaded dynamically by the ppolicy overlay. Indeed, ppolicy is dynamically including the ppm.so code through libtool, so there is no link at all between ppm.so and ppm.la. Does anybody have an idea on how a module called by the ppolicy could read some configuration in cn=config ? Thanks in advance ! David Le 12/11/2014 10:41, David Coutadeur a écrit : > > Hi, > > The ppm module is still alive, and is evolving. > Last version is 1.2, and source code is now available on Github : > > https://github.com/davidcoutadeur/ppm > > There are also plans to package it. > If anybody is interrested, I am always glad to hear about comments, > ideas, improvements,... > > Sincerely, > > David

1 0

Re: (ITS#7987) SIGSEGV in LMDB while adding ldap-entries
by leo＠yuriev.ru 30 Nov '14

30 Nov '14

Previously noted (2) and (3) was caused by following patch. It is a trial from Howard Chu for workout on ITS#7968 ;) Under a heavy load of add/delete it may induce "DN index delete failed" in the mdb backend. > Message-ID: <5440D299.60208(a)symas.com> > Date: Fri, 17 Oct 2014 09:26:01 +0100 > From: Howard Chu <hyc(a)symas.com> > > Can you try this patch and followup again? > >> diff --git a/servers/slapd/overlays/syncprov.c >> b/servers/slapd/overlays/syncprov.c >> index e15020e..b54c83f 100644 >> --- a/servers/slapd/overlays/syncprov.c >> +++ b/servers/slapd/overlays/syncprov.c >> @@ -1306,11 +1306,12 @@ syncprov_matchops( Operation *op, opcookie >> *opc, int saveit ) >> op2.o_hdr = &oh; >> op2.o_extra = op->o_extra; >> op2.o_callback = NULL; >> - if (ss->s_flags & PS_FIX_FILTER) { >> + if ((ss->s_flags & PS_FIX_FILTER) >> + && op2.ors_filter->f_choice == >> LDAP_FILTER_AND) { >> /* Skip the AND/GE clause that we >> stuck on in front. We >> would lose deletes/mods that >> happen during the refresh >> phase otherwise (ITS#6555) */ >> - op2.ors_filter = >> ss->s_op->ors_filter->f_and->f_next; >> + op2.ors_filter = >> op2.ors_filter->f_and->f_next; >> } >> ldap_pvt_thread_mutex_unlock( &ss->s_mutex ); >> rc = test_filter( &op2, e, op2.ors_filter );

1 0

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 29 Nov '14

29 Nov '14

This is a multi-part message in MIME format. --------------010409020705090508090802 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Some of Valgrind's DRD output, seems be enough to crash around connect/disconnect and walking on overlays. --------------010409020705090508090802 Content-Type: application/gzip; name="valgrind-drd.log.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="valgrind-drd.log.gz" H4sICJ8XelQAA3ZhbGdyaW5kLWRyZC5sb2cA7V3bcuO4EX3PV/At3lRkgSB4U2pqQ922tmqS naq9VB5SxaJJ2GZGIrUk5bHz9WmQ1IUayNY6HluSjx9kXdgkgO7TOH0kgB8+uMz1P3wwkiL5 qxEZ1W0ho8SQRZEXRiIrGVd58acPq6NG+eKhSG9uK+Ni9J3BGXN6nJkWWWaJ8cM/fzV++PTx z3SiqwdjGBWV8VuUGUFZxrfycnOSX8s0u6GPZjdFmiU969Jkl6w+w8f06rfJv/5mFLJYZsaX tLo1erfGNTUlXl84za7z7QbN52Q5MPq3+Vz2Zw/9T0X+H2p12f/4j/GwV8myiqNSXt6kVV+9 6N1FSTrv38pC9spZtEj6s/RK3su4X78yejPj40+j4KNt9BKDGb1SPQjVjFkSLQb9PjWWX7JL c2DSH+//e/0+d+nt+gNm+bxv9K6f1agkqqJ+licy5H1Ztc26jPPsetPrT1Ehs8r49ON4YDi+ zzafbJ790nhSDLYHK7uepXGlhr8kv0rlp9bjwogqg90zh8vYkrFRpv+VhtjY0l99gDCnLHAG hmpWOEvLSmayMC6SSM7z7DIemJ7wvuuY0TVqM2/CdszC9toba848X2c9sb0xNwf1WIdpVrWW 4SLPZ+GXIlosVCMq9ZLO4njaJows0w2GA+P77783LtLM6C/LQnm/f9eGYv/uZlHIWU4nJjj0 onniiN4szZb3l2WuOaPNh4wFgnpVUbCve7NoGxfTYyWpPRbTdcq2R8wTo4ERz/JMGhf1v8uf VVxtHR0kSSFLisL7lWfSUnkiv74uZWUIYVwX+Xz1ccwujWA2y+OoSvOMUJNV8r4aaNw44uPp mBwyj9ThLzQeLDDJ/wPjinw7l82pw3vjgp7nxYPyL9d6xppMxwENxG24as76KRnZQhtQk0BY bUDlC5lpg9H2mM6Wm97UbGypa/XRFFVptW3quNpIZAFvho0G7EI90rGu2PbYTxXh2CjlzVxh tA4NCs0mNvh3OldYYjqm5qziZr4kp4XLjHr/+WUcIzgLht5Oh6uo/LwNPXFGqOn6QNLU8pgH 1Dkn3Gr7WD6UMYUeZen5Yqaa8vPAM/WDyqbTJwbVtpwzHdTDAtsy2W5gv2BYm1NKHE+FtWWd qQeeCuvXSSyM8ac8YJ9PYvmKX7l7+JVq9ha9clf0yvKkbbGGXnmaVGQyPqRGlA9ZvCjyu/D3 ZjRXr9XMxJh2QgRHIhLUDm+HI7E1RWo+PZgiWYyNKH3FL02RphuKFGs4kqdNWNaUuHnNkWIN RzL1MUHeHBFZv4riz5QtwuSqpTntG4pc+doJisLQplaqsiO9CW8Ur0rpklfNGzW14lxrGDgj vjak4Q9pqEpq7MrQsrXdM8eW5Q6MJiga4+t0JrcMXV87C5vOyJ52DLebKbiljXOicfZol8b5 /MDZznqjbDvmPqe+zsmP1KjiISxktSyoB2nC6zdqyqHtMJk6oms6k1SDdm19Lef1iPPSNJvf yWIWPXTtw/yuCSf1qRpwSxuInjkcW01aK+Ri1pyjSWvqdR32rta/rWWSh+3BvGNGgaq/oOWr iWljNuua2Za2q9xmE7cO34zqdUoQYe3LVdravK/OwX1tKL/fRLyfn+xDzLflh95w6K5qxN+X cinDuCS0xNU9/Vce1KcUd+RzthWsy0VCYzPK88+p7ESR5Tra4HOnTCWzR2JW63PE7OvH7Lcm dBThNLabKXjLS7tTsW9qp2JOM+a4497GsONX29WLJFMxEfvFOk7Nh1gHIgoiCiL6hybWie1O VGdriC/uuhAvl1dz5dsVwi2hc5DNhiPH3a50CTqLnUrX18m3tmmORt6W5Tyq4tt8UXaNLS0T tU0eTPiWcb4I1YXzrJRde18/21rW0GsVj7VhuCBebFzQy+WsUrHM9DK3YBOfTBUC6pHbXHhj ugd0IvBaxTrs2JPVlrXnaENz5E0mXkP+o4SSHj3UVF0LHC8Qwt6wfRqfL9Hsc4fkO3uoemAP WWOpzK6XWdwxc7m2bx5zV5LH3tpAz7NaywNrgz/OTr+5ejYa2jTHRVVVhG0uVc+VI7UBxMc2 c9vj57K4kevjhWtriajgPnVhnifp9YPyvUqCS0lIobfK+msOrScD1/SDJmBaW5rHZZFFs9qS 3qhttY0M3MnY2bbdMnH2RMBrhxwx/OGBDF+Px5Nh+Ec4e6j8zZyn87epC2nk73ebv48GRW8u bBB3ClRX0ixuzk3ZuRP8rqsj0yuzRymXrSVroFyA7OtB9mUVGM/31mO0Bf6vxsrT1ilKwHEm Bwo4LgQcCDgQcCDgQMCBgAM2AQEHAg4EHAg4yN/I38eEIgg4oFyA7CkJOGP7IAFHW4FCwIGA AwEHAg4EHAg4YBMQcCDgHEHIQcCBgIP8fWL5+2hQBAEHlAuQfRUBp10WZR24j5B1uKgzUes6 63GL4piK9pqAfZFJZ/gsrt3BRYihS4PQNSRMqLXyUaw6JGy9IR8O6bJq16WQEE9hFUtVXlZK EWn+r1bDelzr8O0z6A1NLRIUglfLCh+ddLWJAwh+rwiGpAVJ61UlrR0N/NVqcXM85WK1l0wN +LXQ7ekLXSXM208L83pXQphfw/ZNtwZ4q3Cj4BHu08GjVXUQPG8YPMhWCDhkK2SrYw2er2pn 57AtRZyDtxSxAodI4bUMo+W92vy0qNm++mpgQ31NX2iDwWJ1FlqR5r3W+hxm2fa4U9CVMiqI qrfFz7qiMxnTl7HMdfytMlad4ysJzPP1uvOO7e9N+bpl6Au9+rVrqNlTz9SqBe83iFF1oup8 Dz+kwFdhUOXwVRi+CgNkAVk9ZDFpAQHvGwGYtDBpAbInBdmXFZxojETw2BiZ2qG1rMCzD9Cp tItuoFNBp4JOBZ0KOhUoP/gDKD8oPyALyEKnAgKAAExamLQA2XOA7IvrVK54VKfS/yQKOhV0 KuhUm8kDOhV0KlB+8Ifj5w+g/KD8gOxJQRaTFhDwvhGASQuTFiB7UpDdPGvX9HmHrenzDpWu KBc4rNagaNCiqyhLqPC/aJ/UkayVrjgXbNjJIGvbTvZw9eIVWY+9jnk8y0vVj665p9+Fh4vR cPJV/tpNXEIL/T3G+5Kfp3Ui9CToSdCTzllPwkbHYBmnxzKw0TE2Ol6Ny7vZ6PhlCfEz1xxQ B1znUR6tJ6Pg0eDR4NHg0eDR4NHg0eDR4NHg0efCo5/zm0jwaPBo8GjwaPBo8GjwaPBo8Gjw 6JPl0e1vNvhhv9ngK2rNZWxJbz+1NqdTx1ltAd9siB02S2E2u2ML7RKak+d47dB0OJ7YkDz1 cXw4yePj6ZgpJvDCJM/bkDwNx9PHqTWZjoOa4801HM/W3+R7EgirnaLyhcx0u6ybtqevWUxv au4EUUMQN6aOq8UGEahm2LYJlDj0xgn2G2V+zxra7iOJwBFYOnbgzQj2uNCeWJONCwl4CU0q afX3v7wYBfbGLj/YFfr5+QxcATydgROBp6NxxdM39qnPappfndX7/27e8k1/Gi+4JTz/yVu3 CL0GhFu3HEs8ijfK78obpnO4N7RxdAbe2AayzhfUImdsj9s+lg+l0mh7lZwvZqopO0liCyps ZO9HGNUQWowAYUDYuXkDCDs/nwJhx+QNIOwcfPoMFTluVGShgR9nzOVPqMh7vug9ydHbVZHj HRVZQEWGigzVC6rXu1S9gKeTdCLwdDSugIoMFfl44xEV+PEkalTg5+FTIOyYvAGEnZ9PgbBj 8gYQdn4+BcKOyRtA2Dn4dPPsl+b0zmELAA6+34jFzSDYLO2Lb2X8Wa1Mqoq0rsjLzi1AmNAG hTCH7mi10vYqVZGnHusVGPqluaZte7VU1zmaM/0OkcLlVkc3WN+iZHf5BJ0XAYRFrVjU2hi+ o0WtWI3XfguC1XjHsWH5MyR6IAlIApLOBkm4Jwe2OuhY4p4cuCcHIAvIauSdF7p37HP2G7a4 qXYNO1gC0noWEhAkIEhAkIBQuKJwReF64oUrkAQkAUmQgFBPnlg9+frAhAQEyAKyxyQBPWer fEhAkIAgAUECggSEwhWFKwpXIAlIApIgAaGePLl68vWBCQkIkAVkj0YCEubQs/UyjH7jNcgw kGEgw0CGQfGI4hHFI5AEJAFJ54ckyDCo6SDDQIYBZAHZI16MJUxCyx71RjuoUG+g3kC9gXqD mhM1J2pOIAlIApLOD0lQb1AKQr2BegPIArJHvI4K6g3UG6g3UG9Qc6LmRM154jUnkAQkAUlQ b1AKnlgp+PrAhHoDyAKyfxyy/wMt47cXvE0BAA== --------------010409020705090508090802--

1 0

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 29 Nov '14

29 Nov '14

Program terminated with signal 11, Segmentation fault. #0 0x00007ffda90d607b in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007ffda90d607b in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x000000000047fb7c in do_syncrep2 (op=0x7ffd68cf5740, si=0x1681d00) at syncrepl.c:893 #2 0x0000000000483903 in do_syncrepl (ctx=<optimised out>, arg=0x1682090) at syncrepl.c:1551 #3 0x00000000004250e8 in connection_input (cri=<optimised out>, conn=<optimised out>) at connection.c:1732 #4 connection_read (cri=<optimised out>, s=<optimised out>) at connection.c:1460 #5 connection_read_thread (ctx=0x7ffd68cf5bd0, argv=0x25) at connection.c:1284 #6 0x00007ffda9777d22 in ldap_int_thread_pool_wrapper (xpool=0x1635090) at tpool.c:688 #7 0x00007ffda93420a5 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #8 0x00007ffda906f84d in clone () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) frame 1 #1 0x000000000047fb7c in do_syncrep2 (op=0x7ffd68cf5740, si=0x1681d00) at syncrepl.c:893 893 Debug( LDAP_DEBUG_ANY, "do_syncrep2: %s malformed message (%s)\n", (gdb) info locals syncUUID = {{bv_len = 16, bv_val = 0x7ffd543a98b7 "\177]\201N\f'\020\064\235\255Չ\v\247\331", <incomplete sequence \351>}, {bv_len = 128849018894, bv_val = 0x7ffd68cf4ec4 "\375\177"}} cookie = {bv_len = 60, bv_val = 0x7ffd543a98c9 "rid=002,sid=002,csn=20141129152404.971057Z#000000#001#000000"} rctrls = 0x7ffd543f7130 bdn = {bv_len = 33, bv_val = 0x7ffd543706f7 "cn=modem,uid=4711,dc=ngdr,dc=ldap"} si_tag = 1 syncstate = 3 retdata = 0x7ffd68cf57c0 retoid = 0xb <Address 0xb out of bounds> syncUUIDs = 0x7ffd68cf57c0 len = 60 berbuf = { buffer = "\002\000\001", '\000' <repeats 29 times>, "\260\230:T\375\177\000\000\005\231:T\375\177\000\000\005\231:T\375\177", '\000' <repeats 34 times>, "i\215\064\251\375\177\000\000\000\000\000\000\000\000\000\000x\021V\251\375\177\000\000\340\022h\001", '\000' <repeats 36 times>, "\060S\317h\375\177\000\000Q\020", '\000' <repeats 14 times>, "X", '\000' <repeats 15 times>, "\300U\317h\375\177\000\000"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} msg = 0x7ffd543f3c50 syncCookie = {ctxcsn = 0x7ffd543f3f10, sids = 0x7ffd542eb890, numcsns = 1, rid = 2, octet_str = {bv_len = 60, bv_val = 0x7ffd5440f6d0 "rid=002,sid=002,csn=20141129152404.971057Z#000000#001#000000"}, sid = 2, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x7ffd5440f380, sids = 0x7ffd542ebae0, numcsns = 5, rid = 2, octet_str = {bv_len = 224, bv_val = 0x7ffd543714e0 "rid=002,sid=004,csn=20141129152404.970764Z#000000#001#000000;20141129151341.491595Z#000000#002#000000;20141129151341.507685Z#000000#003#000000;20141129151341.523508Z#000000#004#000000;20141129151341.5"...}, sid = 4, sc_next = {stqe_next = 0x0}} rc = 100 err = 0 modlist = 0x0 m = 32765 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 empty = "empty" (gdb) p *si $1 = {si_next = 0x1682200, si_be = 0x1680940, si_wbe = 0x1680940, si_re = 0x1682090, si_rid = 2, si_ridtxt = "rid=002", si_bindconf = {sb_uri = {bv_len = 22, bv_val = 0x16816b0 "ldap://10.2.0.1:11113/"}, sb_version = 3, sb_tls = 0, sb_method = 128, sb_timeout_api = 10, sb_timeout_net = 0, sb_binddn = {bv_len = 19, bv_val = 0x1681690 "uid=replica,dc=ldap"}, sb_cred = {bv_len = 3, bv_val = 0x1682110 "xyz"}, sb_saslmech = {bv_len = 0, bv_val = 0x0}, sb_secprops = 0x0, sb_realm = {bv_len = 0, bv_val = 0x0}, sb_authcId = {bv_len = 0, bv_val = 0x0}, sb_authzId = {bv_len = 0, bv_val = 0x0}, sb_keepalive = {sk_idle = 1, sk_probes = 1, sk_interval = 1}, sb_tls_ctx = 0x0, sb_tls_cert = 0x0, sb_tls_key = 0x0, sb_tls_cacert = 0x0, sb_tls_cacertdir = 0x0, sb_tls_reqcert = 0x0, sb_tls_cipher_suite = 0x0, sb_tls_protocol_min = 0x0, sb_tls_crlcheck = 0x0, sb_tls_do_init = 0}, si_base = {bv_len = 15, bv_val = 0x1682030 "dc=ngdr,dc=ldap"}, si_logbase = { bv_len = 0, bv_val = 0x0}, si_filterstr = {bv_len = 15, bv_val = 0x1681200 "(objectclass=*)"}, si_filter = 0x1682010, si_logfilterstr = {bv_len = 0, bv_val = 0x0}, si_contextdn = {bv_len = 7, bv_val = 0x16811e0 "dc=ldap"}, si_scope = 2, si_attrsonly = 0, si_anfile = 0x0, si_anlist = 0x1682130, si_exanlist = 0x1681fc0, si_attrs = 0x169f0f0, si_exattrs = 0x0, si_allattrs = 1, si_allopattrs = 1, si_schemachecking = 0, si_type = 3, si_ctype = 3, si_interval = 60, si_retryinterval = 0x1681ff0, si_retrynum_init = 0x1682070, si_retrynum = 0x1682050, si_syncCookie = { ctxcsn = 0x7ffd7c1d87d0, sids = 0x7ffd54411150, numcsns = 5, rid = 2, octet_str = {bv_len = 224, bv_val = 0x7ffd543f57f0 "rid=002,sid=004,csn=20141129152404.970905Z#000000#001#000000;20141129151341.491595Z#000000#002#000000;20141129151341.507685Z#000000#003#000000;20141129151341.523508Z#000000#004#000000;20141129151341.5"...}, sid = 4, sc_next = {stqe_next = 0x0}}, si_cookieState = 0x1681c70, si_cookieAge = 1539004, si_manageDSAit = 0, si_slimit = 0, si_tlimit = 0, si_refreshDelete = 0, si_refreshPresent = 1, si_refreshDone = 1, si_syncdata = 0, si_logstate = 0, si_got = 269715, si_strict_refresh = 0, si_too_old = 0, si_msgid = 2, si_presentlist = 0x7ffd7c58e050, si_ld = 0x7ffd7c718210, si_conn = 0x7ffda9a365d0, si_nonpresentlist = {lh_first = 0x0}, si_rewrite = 0x0, si_suffixm = {bv_len = 0, bv_val = 0x0}, si_mutex = {__data = {__lock = 1, __count = 0, __owner = 13107, __nusers = 1, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\001\000\000\000\000\000\000\000\063\063\000\000\001", '\000' <repeats 26 times>, __align = 1}} (gdb) p si->si_ridtxt $2 = "rid=002" (gdb) p (void*)si->si_ridtxt $3 = (void *) 0x1681d24

1 0

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 29 Nov '14

29 Nov '14

Program terminated with signal 11, Segmentation fault. #0 0x000000000047fb64 in do_syncrep2 (op=0x7f8c494e7740, si=0x19967e0) at syncrepl.c:892 892 bdn.bv_val[bdn.bv_len] = '\0'; (gdb) bt #0 0x000000000047fb64 in do_syncrep2 (op=0x7f8c494e7740, si=0x19967e0) at syncrepl.c:892 #1 0x0000000000483903 in do_syncrepl (ctx=<optimised out>, arg=0x1996410) at syncrepl.c:1551 #2 0x00000000004250e8 in connection_input (cri=<optimised out>, conn=<optimised out>) at connection.c:1732 #3 connection_read (cri=<optimised out>, s=<optimised out>) at connection.c:1460 #4 connection_read_thread (ctx=0x7f8c494e7bd0, argv=0x21) at connection.c:1284 #5 0x00007f8c6bb5bd22 in ldap_int_thread_pool_wrapper (xpool=0x194a090) at tpool.c:688 #6 0x00007f8c6b7260a5 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #7 0x00007f8c6b45384d in clone () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) info locals syncUUID = {{bv_len = 16, bv_val = 0x7f8c40106ad7 "\023Z,P\f!\020\064\223e\177\031\357Ζ:"}, {bv_len = 0, bv_val = 0x0}} cookie = {bv_len = 60, bv_val = 0x7f8c40106ae9 "rid=001,sid=001,csn=20141129143806.208485Z#000000#001#000000"} rctrls = 0x7f8c40104ad0 bdn = {bv_len = 34, bv_val = 0x7f8c40105209 "cn=tablet,uid=1756,dc=ngdr,dc=ldap"} si_tag = 1 syncstate = 1 retdata = 0x19eb878 retoid = 0x0 syncUUIDs = 0x0 len = 60 berbuf = { buffer = "\002\000\001", '\000' <repeats 29 times>, "\320j\020@\214\177\000\000%k\020@\214\177\000\000%k\020@\214\177", '\000' <repeats 34 times>, "i\315rk\214\177\000\000\000\000\000\000\000\000\000\000xQ\224k\214\177\000\000\340b\231\001", '\000' <repeats 36 times>, "\a\000\000\000\000\000\000\000\020c\231\001\000\000\000\000\a\000\000\000\000\000\000\000@b\231\001\000\000\000\000\006\000\000\000\000\000\000\000\300b\231\001\000\000\000\000"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} msg = 0x7f8c40102be0 syncCookie = {ctxcsn = 0x7f8c401038f0, sids = 0x7f8c40105890, numcsns = 1, rid = 1, octet_str = {bv_len = 60, bv_val = 0x7f8c40104e10 "rid=001,sid=001,csn=20141129143806.208485Z#000000#001#000000"}, sid = 1, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x7f8c40105e80, sids = 0x7f8c40105020, numcsns = 1, rid = 1, octet_str = {bv_len = 60, bv_val = 0x7f8c40105760 "rid=001,sid=001,csn=20141129143806.208232Z#000000#001#000000"}, sid = 1, sc_next = {stqe_next = 0x0}} rc = 100 err = 0 modlist = 0x7f8c40106a70 m = 32652 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 empty = "empty" (gdb)

1 0

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 29 Nov '14

29 Nov '14

This is a multi-part message in MIME format. --------------050709090905040108060403 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit A simple testcase is attached. All activity (add/delete/read) come via first node of 4x cluster. Unfortunately a lot of time may be required to reproduce a bug (coredump), from 10 minutes up to 2-3 hours. Leonid. --------------050709090905040108060403 Content-Type: application/gzip; name="testcase-its7968-1.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="testcase-its7968-1.tar.gz" H4sIAFrZeVQAA+1abXPbNhLOV/FXbGm7phKREiXLvipVL6mtXj3n2h7LuZuOz+OhSEhizRcV oGK7sf/77QKkSEqy7OSS9DojZGIRwGKxWDz7ApB+5CdW4PnDF1+uNLDs7u7Qr73XbhR/Zdlt N1/YzZ2m3bbtdsN+0bAbbbvxAhpfUKZZmYrE4QAvgrvVdE/1/0WLF3XAc7uB50y0ePAbc5P9 wBGiAzEfOZH/h5P4cVTuSeI5Us89kVXNczugOHXgnWD8wEmcMzaJhZ/E/E7TaLKp73UdL/Sj WjYttnRANj0xj+O68TRKcj6cTQLfdWpLF5BRr+Yp/HASsD5zp9xP7tJ1SIlS5toUF3KKtDcx x9bbuz/U/DhnNPL48rlLytv4CO0Ry0e092X2P4w9Zrlx9Gfav72zQ/bfarfabfxd2/9XLBoC 7T3jhwfw5vDgjaaFPucxJ1TA+dm7nhZjZ+DcgbiL3AmP32vZg+mOmXs9if0oAbvRADvv4SyI HW9MPZLHn73GdXm8pF7ui7qAp+y/tdeexf/W3h7av91c2//XKdJqCQTAMaBKH1AhI/Y9xrtv 3h4cnGFDcjdhGGyHnInx28g7ZVz4ItEqnCX8rqu34ZUOiR+yeJp07QZcMzZxAv896+p2B//p WkUwh7vjgSOwbS5yYq+TJFx09Ze1V1gZ+JEXsmQce10VnFWTF3X1JTEfB6D4HosS3wlEl8Jz hUQJ/NBPutNI/jIPJfD/WGj8s5X/f1D4NAqZ6Sdi77vdv5m2Jcaffw6y8T208eX2j8G+uSvj /26rTX/I/vca7bX9f42y8U0drauOljnWtJ97Z73upjG58araj4fHB4dn3c0P1PhQHzPOTBE4 E087eHv+dqHLw2RV2z961z/vYY8h2O9gQ7uqbWRttrbRP3p7enXQ+/HdP7r2butvO1qhoaFp 134QOEEA5u8gJ4KQhTLJMJ3Q290xAz+a3sK332IvOhhMOHgI5hBeWt5ghH+T2wTcmDNNS5hI wLwFqx5PWERewhTxlLusTlHOH005g/9olft7MEY+DgriiAE+dep1/GtlgyzM4mccLKKcY0dM KiiP6y30YKtkTeKjV4ST097x0QGu9qx3dNU7/sdV82onG06E6FkZymyOHY7MuD/CPXlqTMj4 iOEYNw5DEk6NCr2BFToiYRzMEPSXL1/CL5KQszBOmJlwx732oxEMuBO5Y9heGLcNmLnFS0XW q6ni2C3OuPn3XNebHxRgHuqC8EQb6HgemM7yjVBZp5B0Xt0K/EH6DLQrSxSK02Y6DZgTEVfc e9NLO6zC1prmBGOVf9udyYRNLHIGAcL0LnLcIK/TFHktTXYFtni+kE3oHRLfLTMIZUNGMfAG hdoYa0qk0Llm4DFchwdZNfv1I+QbBI9qc1FhqCHucJ8Jegpws2jDrki6lIfka+4/Z+j8rOG1 5yNaJriJqW0/kKRkXnxYaKy/nB9phHTEhnsYYVguDkciMfViUP1mAkk4GQo4e/tLgWph+cOY Q4TKQZrUbTy8Bi/WKscnBz3lcmayRHhEudqMMAnJxEyJSEzSc76oWcd7h9cx4M03ke8qtrHE haJYmL14oIv7dO77nPR+9FrcK5Ddz9B2P9Lhe8i8o0S1TK/hh7lJin2l+fwhXMCmcYMwu4Hv v/8e9FwhaILmCI9ccPkakjFDBVRIbXyZ2iopJw7fdGEzKgypVCi16+qEE3R7dsPa5FbDsjub hmFTgVc4rFqt65I4VQClh/ebXK5a5Yb3m/RTXnHxSAE/PHPROMnQx78e+mJtbsKozH92ZfF8 5shaqxweH57Pgpaf3XtqlfpUcBkEKW9EU0YnMIgFPsWALszcNChtRatnuZOrmpuRDDiPub3h CsHMADtJGPRLfdoW3OTmDyunoghXXM/RYf/8CjX/qms8JWIV8+F4io6+IBBmzA7mv5ZUNv15 /Ym2R/GhBKJoAUQRgggyiuYe9mcUjdZ3jYxCV3Y8RAGG8cr1kDmSZ/GHyuNDEHdQh7PJIWIJ xrFraLbbVuE/TCc4lLnjWAVFSvsS5NnRQcaPj3C4y9yHyVYj6cl1kS/M0YRzsluWwoYQc3Sy //aoTQFv80OeNiGCBDTA3AFzTE6C9uNBXw2/5g83Mb9ejbVvFcQQXk/KjfjK8jEJJ1VpatpT ypjc4RkvWs5bKkQRAMVEF0kKh5TJnaapnex+7qI/bghlsK+Cco4yshQJMq1CA9UxGMyfYZO4 Yag/Ojo6yC7gwRzkjzcgGNppQjtMGoL9OErYbbLfP1aK/mIK0Ix0QxuvIcvJJX5ep5l3O29f lqJXET5SODMC/d8OuixSKWapeJanC3HLsqTN3VAX/qqFgAm0LP0TPdEKtLlO8tFOHMc86cTT vTVnoaToouUWaTkQFJiVs5HJEu5uHHniebagnf56/vPJ8VW/t39yfNDHA5bkgUb/UWwwUXPx MIJOZLuzTetrYsuEkn5EmfcKKwO3mgoNacHEoTz5p+6QTEVM8QxPmKcpSw2potbOQP/JDxiI O5Q/BDxlTaaJ0KmjpJSVwaRS+TyeX8nkzkx0ERwyCZGoIPd9sGIrTRPnIfd78eby4XlbhqnA aoZ1j72vR9MgSFlT8vB89guIKC2hBlnagz0FSRAoKXJOe2f7vWNMvgzFaQ5R8FK+QaiDMd/x am6qqp5KpFoX+JaIP4GtcltMQW5TgQUPLeeHJx1UXHk1D1unyFtF44O8sf+fSP8LXSwuja6f eY7V9/92c7e1k93/tfbazRfYtLO+//86xQ8nMU/UW/v0mSJoDT0wHhI8PxrVMMMejeQDdyIv DtHeE471jB4dcA1ioWkbzyraBvwzim8iOSekF0EUTLIX7jJRQl9yoVUu9DzPoiTL1mtwjD70 sqZtLHQ2V3W2VnXu5J2Xz12FNuon8QTF/MkJBNNC5/aUx0MMSCR6G3GtYSUotBUp6pgg43g8 hGHHhwdN5YV9F0MRNsj7xv7+yWnvqv/ux/OzXk8LYvcae2abYh1hg1HVNJc+IoD+dCBS5ob6 uKDa0SpeRNwr21603QH58uRD46E2//qlRmfvbTxUC6S6qBh64esE1MuFXvyYwQno5U8cYYc+ mT2hIugHZ1CfMuiXVckVi0Gtkg3OXWp3I9lslxpFoREusfmBjnsDu7gQN+rSFUBY++QVYTD0 XZZJvkQoyX9OhuacDAnd9yVfUAg1QUEKrfJGbrd6O4b7y4agjvKGYMGwBlcoDP6l+Wn/K6Mg HjgBSKTWQAEOuVQITZbj/j71OUMQyWsiGktWqKhotCLjLGAYHyQZvfCbckrMFNUFDbpEvdja AjW20N0Er0k4C/6+inRSNOxJ+J2cQSKUZLe8SNUvlMouL2ziW0aPhXln6CQGzVq9lAKlvC2c 6UoYNBz357JEWIOcqxQrA5Scl54XGVHrUlaqY45Zs8CsuZRZ8zFmzTKzObU20VeRYqX7tSib NXTkyTBb2xLbkMSwhQnvFjy2cNJ/VXJmty6bKDdv0cmzR195gCOAcZ7utZqEUYeh/+SgK/Fo Bsrr5GyIjS08ijLXmeK5ipqemloGCgM5VqvVdHXSY57zKVsGZvyPgP8cYJZSYA6e5IiuAi7Y KCn4G9Rw9SOR3vhEpK/CnFr247B7GmhFDsuwpjjMW9vC6KV7mY5lARRVsQSZ9ILpfYbNIY/D r4BOJfpKgD5qy09D9HmpwIZGjnjEkiuVH8mtNwhYKWSlnrUKd5Hxsbzf9un1nAQTZgVpBc8q WuVmTEdaAi53OwrLqlvmD/Qo9cEdH5fYk2rDqGzoxzHICyU88EUYZbANhvE0kh59y5M8nCSO hEUqoZo0FOL8Snlvzkg6tQALT0EYmgwpd2pR2I8uWU0uKZmrpUaComqoK6DUBBmqHMUCTBT8 2MOELgjuZJ+Am3GMqzs4PFfwULOlKaBUomIhdYdzNmg6effVhSVfjRSUJbdNClewRDLDhV0h mswmKxsZrjw2mI4MvS/TMHo5WgCUvK5CHJEgM9BWUvOxVOaGtqO6C4lc9TVRpdCebVUR1Y/D Or0nXAXrXJwyhil7t+Q9nZHuJv34UWLYjRrYzUYVs0/EmtWo0qZROMn37IyNpoHD76hZ1JVx CRBxyGCi0svHdk7ykRu3ZFdobI6umTy1Yk5MOi2ksVaa2NDQ1LFeSBlw7QGLUmzC5WddhKL9 rMtIQ9ozlkEC0JFBzl72rD9hM6ESLTldgXKsxRMG7T3dy0nmiJlblG/ESLoSVedT1Twn0uwo M0xlk5e36TJSL1T0gWnYTl0hfVOdGnVqzJP0C2tqVRffuqYW5NPtnq+OiyL3iWHmjujSzY9k RlEZxyJBDrK7cVkIv3OGfs7vSGa0NPq0DDC57HywH958aOZJJolYg0ysGhBrZfhBdkSjuz3f Cfw/mJG9FiimqYURFqo0id04uKLDLrmBlMW/emf9w5PjlqIS6K1i5dFl78np+dVx7/zfJ2f/ vDo//KV38u68Bi2yXEUuP4+7oiXMiatidnnH+lPXZUIMp+SPaYxyNSgx+SRcfknwGhBHJX6q bZL5fwrWUtelKctubXH++fC8UY7PhLXQ8aMFoOVoRTfpu/vyTaERsPcs6GY98gVaDdSc3e0t wxEuOc+q/Z0A2FLUdG1cVfUQleeMWFVs44kCbWYY0qhfza3QRLvc+rmz9Utnq7+Ncs7gT3e+ ZNAlr9zG6ga9JjDIA1dUyLNLh/tz+WQkDsf4JYMt0VQz4ubziKVXXM1YkmSkq9mWSFvPJ915 FmnqeVdLmxLl5KslXiBfLfUC+WrJZ+SzLbTkK2Uj36a8QW3FXH2+vzVX38nrmXoWWpoLLa2F lpwPAg+Ofu2AAwHGNXTy8mWZLxAz8vjklT1uHkJ2G/ASmk11Wipg2U6zw1hYEycZWwhrkQhD p+/wdHW0KlnsglMiQm8aTr7RU055JjdALV6/lolgKQrPMZxzctg3wape3JffYnIR+bZk9XRX StW53la5ujOrznZkrqE539Cab8h5zAf5yBdj5qHoyqf9hd4irMu6rMu6rMu6rMu6rMu6rMu6 rMu6rMu6rMu6rMu6rMu6rMv/U/kvfCGhtABQAAA= --------------050709090905040108060403--

1 0

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 29 Nov '14

29 Nov '14

current OPENLDAP_REL_ENG_2_4 (6b26910 Silence compiler warning...) with merge-in current mdb.master (9a72292 ITS#7961,#7987 Re-fix txn init) - cluster of 4 node, but on single machine. - only localback network, no any failures. - multi-master by config, but all writes come only to first node. Testcase will be available shortly (config + script). Core was generated by `/opt/openldap.devel/libexec/slapd -l LOCAL5 -d 0 -s 0 -4 -h ldap://10.4.0.1:1114'. Program terminated with signal 11, Segmentation fault. #0 0x00007ff68564d07b in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007ff68564d07b in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x000000000047fb3c in do_syncrep2 (op=0x7ff62f7fd740, si=0x1c74190) at syncrepl.c:934 #2 0x00000000004838c3 in do_syncrepl (ctx=<optimised out>, arg=0x1c746d0) at syncrepl.c:1539 #3 0x00000000004250a8 in connection_read_thread (ctx=0x7ff62f7fdbd0, argv=0x35) at connection.c:1293 #4 0x00007ff685ceecf2 in ldap_int_thread_pool_wrapper (xpool=0x1c27090) at tpool.c:688 #5 0x00007ff6858b90a5 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #6 0x00007ff6855e684d in clone () from /lib/x86_64-linux-gnu/libc.so.6 > if ( !BER_BVISNULL( &syncCookie.octet_str ) ) > { > slap_parse_sync_cookie( &syncCookie, NULL ); > if ( syncCookie.ctxcsn ) { > int i, sid = slap_parse_csn_sid( syncCookie.ctxcsn ); > check_syncprov( op, si ); > for ( i =0; i<si->si_cookieState->cs_num; i++ ) { > /* new SID */ > if ( sid < si->si_cookieState->cs_sids[i] ) > break; > if ( si->si_cookieState->cs_sids[i] == sid ) { syncrepl.c:934 > if ( ber_bvcmp( syncCookie.ctxcsn, &si->si_cookieState->cs_vals[i] ) <= 0 ) { > bdn.bv_val[bdn.bv_len] = '\0'; > Debug( LDAP_DEBUG_SYNC, "do_syncrep2: %s CSN too old, ignoring %s (%s)\n", > si->si_ridtxt, syncCookie.ctxcsn->bv_val, bdn.bv_val ); > ldap_controls_free( rctrls ); > rc = 0; > si->si_too_old = 1; > goto done; > } > si->si_too_old = 0; > break; > } > }

1 0

Re: (ITS#7987) SIGSEGV in LMDB while adding ldap-entries
by leo＠yuriev.ru 28 Nov '14

28 Nov '14

(1) ITS#7968 not fixed - still crash in a few 'favorite' locations - last time SIGSEGV in do_syncrep2() at "if ( ber_bvcmp( syncCookie.ctxcsn, &si->si_cookieState->cs_vals[i] ) <= 0 )" (2) mdb.master seems to be have another bug(s), that also was fixed in the 'mdb/fixes' branch on git://git.uio.no/u/hbf/openldap.git - just a cherry-pick of ead57604 fixes this SIGSEGV, but I got a 'implementation specific' error in heavy add/delete test (same as in the attached testcase). - but merge 'mdb/fixes' passed my test. (3) OPENLDAP_REL_ENG_2_4 without merge current mdb.master and after revert all 4d02c741-related changes (single write txn) also passed my test. Leonid. 2014-11-28 22:06 GMT+03:00 Howard Chu <hyc(a)symas.com>: > leo(a)yuriev.ru wrote: >> >> Sure this bug is introduced by the 4d02c741 (Use a single write txn). >> >> Could be fixed by: >> cherry-pick ead57604 (ITS#7961 Re-fix txn init) from >> git://git.uio.no/u/hbf/openldap.git >> or >> revert: d72b2f5d (ITS#7961 fix txn init), 62e4eeb7 (ITS#7943 reinit >> txn flags), 891e6627 (Plug leak in 4d02c741...) and 4d02c741 (Use a >> single write txn). > > > Totally fixed? Or are you still seeing the ITS#7968 crash now? So far I've > run your testcase on the patched source (with ead57604) and gotten no > crashes. > > -- > -- 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#7987) SIGSEGV in LMDB while adding ldap-entries
by hyc＠symas.com 28 Nov '14

28 Nov '14

leo(a)yuriev.ru wrote: > Sure this bug is introduced by the 4d02c741 (Use a single write txn). > > Could be fixed by: > cherry-pick ead57604 (ITS#7961 Re-fix txn init) from > git://git.uio.no/u/hbf/openldap.git > or > revert: d72b2f5d (ITS#7961 fix txn init), 62e4eeb7 (ITS#7943 reinit > txn flags), 891e6627 (Plug leak in 4d02c741...) and 4d02c741 (Use a > single write txn). Totally fixed? Or are you still seeing the ITS#7968 crash now? So far I've run your testcase on the patched source (with ead57604) and gotten no crashes. -- -- 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#7987) SIGSEGV in LMDB while adding ldap-entries
by leo＠yuriev.ru 28 Nov '14

28 Nov '14

Sure this bug is introduced by the 4d02c741 (Use a single write txn). Could be fixed by: cherry-pick ead57604 (ITS#7961 Re-fix txn init) from git://git.uio.no/u/hbf/openldap.git or revert: d72b2f5d (ITS#7961 fix txn init), 62e4eeb7 (ITS#7943 reinit txn flags), 891e6627 (Plug leak in 4d02c741...) and 4d02c741 (Use a single write txn). Leonid.

1 0

Re: (ITS#7987) SIGSEGV in LMDB while adding ldap-entries
by leo＠yuriev.ru 27 Nov '14

27 Nov '14

confirm - this bug seems to be fixed (just merge with 'mdb/fixes' from git://git.uio.no/u/hbf/openldap.git). but now is another, like http://www.openldap.org/its/index.cgi/Incoming?id=7968 #3 0x00007f5061836c82 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x00007f5061df4553 in ber_int_sb_write (sb=sb@entry=0x7f5024105870, buf=0x7f4ff80019d0, len=len@entry=152) at sockbuf.c:441 #5 0x00007f5061df0b8b in ber_flush2 (sb=0x7f5024105870, ber=ber@entry=0x7f500cffb330, freeit=freeit@entry=0) at io.c:246 #6 0x0000000000433dce in send_ldap_ber (op=0x7f500cffb7c0, ber=0x7f500cffb330) at result.c:339 #7 0x00000000004367a6 in slap_send_search_entry (op=0x7f500cffb7c0, rs=0x7f500cffb5c0) at result.c:1430 #8 0x000000000051077a in syncprov_sendresp (mode=<optimised out>, so=<optimised out>, opc=<optimised out>, op=<optimised out>) at syncprov.c:895 #9 syncprov_qplay (so=<optimised out>, op=<optimised out>) at syncprov.c:944 #10 syncprov_qtask (ctx=0x7f4ff81086c8, arg=0x7f4ff8108670) at syncprov.c:1010 #11 0x00007f5062009d12 in ldap_int_thread_pool_wrapper (xpool=0xd3b070) at tpool.c:688 #12 0x00007f5061bd40a5 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #13 0x00007f506190184d in clone () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) frame 4 #4 0x00007f5061df4553 in ber_int_sb_write (sb=sb@entry=0x7f5024105870, buf=0x7f4ff80019d0, len=len@entry=152) at sockbuf.c:441 441 assert( sb->sb_iod != NULL ); (gdb) info local ret = <optimised out> __PRETTY_FUNCTION__ = "ber_int_sb_write" (gdb) p *sb $1 = {sb_opts = {lbo_valid = 3, lbo_options = 0, lbo_debug = 16384}, sb_iod = 0x0, sb_fd = 75, sb_max_incoming = 262143, sb_trans_needs_read = 0, sb_trans_needs_write = 0} tail xxx.log 54775e18 syncrepl_entry: rid=001 cn=tablet,uid=1040,dc=ngdr,dc=ldap 54775e18 slap_queue_csn: queueing 0x7f5020107890 20141127172334.589180Z#000000#001#000000 54775e18 syncprov_matchops: skipping original sid 001 54775e18 slap_graduate_commit_csn: removing 0x7f502012d740 20141127172334.589180Z#000000#001#000000 54775e18 syncrepl_entry: rid=001 be_delete cn=tablet,uid=1040,dc=ngdr,dc=ldap (0) 54775e18 slap_queue_csn: queueing 0x7f5020107890 20141127172334.589180Z#000000#001#000000 54775e18 slap_graduate_commit_csn: removing 0x7f5020108020 20141127172334.589180Z#000000#001#000000 54775e18 do_syncrep2: rid=001 cookie=rid=001,sid=001,csn=20141127172334.589328Z#000000#001#000000 54775e18 syncrepl_message_to_entry: rid=001 DN: cn=tablet,uid=1793,dc=ngdr,dc=ldap, UUID: dc4d5d30-0aa5-1034-8ff5-a9ee5a485f53 slapd: sockbuf.c:441: ber_int_sb_write: Assertion `sb->sb_iod != ((void *)0)' failed. 2014-11-27 13:07 GMT+03:00 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no>: > On 11/27/2014 10:26 AM, leo(a)yuriev.ru wrote: >> >> # possible first bad commit: >> [4d02c741b120786df1b87ee9ed49c1d3f9bc7522] Use a single write txn > > > Partly fixed in mdb.master, but I think branch "mdb/fixes" > in <git://git.uio.no/u/hbf/openldap.git> is needed too. > That is, the "[Untested] ITS#7961 Re-fix txn init." commit. > Both branches have some remaining problems, however. > > -- > Hallvard

1 0

Re: (ITS#7987) SIGSEGV in LMDB while adding ldap-entries
by h.b.furuseth＠usit.uio.no 27 Nov '14

27 Nov '14

On 11/27/2014 10:26 AM, leo(a)yuriev.ru wrote: > # possible first bad commit: > [4d02c741b120786df1b87ee9ed49c1d3f9bc7522] Use a single write txn Partly fixed in mdb.master, but I think branch "mdb/fixes" in <git://git.uio.no/u/hbf/openldap.git> is needed too. That is, the "[Untested] ITS#7961 Re-fix txn init." commit. Both branches have some remaining problems, however. -- Hallvard

1 0

Re: (ITS#7987) SIGSEGV in LMDB while adding ldap-entries
by leo＠yuriev.ru 27 Nov '14

27 Nov '14

--f46d043c06bcb68d180508d3bcbe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Two runs gave the same result, bisect-testcase attached. sudo will be called for ramfs-mount and ifconfig for ip-aliases (for cluste= r). mkdir xxx cd xxx tar xaf its7987-gitbisect-testcase.tar.gz git clone git://git.openldap.org/openldap.git openldap-source cd openldap-source git checkout OPENLDAP_REL_ENG_2_4 git bisect start 'OPENLDAP_REL_ENG_2_4' 'OPENLDAP_REL_ENG_2_4_39' git bisect run ../git-bisect-probe.sh git bisect log # bad: [6b26910c5acbf141ff322d043b3301d0976a7913] Silence compiler warning by adding explicit return 0 to ppolicy_db_destroy # good: [6bfa8256161618e62e56d139243aa234b3ece875] Prep for release git bisect start 'OPENLDAP_REL_ENG_2_4' 'OPENLDAP_REL_ENG_2_4_39' # good: [0e104da454c0f59c6d3195add38c935179de2cb3] Merge remote-tracking branch 'origin/mdb.master' into OPENLDAP_REL_ENG_2_4 git bisect good 0e104da454c0f59c6d3195add38c935179de2cb3 # good: [5e4cc6d1c515ace1e0c151ca8986bf805f203834] ITS#7895, ITS#7915 git bisect good 5e4cc6d1c515ace1e0c151ca8986bf805f203834 # good: [d871d328544124573bdbf63e360c4bb47e6c0d38] ITS#7702 git bisect good d871d328544124573bdbf63e360c4bb47e6c0d38 # good: [e4c848e24ff36139eb235efe7f426d89e01056ae] ITS#7915 fix memory leaks in previous patch git bisect good e4c848e24ff36139eb235efe7f426d89e01056ae # bad: [0659ef45d486b5daaafc020cb67b561a8029036d] ITS#7941 fix for repeated= tags git bisect bad 0659ef45d486b5daaafc020cb67b561a8029036d # bad: [5ebeec95535786ce7a0e80173209e33f64ab9013] Merge remote-tracking branch 'origin/mdb.master' into OPENLDAP_REL_ENG_2_4 git bisect bad 5ebeec95535786ce7a0e80173209e33f64ab9013 # skip: [29fd241fadc3dd49b3486f0e3556b029b716bcbf] Remember oldest reader t= xnid git bisect skip 29fd241fadc3dd49b3486f0e3556b029b716bcbf # skip: [3646ba966c75137b01e38fc5baea6d5864189c8e] More for me_pgoldest git bisect skip 3646ba966c75137b01e38fc5baea6d5864189c8e # skip: [4d02c741b120786df1b87ee9ed49c1d3f9bc7522] Use a single write txn git bisect skip 4d02c741b120786df1b87ee9ed49c1d3f9bc7522 # skip: [5ee99f1125a775f28ed69b06d991a43c60d894a9] Change retry to num times 60. Testing shows that on a known dataset, this has the same growth behavior as 2.4.39, while num times 20 resulted in significant growth. git bisect skip 5ee99f1125a775f28ed69b06d991a43c60d894a9 # only skipped commits left to test # possible first bad commit: [5ebeec95535786ce7a0e80173209e33f64ab9013] Merge remote-tracking branch 'origin/mdb.master' into OPENLDAP_REL_ENG_2_4 # possible first bad commit: [5ee99f1125a775f28ed69b06d991a43c60d894a9] Change retry to num times 60. Testing shows that on a known dataset, this has the same growth behavior as 2.4.39, while num times 20 resulted in significant growth. # possible first bad commit: [3646ba966c75137b01e38fc5baea6d5864189c8e] More for me_pgoldest # possible first bad commit: [29fd241fadc3dd49b3486f0e3556b029b716bcbf] Remember oldest reader txnid # possible first bad commit: [4d02c741b120786df1b87ee9ed49c1d3f9bc7522] Use a single write txn 2014-11-26 22:11 GMT+03:00 =D0=9B=D0=B5=D0=BE=D0=BD=D0=B8=D0=B4 =D0=AE=D1= =80=D1=8C=D0=B5=D0=B2 <leo(a)yuriev.ru>: > Just run a 'runme.sh' from attached tarball. > Problem (coredump) usually is reproduced for 10-20 min. > I will try 'git bisect'. > > Leonid. --f46d043c06bcb68d180508d3bcbe Content-Type: application/x-gzip; name="its7987-gitbisect-testcase.tar.gz" Content-Disposition: attachment; filename="its7987-gitbisect-testcase.tar.gz" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i2zwyqwk1 H4sIAIHtdlQAA+07XVPjSJL9av2KbGEGuduSLYOh2z2eaxrcM8QwQGD69iZYgpClsq1BHx6VzMc0 PNze6/6Y3Y3d23u4299A/6PLrJJsyTYGehtmNoLqNlZlZWVlZWVlZmXJPTfWOy5ndqwPorDDDN5/ 9qVLFctavU7f5lq9mv2mUjNX156ZtZXler26srq6/KyKldrKM6h+cU5mlCGPrQjgmXcxH++29n/R svC80nGDSsfifUX5duvgeHNrv1nUImY5nhucgN6FojY4c0olpd3afp80O24UWD6DCcQqYu3tt95v /Uez+DFFv6r0WcR07lkDR1G6w8CO3TCAztD1HK0EH5WC7UAxGRouL4GduzGYtbpS6OGD7TErIOr6 OehOvt3twiE8p0ajYodB1+0NIwZHbyDus2CE9wa6rlLIYuio66zrniOXkt0rBLHA6nhMdy4Cy/bG dc+xBuNaeMoiz7rgCHFcLkCoP7Fr5wn4ApBidJxOptbHWm4WvnXCwGEDFjjw1VcgqvpPK6NnN8Ah PC/X6SojSbFvx5JM5U79I5+EY4c4Z6wZlWgY+Ex3Y772+tUabvU8I8zuh6C+eLACqliymPGYVo0J xuRiKYXx6LD7PSIWIsaHXtwMT5Axj7Mcxvv1re0MTtcSCLTMjzAHlL1QXkWxw2EQs6hZVTzXd+Pm mnLWdz2GSllMmkD3YiiKVtJLJ8Q1SjoVNW2E9RJM3DqZCUaoDlZiksfEwm5CC+cumpItUJRygOdN UMMTNd0BKKAO7s8TIRknDJjyCNLhHmMDMKuKMuarmfKlCGUr/pvya5u9p5IUN3Bjw3Pc7gOOQU5+ dXXlJv9fXa3XyP/XzLpp1qsm+v9q3aw++f/HKE7QAMdukpdTws5PGAdueBbnDQijnhW4v1jkYvIt cTiB6ti7oqo4dgMkpQZ84CzatGJrnw1C7sZhdKEoNNjQdZqW47tBOR0WIQ0QoFvGsWxhCMd00Ep6 rm2VZ04gxZ5Pk7v+wGNtZg8jN75I5iE4SogrQ5zIHuKehRFCzy9+kePjmEHPiWaPnRPewj2kRyRv kN7DrL8fOsygyOhhyIty2/43V1Zk/I8nAPx+2v+PWBRUNIxptzbh7dbmW0Xx3SgKI9IKONj/0FKS gBf4RWBjyHGqpA+63Wf2ySB0A4weq1Uwxy0R80LL6VOLoPFrz/Gp3FwSK/egJuC2/b+8Vh/5/+W1 Ndz/Zu1p/z9OEbuWlAAidKjCBtDR4tR18Ijydn1zcx8B8cWAobPtYjjfXw+cPRZxl8cKHr/i6KKp 1uGlCrHrs3AYN80qnOAJwPLcU9ZUzQb+w9MKZ1Zk9zsWR9iE58RWK44j3lRflF9ipeMGjs/ifug0 pXOWICdoqjN8PnZA9h0WxC4eApvkngvEijyQDQPxzRzkwP1lCvhrC/83UCYzAg8xxvz8Hzp7uf/R +6+u1tfI/5v11drT/n+Mksv/fdfabzVluk95t7Ujcn0fCZjL4W2uH6xPNTkYrCob2x/aBy1KEHL2 M5hQLynKiet5lL3SfwbRHXzmi9BBt3xndUX33GB4TtmpJHGgyJzVC8Pp9PBvfB6LNJGiiLSRfg5G JRywgPa+zsNhZLNMYu/3SuHyEjSZNwwDBvjUqFTwr5F2MjA2H1EwCHOCHBEpID+2M9WCUEGa2Edb B7t7rZ3tzfW94/3W9nFr59vj2vFKKWEizXSM+C5+lCK9qnCSOAnDchzQrdmTknEZF3hOxfDcTvJM OTttBnM4bMqfTJmei6ypkzTckP9MeHrk/KdkaVbicyLpeaM0pwWGEoqsyGWcnjzf6VTwc0zcJTRk YnXjLl1nj+rgGibKf5VMgZQ16mbglReTff0Tx41AH0x31nw6oMIl9NCpZZuxOx86Ich2PYbYH3Q5 7K//kMGaEk03jCBAwSFOshGvZMZxZ3ezJTfsiMsAA/zjYoAuPJ1AgkQToDUYMz1qOLUiSiBPgmjn Z2EstiHLFvp+B1R+mYx9OUa97L3hl1IBL0eaeNlT4WtIbYvQeBGcwjcTg2TbcuPJlKh2hip4Bl9/ /TWoY4GoJdB7eGDJpEhJbNEssRXS5CrlVYtBpkuhQIFRUyUdQvNiVo1iZFQNs1HUNJMKvMRupVJF FciJACi4uixGYtYysros0ld+xtmAHL6546RxEEp+F0SSd2LAIE9/dOC/O3EkrRS2drYORiZ/lDVU CpUhj4QLoagLtzkaiE7I8SkENG96UaOgT14WpUtc0ouBMOw3mcTuHMZ0DxuJGbRZbVoWXOTaN3OH Ik+Snc9CD3f4TWOzcxQdi8GKevzunJypomd0X1a2t9oHx6gEL5vabdIqYWAbDu1+liMMfS0MZA2x 7vTnzWeaAfJiOX0OpvQ5QH2GFKO2hu0pRnX5dTXFUKVJ6SID3XDufMgykJFzu9IxgRc2cDlHg0PA Yt/iJ1Cr143MB4YDJXtVQvFbjDTVubp4KztkTcc6gX6AnbNkuUHvkw0hGV2ptOzbuxvr23VyCObq 8qsV0DlUQV+Zry61b87C6GS+anwlNQK14VZ+UR3SiEmsvqzUFOU2IQwu8GwVzKYtBCER0E2S17MR aXQ8GFwoyRVS80sX9Wa9zevmPM0bKwUpNgqqgUDqKI+foH8HRaKGAcT29vZmmvgGvTN+PAPOcFvF tKgkIdgIg5idxxvtnewd2gMIQNHSu7M3kEbNQn/eJLFxfQyfFUSXUH0Ec3oA6u8stDAkUjukMzQl og3DUMm3n1ETfsuJgA40LfUzDcccbbOt+N7mH/vcanSTtdVHTihrUcUSje85E2VuiImLMAtXNwwc fre9oOz9ePDd7s5xu7Wxu7PZxoONoIH24F5kMMSzhyKAXGos0fxqCBlYPEY5ceclVjp2KWEakoIh R37wz10hEcTo/A4W8GjGXfxoI8kXCO4RdM8KE3XWTcPdpcUlHEiKk4H6nu7N+QWKxAc8Wg2GMSeX mpfzXHdSKDwQe/bIAEyr3vhqvb29vrc5R1F0HYck43749ujqbgqBccF8ghWHnVaCoeclpCmSuDv5 KX3LTaEMaUiELRlOUA0Tvdxr7W+0djAo1CSlCX2FF+JeoALaZMPLiaFKasKRhE7RzSF/BllpFJlU 6KLUGzxMHWztNlBw+dlcLe4h7eLHHCtXi+3fY3yhLMhz4PiNGgok73N0122ZzBDWqvpbyD+OTevD jXFL/r9WX66N7/+qq3T/t7r2lP97lLIA7zbfwTvLPqEsTJoiEhfX0EWbrCxAmzEYq4lWL4m4wmGx 5XocEC/fKxzQFzew50Hf5YIK8H449BzY2T2ADgMMhLFCrw5SRggxhzbZX31gxX204rKmKG5ge0OH FQpyy4pQIN1rFY7xj29VaDsZ8vmO+NwN7tnD85gdu6f36hW4/D7oyFMcRr0Bmg0M1O7RcZTJvEcf 5yLoReFw1EcZuA6tUqGQRA9pqqciKGOrQqdhgTITg1oVL+xNE0GgRMEHRYn7tOZcOhxzVYnD0NNT 4AraV9SqLooCfkCdHFgROvoYJaJ0pHoWCui9FdINCgNEZcG3zulmp2BW15bXVsxXtRUlBRXqy6uv 1qqvzZqywILTrmf1eOEscjHEwEAfPxbdfSnTTUEoGmZ0ki3guV0Mb0PLY9xmEIY+heXIPW0hOQNF 4cNu1z0vFNTRRVUUhrETTEIGZwiRRw70MI4boa6F0UVOiul2cBgSzLw8AuxnHDW9dwc+YLbbdW0Q mG7QA0oqQIhBXcTB4rjjfh7iAE5J0kJ+4+iC4hqkk4F8+LC1SSBlIXPHL8prUfDIOdVSq6MlR5c2 1QCvzNe1WQ1VOqwuCFvS/nFnY7+1t43V6/+7/htc//36T9d//vRf13/99MdPf0DAp/+8/gcC/3r9 p09/+PRHWf0HtvzFACcAje4FbYeXc+8W0R1jCa7/Atd/Rmp/Ryoa9vtfg4b4n+v/vv5bSb61yZGE wc4tO77hghGA1ClzbQjisjMDUBYc1GEfDy84yQhWavj/t+Dc71BmnPG/+Bjz/T+987c6ev9/zazS +/+15bUn//8YxfUHYRTLt/aSZ1LuMkizjEakDGi7e+IhsgIn9PFkEEdYT/Hx1FaGkOMuuFPBTf59 EJ4FYkxIYmU61KYv3ImEDZ46DpWFwqE6TviIbI9ahh08bh2Vlak2c9w23bE2r3F5XuPKuPHorlNU eu04HOAc3os309Ej7UUheUeaF1lKBSteBpbFqKBhxP4Wntaa8PFKkcmrto1uHAHCm7Y3dvdax+0P 7w72Wy30vPYJtoxWzNhGgFZSFFs4ifawwxPimnQepYZSQLuJ1AtLTrDUAGH4PlavypPvZpTpamHJ Dx2OWIcFTc14H5TLoZp909Hy9kT8gg3qYPSEgqAvHEG+56gelQRVLBpBBRkcOwe3AwE2c0CeAcIR gq8ohdwxsxOxgybdcPjlz54Rnqldm6Wcz2BK0J/goTbBQ0yBbfyATMgBMlwohbdiueWrM7i+DI+p 4npA48zrluEYmcG/ND6tf6HnhR3LA6GpZZAKh1QKpE2GZYtIAZVI3IJRX9qiEot6S7SIeQydh0Cj t4GGEWWPJNYhdTpCuZjKFDZCKDSJykKdeXRaQjzBGrZgBCJGEBpKvBtOIOuHUmRHhybRzWuPgYGE b8UajVo6EgwltA0c6Zhr1B3X5yiHWIYxVcFWqlBiXHqeJkTQmaRkwwSxWoZYbSax2k3EanliE2LF qFYsg7DNBuXHNBVpMgeWFvkSxCEschUW4aaJk/xLgjI7t9lA+gCD0uMtegWU4kUWRclay0EYNWjq ezz44TCxuOGTo6FuLHI82tnWkDMBum1o4UU0pFgqlZLZCYt5EA3ZLGXGDyr8l1BmwQWG8vFYo0uA E9ZyAn6OEi7dU9Orn6np83ROTvtmtbtd0bIUZumapDC526Z6z1zLpC/zICuKGZoZMT88TXWzG4X+ I2inZH2ugt64l29X0buFAgsKGeIei49l8CSWXiPFSlRWyFkpRDYS3hHX9y791EsoE0YFScXEkKEg f1xGihvZDanLslnED/Qo5BFZLk6xJcSGXllTd0IQt152GARM/mawGw4DYdEXHUHDiillQyKhmtgo 4ndp0nrjmRR5kBMw7H6IrkkTfCc7CtvRJMvBBSazlWSTIKsKHfPIMkVJiGLAPusNPSu6IDCvyHXi wEOf0a8ZRcZI6IgcMgkShSQFHSG/sTTEutDo1HfMKH3haVMzy9nwiljORERG4iOpa7JHDwUPKAqP Bck0gUzwl5uExP2i00is4x2mQQxQ9ClGz2/S9wimtAEqRTIDuUezwSptBTqzC+KoQOfIX48Rdzms xueKeYKlUVTcTXgTl5XJNBKFzm6nxAMku4p+u4OSHGdcCoPklzwEHWVdxIQoxUMTEl3H28tPNZuu gdxAOKdCP+QxUhDN1aOMJU+Zd1hn2NPUg+iCeEZbRK8wA8YpjY/m1duPtXG8QiyWIWWrDERamhsv jfbptsm1PPcXpqXX4NmIJ9PDQJHGoR16x3Sooo2ekPj31n57a3dnWWJxNEcyTSsEb+zuHRzvtA5+ t7v//fHB1g+t3Q8HZVg2qglR+Rr2MU1hgl1p/vMr1h7aNuO8O/S8CzFtaYyRYzLaOP0c42UgipL9 RNrE8z9l94Wsc0PmDf/0+JOWfiFv6knXfMsNphRtrK0di7v2hkiEax47ZV4zbdlsvfvwbRnkmM2l Rc3iNh2xS+ZrDrAoselOsyTrPgrP6rESX8LgFPdM16deP+qLvo77cvG7xuIPjcX2Uol+SZyoP91C 0oaWr74b4m0BrY7VBbpo0qq0TMJ2mblj4oF40mIrQv+ELQKllKDW7o66fHfUlTuhJvZxPrcJ0hh9 PsdT6PO5nkKfz/kIPRW0IV5L0kbSnKgvT9RXxvV08lOQ2hRkeQoyppM3amMrvVqlG1QZ2ma0xUxc ecgNuoUxUHF4zPG4GUZobhtT4c/UtidEZ+gPnqsJpZE7kz9CfyPeRMj5uQmCE2YE2wZYVTMy/Smk PTgSaa66nK+ujKojeU4AapOA5UnAmMakmwxc3mcOsiatwr9IrvepPJWn8lSeylN5Kk/lqTyV/wdD 8uEBAFAAAA== --f46d043c06bcb68d180508d3bcbe--

1 0

Re: (ITS#7988) Reflected XSS vulnerability in www.openldap.org
by hyc＠symas.com 26 Nov '14

26 Nov '14

yann.cam(a)gmail.com wrote: > Full_Name: Yann CAM > Version: > OS: > URL: http://www.openldap.org/its/ > Submission from: (NULL) (2a01:e34:edbf:a5d0:845:664b:ce80:cf7b) > > > I'm contacting you to inform you about the presence of a Reflected XSS > vulnerability on the www.openldap.org main domain. Thanks for the report, this is now fixed. > > Through this vulnerability, an attacker could tamper with page rendering, > redirect victims to fake OpenLdap pages, or capture users data. > > This reflected XSS is on GET "id" variable of the current "JitterBug" tracker, > and is not properly sanitized before being used to his page. > > The JitterBug tracker project seems to be suspended > (https://www.samba.org/cgi-bin/jitterbug/), this vulnerability isn't specific to > your bug tracker. I just open a ticket to report this vulnerability to the > samba-jitterbug maintainers (https://bugzilla.samba.org/show_bug.cgi?id=10967). > > Proof of Concept, tested with Firefox 33.1.1 (screenshot in attachment): > > http://www.openldap.org/its/index.cgi/Documentation?id=1337</TITLE><img > src=x onerror="alert(/Reflected XSS - Yann CAM @ASAfety/)" > /><TITLE>;selectid=1337 > > Screenshots available : > > http://www.asafety.fr/data/20141126-RXSS_openldap.org_synetis_001.png > http://www.asafety.fr/data/20141126-RXSS_openldap.org_synetis_002.png > > Feel free to contact me for more information, > > Best regards, > > Yann CAM - Security Consultant @ASafety - Synetis - www.synetis.com > > -- -- 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#7988) Reflected XSS vulnerability in www.openldap.org
by yann.cam＠gmail.com 26 Nov '14

26 Nov '14

Full_Name: Yann CAM Version: OS: URL: http://www.openldap.org/its/ Submission from: (NULL) (2a01:e34:edbf:a5d0:845:664b:ce80:cf7b) I'm contacting you to inform you about the presence of a Reflected XSS vulnerability on the www.openldap.org main domain. Through this vulnerability, an attacker could tamper with page rendering, redirect victims to fake OpenLdap pages, or capture users data. This reflected XSS is on GET "id" variable of the current "JitterBug" tracker, and is not properly sanitized before being used to his page. The JitterBug tracker project seems to be suspended (https://www.samba.org/cgi-bin/jitterbug/), this vulnerability isn't specific to your bug tracker. I just open a ticket to report this vulnerability to the samba-jitterbug maintainers (https://bugzilla.samba.org/show_bug.cgi?id=10967). Proof of Concept, tested with Firefox 33.1.1 (screenshot in attachment): http://www.openldap.org/its/index.cgi/Documentation?id=1337</TITLE><img src=x onerror="alert(/Reflected XSS - Yann CAM @ASAfety/)" /><TITLE>;selectid=1337 Screenshots available : http://www.asafety.fr/data/20141126-RXSS_openldap.org_synetis_001.png http://www.asafety.fr/data/20141126-RXSS_openldap.org_synetis_002.png Feel free to contact me for more information, Best regards, Yann CAM - Security Consultant @ASafety - Synetis - www.synetis.com

1 0

Re: (ITS#7987) SIGSEGV in LMDB while adding ldap-entries
by leo＠yuriev.ru 26 Nov '14

26 Nov '14

--e89a8f8389d1c4af560508c7cb28 Content-Type: text/plain; charset=UTF-8 Just run a 'runme.sh' from attached tarball. Problem (coredump) usually is reproduced for 10-20 min. I will try 'git bisect'. Leonid. --e89a8f8389d1c4af560508c7cb28 Content-Type: application/x-gzip; name="its7987-testcase.tar.gz" Content-Disposition: attachment; filename="its7987-testcase.tar.gz" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i2z2cx130 H4sIADIkdlQAA+0723LbyLF+Bb6iF5JWoE2CN1Gy6eUe2xI3q4pWUolyUluKSgUCQxIRLtwZUBLX 0kOS13xMkkpOzkOSb5D/KN0zAAleREmO7c3W4eyKwPT09PT09G1mYC/0Yst3vc6TT1dKWDY3N+hZ 3qqVsk9ZNmuVJ+XKRqVcK5drpfKTUrlUK5eeQOkT8jQqAxHbHOCJP1yMd1/7z7S4YR1cp+G7dl+P 2r9lTrzt20LUIeJdO/R+tGMvCidb4mgK1XUOZFV3nTooSnV4KxjfsWP7iPUj4cURH+o6DTbw3Ibt Bl6YT4dFSB0k6J5xbMeJBmE8psNZ3/ccOz93Ain2YprCC/o+azFnwL14mMxDcpQQ1wc4kUPEvYw4 Qq+GP6rxccyw6/L5Y08Ib+UR0iOSd0jv06x/ELnMcqLwp7T/8sYG2X+1Vq3V8Lm0/89YdFS0C8Z3 d+DV7s4rXQ88ziNOWgHHR2+beoSNvj0EMQydPo8u9PSl4PSYc96PvDCGcqkE5XELZ35kuz1qkTR+ 6jkuy90l8XKf1AXcZ//Vrdoo/le3ttD+y5Wl/X+eIq2WlAA4BlTpAzQyYs9lvPHq9c7OEQLiYZ9h sO1wJnqvQ/eQceGJWNc4i/mwYdTgmQGxF7BoEDfKJThnrG/73gVrGOU6/mfommA2d3ptWyBsKnJi qx3HXDSMp/lnWGl7oRuwuBe5DRWcFcgNG8acmI8dkH2XhbFn+6JB4VkjVnwv8OLGIJRP5iIH3o8z wJ9a+P8FhQ/CgBW8WGy9eL5lid6nGINsfKtWu8P+MdiXkvhPLmCzSvZfq24u7f9zlJUvimhdRbTM nq5/2zxqNlbN/qWb09/s7u/sHjVW3xHwpthjnBWEb/ddfef18euZJheTVX17723ruIktpmA/QBk2 crp+7vm+7ftQ+AFkdwhYIFOHgh24mxsF3wsHV/Dll9iKbgPTCB5AoQNPLbfdxd/4KgYn4kzXYyZi KFyBVYz6LCTbL4howB1WpNjldQecwW907foazK6HnfwoZIBv9WIRf620k4W5+YiCRZhT5IiIhvw4 7kwLQiVpYh99HRwcNvf3dl4fnh01986a+784q5xt5BIm2BVirv7PmO/Vd0qkN0VBEidh2K4LxO+c oZBIOprP7JAIoFQKbtJgZSZdKPTRN3tXjdEICGKh3fZxWYah7fjjOg0xriXJnUCI6wkJQmuIPWeS QCABKUbbbWdqPawplgL7nIHLcB4upNX06YVI1/fvlM3smvpem9vcY4Le/MBtF/HvjLhLaEi6he2H dJ0/qosrkqjyTTIFUj3eycCLT6f7Bueux6HQn+1sBrTdhGvoYojKNmN3MXAjUO2FGOKg3xFw9Pq7 DNaMaDoRhxAFhziJWd28BDfStf2DnaYyvxGXIabrZ6shBuR0AgkSTYDWYMz0qOHC5kV0/tMgsuMs jMUOZNnCSO6CIa6Tsa/HqNfdl+JaKeD1SBOvuwZ8BamnkA5Apprw9dQg2baJ8bwOnMCqeYkqeAlf ffUVGGOBGDkodHH7AacvIe4xFIBGYuPzxKYllDh80YDVMNNF0yjNaRikQ+gsyiVrlVslq1xfNc0y FXiG3XK5oiGREwFQqnS9yuWsVZ50vUqPyRln02v4+oGTxkE6Hv666MH0qQHDSfqj7fvDiSNpXdvd 3z0eOXAvPQPUteJAcBkQKIdCM0cH0Y4EvkWAzqqwalIKhx6Bjd1ZrrAaSjd9h4MrdBYwVvCxkZhB n9WiZcFFrny9cCiKC9n5rHTRwu8am12h6FgMNu+Kh3Nyacie/LGs7O22js9QCZ41zPuklcM0NRo4 vSxHmMjamJZact3p5+UHugGKSRP6HM7oc4j6DClGZQvbU4xS9UUpxTCUS+kgA51o4XzIM5CT8zoq MIEf1XE5R4NDyOLAFudQqdWszB8M+tiVOb0IjKdPnwJlYzHSrBsLlfFefsidjpUCAwG7Ysl6Q6FH ToSEdGPQuu8dbL/eq1FEKG9Wn29AQUAJChuL9aXy9WXEzxfrxpdKJVAd7uUX9SFNgOTyq0pF1+8T Qn+IW6VwPm0pCIWAcZLCnoNIo2y/P9R1JfnGxy7G3Yo7qZyLVG+sFaTZiVJQR7WbhMK3sErUMIPY 29vbSc+xodAev16CYGhXMS0qSQi2ozBmV/F2a18J+pMJQDeTBS29hDQJlvrzMkl1a2P4vJw4h+oj mSuEYPzaRhdDInUi2hLTubJlWQYF90tqwqeaCBSApmV8oOdYoG2OHT/a/2Ofe71usraFURTKulS5 RPpYEZQy1+XEZZ6FqxuFrniYLeiH3x9/e7B/1mpuH+zvtHCfImmgP3gUGczxnIHMINfr6zS/CkL6 tohRTsJ9hpW2k0uYhqRgzjE5+IeukMxiCuIBHnCc4cwxJJCbiEdk3fPyxALrpPnu+to6DqTEycD4 xvMZiCGKJADcKfUHsaCYOinnhfFE0z4Re87IAcyqnsyOpM619l4f7ixQlEIBhyTnfvLq9OZhCoGJ wWKCRZddFMOB7yekKZV4OPkZfZuYQh7SnAhbMpygGiZ6edg82m7uY1ZoKkpT+gpP5TF/EczphmdT Q+WMhCMFnaE7gfwBZJVTZEqhV5Xe4G7qePegjoKbnM3N2iHSXn03wcrNWus3oZHuAzvyfEE6FEwk Z5VOXZAI5bWKFmqeSPMIRx1N/NRnOP9JGfviTzfGPef/lVq1Mr7/K23S/d/mVmV5/vc5ygq82XkD b2znnM5t0kMleXENHXTi+gq0GIOxmpi1nExEXBbbni8A8SZ7RX16CAt7Hvc8IamA6EUD34X9g2No M8DMGSu423HpDAkxBw457ELfjnvo9lVN173Q8Qcu0zRl4zJ3SK2zKDBhCuwiGaCl3h+IL7zwkT18 nzmxd/GoXqEnHoOOPMUR7/bR0WBm94iOo5PMR/Rxh2GXR4NRH73vubRKmpakG+nhUFFSxlad9s8S ZS4Gtep+1J0lgkCFgi/ocHu05kJFqPKmHkeRX0iBGzpqjMs6KAr4DnWyb3PMDGKUiN5W6qlpGO51 0g3KG2RlJbCv6GZHK5e2qlsb5eeVDT0FabXq5vOt0otyRV9h4UXHt7tCu+Qe5iS4M8A/m+6+9Nmm MJINczqpFvC9DubDke0z4TCIooDyeOSeTEjNQNfFoNPxrjTNGF1U8SiK3XAa0r9EiNqjYEhyPY66 FvHhhBRTc3AZEsx8PALsBxw1vXcH0WeO1/EckJhe2AU6hoAIs0AuwBZocT8McAA3p2ghvzEfUiKE dDKQt293dwikr2Tu+GV5IQvuUWdaKjX05FCabYDn5ReVeQ0l2t2uSF/S+n5/+6h5uIfV23/e/g1u /377p9s/v//D7V/f//H97xHw/ne3/0LgX2//9P737/+oqv/Clr9Y4IZg0r2g44r8xLdFdMeYg9u/ wO2fkdrfkYqJ/f5h0RD/d/u/t3/L6fIeUCAJi13ZTnzHBSMAqVPm2hDkZWcGoK+4qMMB7nZwkhw2 Kvj/zyQrmHMo8NHHWBz/6Zu/zeT+D8HVGsb/SmVjaxn/P0fxgn7EY/XVXvJOyp0H5ZbRieQBfXdX vnA7dKMAtxIxx3qKj9u8PEQCreBBBY38l2F0GcoxIcmuaRecfnAnT3hwm3Kir2gnxviESB4PGXnY x/3ZaV6faSuP22Y7VhY1Vhc1bowbTx86Rb3biqM+zuEb2xeMItIhjyg60rzIU+pY8TOwLEYRHSP2 t3F714B3N7o67Wo5GMYRIKNpa/vgsHnWevvm+KjZxMjrnGPLaMWsPQSYOV13ZJBoDdoiIW6q4JGr 6xr6TaSurbvheh2k43tXuslPf5uRp8uI9SByBWKdaKaRiT4olxMj+6Wj7R/K/AUbjP7oDQVBDxxB fedonOYkVSwmQSUZHHsC7oQSXJ4AigwQThF8Q4fO7XJ2Ik7YoDuRIP/BM8JNuOewlPM5TEn6UzxU pniIKbGNPyETaoAMF7r2Si63+nQG15fhxlZeKJiC+Z08nCEz+Evj0/prXT9q2z5ITc2DUjikopE2 WbYjMwVUInlvRn3JRBUW9VZonPkMg4dEo6+BBpyOmxTWCXU6RbmU9RlshFBqwvNSnQW/yCGeZA1b MAORI0gNJd4tN1T1EyWy05My0Z3UHgsTicCOTRo1dyoZSmhbONKZMKk7rs/pBGIexlQlW6lCyXHp fZYQQeeSUg1TxCoZYpW5xCp3EatMEpsSK2a1chmkb7boQM00kCZzYX1NrEMcwZowYA3umjjJPycp syuH9VUMsOg8vUmfgFK+yDhP1loNwqjBNL7BjR8OE8s7QTUa6saawK2dYw8Ek6D7hpZRxESKuVwu mZ30mMd8wOYpM/6hwn8MZZZcYCofjzU6Bzhhc0LAX6CEc4/U9NIHavoinVPTvlvt7le0LIV5uqYo TFvbTO+5a5n0ZT5kRTFHMzkLootUNzs8Cj6DdirWFyronbZ8v4o+LBVY0ckRd1l8ppInufQmKVai slLOusYdJLwvL/xxS8GVMmFWkFTKmDJolz06SiHF5U5d6bJqlvkDvUp5cNvDKTal2DAqm8Z+BPKa zInCkE4y6GgnGoTSo6+5koYd05ENiYRq0lCI8jPlvXFPijyoCVhOL8LQZEq+E4vCdnTJanCJyRw9 MRJkVadtHnkmnqQoFhyx7sC3+ZDAoqjWSYCIAgZ9lakoHVFDJkmilKSkI+U3loZcFxqd+o4ZpQfu Ns1yPpteEcuZjMhKYiR1TWz0RPKAovBZmEwTyAV/vEko3I86jcQ7PmAaxABln3L0SSP9BsF0bIBK kcxA2Wg2WSVToD27JI4KdIX8dRlxN4FV/1AxT7E0yoo7CW/ydjOZRqLQWXNKIkBiVfRvd1CS4xMX rZ/8Sx6Cjk5d5IToiIcmJLuOzStINZvujbxQBietF4kYKcjm0mnGk6fMu6w96JrGMR8Sz+iL6BNm wDyl/q588+pdZZyvEIt5SNnKA5FW7sZPs326nvJs3/uRmem9eTbjyfSwUKRx5ET+GW2qyNATEr9q HrV2D/arCkugO1LHtFLw1sHh8dl+8/jXB0e/PDve/a558PY4D1WrlBBVn2Gf0RSm2FXuf3LFWgPH YUJ0Br4/lNNWzhg5JqeN059gPA9EUbGfSJt4/o/8vpT1xJCTjn92/GlPvzLp6knXAtsLZxRtrK1t W3jOtjwIN312wfxG2rLTfPP2F3lQYzbW10xbOLTFzpVfCIA1hU2XoDlVD1B4dpflxDomp2gznYB6 fV9YCwpol2vf1te+q6+11pHPkfrTtSUZtPr03ZKfF5g1rK7QPbpZomWSvqs8sU08lm9mbHOMT9gi UXIJauXhqNWHo248CDXxj4u5TZDG6Is5nkFfzPUM+mLOR+ipoC35IZM5kuZUvTpV3xjX08nPQCoz kOoMZExn0qmNvfRmCZ5CtSQddEZbykkoj4RFtzAWKo6IBW43I47utj6T/syYPSG6g6D/hZFQGoUz rY2yOn8pP12YiHNTBKfcCLb1sWpkZPrbiGxwJNKJanWyujGqjuQ5BahMA6rTgDGN6TAZeqLHXGRN eYWfyVnvsizLsizLsizLsizLsizLsizLsizLsizLsvz/K/8GiErmgABQAAA= --e89a8f8389d1c4af560508c7cb28--

1 0

(ITS#7987) SIGSEGV in LMDB while adding ldap-entries
by leo＠yuriev.ru 26 Nov '14

26 Nov '14

Full_Name: Leonid Yuriev Version: 2.4 git head (OPENLDAP_REL_ENG_2_4 branch) OS: Ubuntu 14.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (31.130.36.33) Multi-master cluster of 4 nodes. Testcase will be available shortly (config + script). Program terminated with signal 11, Segmentation fault. #0 0x00000000004a2e25 in mdb_cursor_put (mc=0x7f81f915c370, key=0x7f82177fd120, data=0x7f82177fd130, flags=32) at ./../../../libraries/liblmdb/mdb.c:6358 6358 nsize = IS_LEAF2(mc->mc_pg[mc->mc_top]) ? key->mv_size : mdb_leaf_size(env, key, rdata); (gdb) bt #0 0x00000000004a2e25 in mdb_cursor_put (mc=0x7f81f915c370, key=0x7f82177fd120, data=0x7f82177fd130, flags=32) at ./../../../libraries/liblmdb/mdb.c:6358 #1 0x00000000004a2b52 in mdb_cursor_put (mc=mc@entry=0x7f81f915c370, key=key@entry=0x7f82177fd120, data=data@entry=0x7f82177fd130, flags=flags@entry2%2) at ./../../../libraries/liblmdb/mdb.c:6471 #2 0x00000000004d3e58 in mdb_idl_insert_keys (be=<optimised out>, cursor=0x7f81f915c370, keys=<optimised out>, id=997543) at idl.c:534 #3 0x00000000004d5143 in indexer (op=0x7f81ed1356e0, txn=0x0, atname=0%0, vals=0x7f81f81026d0, id=997543, opid=1, mask=4, ad=<optimised out>, ai=<optimised out>, ai=<optimised out>) at index.c:219 #4 0x00000000004d5445 in index_at_values (op=0x7f81ed1356e0, txn=0x1b55110, type=0x194a270, tags=0x1943830, vals=0x7f81f81026d0, id=997543, opid=1, ad=<optimised out>) at index.c:337 #5 0x00000000004d59f9 in mdb_index_values (opid=<optimised out>, id=<optimised out>, vals=<optimised out>, desc=<optimised out>, txn=<optimised out>, op=<optimised out>) at index.c:386 #6 mdb_index_entry (op=0x0, txn=0x2C o opid=394252592, e=0x8) at index.c:558 #7 0x00000000004c9159 in mdb_add (op=0x7f81ed1356e0, rs=0x7f82177fda80) at add.c:359 #8 0x000000000048a346 in overlay_op_walk (op=op@entry=0x7f81ed1356e0, rs=0x7f82177fda80, which=op_add, oi=0x19a3730, on=0x0)t t backover.c:671 #9 0x000000000048a4b1 in over_op_func (op=0x7f81ed1356e0, rs=<optimised out>, which=<optimised out>) at backover.c:723 #10 0x000000000042a9b0 in fe_op_add (op=0x7f81ed1356e0, rs=0x7f82177fda80) at add.c:334 #11 0x000000000042b59f in do_add (op=0x7f81ed1356e0, rs=0x7f82177fda80) at add.c:194 #12 0x0000000000424624 in connection_operation (ctx=0x7f82177fdbd0, arg_v=0x7f81ed1356e0) at connection.c:1155 #13 0x0000000000424d3c in connection_read_thread (ctx=0x7f82177fdbd0, argv=0x13) at connection.c:1291 #14 0x00007f824def1cf2 in ldap_int_thread_pool_wrapper (xpool=0x1956090) at tpool.c:688 #15 0x00007f824dabc0a5 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #16 0x00007f824d7e984d in clone () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) p * mc $1 = {mc_next = 0x0, mc_backup = 0x0, mc_xcursor = 0x7f81f915c4f8, mc_txn = 0x1b55110, mc_dbi = 5, mc_db = 0x1b55288, mc_dbx = 0x1b52660, mc_dbflag = 0x1b57015 "\v\n\n", mc_snum = 0, mc_top = 0, mc_flags % 6 64, mc_pg = {0x0, 0x7f822f03f000, 0x7f822f287000, 0x308f, 0x2fb0, 0x2e37, 0x2d75, 0x2bbc, 0x2b76, 0x28eb, 0x25f4, 0x2582, 0x2439, 0x225f, 0x21d0, 0x1fdd, 0x1c89, 0x1b68, 0x1b00, 0x19db, 0x1323, 0xf00, 0x895, 0x223, 0x12b, 0x3cb, 0x32b, 0xe5, 0x0, 0x7f81f9006e63, 0x941, 0x7f81f80005b8}, mc_ki = {0, 0, 0, 0, 50336, 63765, 32641, 0, 50336, 63765, 32641, 0, 3, 0, 12849, 14641, 21032, 437, 0, 0, 9728, 437, 0, 0, 28691, 437, 0, 0, 3, 2, 65, 0}} (gdb) p mc->mc_top $2 = 0 (gdb) p mc->mc_pg $3 = {0x0, 0f8f822f03f000, 0x7f822f287000, 0x308f, 0x2fb0, 0x2e37, 0x2d75, 0x2bbc, 0x2b76, 0x28eb, 0x25f4, 0x2582, 0x2439, 0x225f, 0x21d0, 0x1fdd, 0x1c89, 0x1b68, 0x1b00, 0x19db, 0x1323, 0xf00, 0x895, 0x223, 0x12b, 0x3cb, 0x32b, 0xe5, 0x0, 0x7f81f9006e63, 0x941, 0x7f81f80005b8} (gdb) p mc->mc_pg[mc->mc_top] $4 = (MDB_page *) 0x0 git show commit 6b26910c5acbf141ff322d043b3301d0976a7913 Author: Quanah Gibson-Mount <quanah(a)openldap.org> Date: 2014-10-03 15:35:39 -0500 Silence compiler warning by adding explicit return 0 to ppolicy_db_destroy

1 0

(ITS#7986) -y option issue during read the password from a file
by shifeng.hu＠ericsson.com 21 Nov '14

21 Nov '14

Full_Name: Shifeng Hu Version: openldap2-2.4.26-0.26.1 OS: SUSE 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.200) Dear There Our server is using LDAP, but I found there was an issue when I use -y file option to set the password of LDAP User. the User password was defined in server system as 7 characters without any "\0" when I try to use ldapsearch or ldapmodify with the option -y to give the password I am for sure the password in file is exactly same with I set. And I did a capture for LDAP, I saw there is a \0 in the suffix of password, this means the tool adds an additional '\0' in the last. then I got the error output li%0 below ldap_bind: Invalid credentials (49) As I check the src in the file "libraries\liblutil\passfile.c" passwd->bv_len = nread; passwd->bv_val[nread] = '\0'; is this necessary for a \0 BR//shifeng Thanks!

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs