- openldap-bugs - openldap.org

(ITS#7834) MDB_MULTIPLE can insert multiple keys
by h.b.furuseth＠usit.uio.no 12 Apr '14

12 Apr '14

Full_Name: Hallvard B Furuseth Version: LMDB 0.9.11 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.191.45.35) Submitted by: hallvard mdb_cursor_put(,new key, multiple data items, MDB_MULTIPLE) inserts several identical keys as well as multiple data items. Broken since 0.9.10 by 4c8f57615c5ca7b014c038e59c1045182e74f5ad. OpenLDAP is not affected, since it no longer uses MDB_MULTIPLE. Root cause: mdb_cursor_put() does not reset the 'insert' flag when looping through MDB_MULTIPLE. Recently it uses that flag to decode whether to delete the old key before re-inserting it. Also MDB_MULTIPLE breaks MDB_db.md_entries so mdb_stat() reports the wrong number of entries. This was always so. The 'insert' flag also affects cursor tracking. I have not checked how. Fix: Reset 'insert' before looping, and move setting C_INITIALIZED at 'done:' before that again. This should make MDB_MULTIPLE behave like a sequence of put()s, except it does not repeat spill/touch.

1 0

Re: (ITS#7832) Proposing ppolicy extended module for OpenLDAP
by hyc＠symas.com 10 Apr '14

10 Apr '14

dcoutadeur(a)linagora.com wrote: > Full_Name: David Coutadeur > Version: 2.4.39 > OS: Debian wheezy 64 > URL: http://62.210.236.82/incoming/ppm-1.0.tar.gz > Submission from: (NULL) (92.103.166.6) > > > > Hi, > > I am proposing this module extending password policy for integration into > contrib/slapd-modules. (see URL attached) > > I get inspired by the ltb check password module, but I finally rewrote > everything from scratch to better include new functionnalities. > > You can consider this as a replacement for ITS Incoming/7412 > > The code has been tested a little, and a work has been done to make the code > cleaner, but do not hesitate for any suggestion or remark. I took a brief look at it. The config file syntax seems a bit awkward, how do you distinguish a new class name from an existing reserved keyword? I'd like to hear other people's opinion on the actual checks being performed. > David > > -- -- 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#7833) ldap client configuration issue
by hyc＠symas.com 10 Apr '14

10 Apr '14

prabhs(a)gmail.com wrote: > Full_Name: prabhakar > Version: 4.3 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (59.161.164.4) > > > When root file system is full, we are observing that ldap client file is getting > deleted. LDAP authentication failing, again we need to reconfigure the ldap > client. There is no such OpenLDAP version 4.3. > > Is there any way to overcome this issue. > > libsldap: Status: 2 Mesg: Unable to load configuration > '/var/ldap/ldap_client_file' (''). There is no such OpenLDAP component named libsldap. It appears you're not using OpenLDAP software at all. We're not the right people to help you. This ITS will be closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7833) ldap client configuration issue
by prabhs＠gmail.com 10 Apr '14

10 Apr '14

Full_Name: prabhakar Version: 4.3 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.161.164.4) When root file system is full, we are observing that ldap client file is getting deleted. LDAP authentication failing, again we need to reconfigure the ldap client. Is there any way to overcome this issue. libsldap: Status: 2 Mesg: Unable to load configuration '/var/ldap/ldap_client_file' ('').

1 0

Re: (ITS#7500) libldap starttls crashes if invalid GnuTLS cipher suite string
by quanah＠zimbra.com 08 Apr '14

08 Apr '14

--On April 9, 2014 at 1:55:26 AM +0000 ryan(a)nardis.ca wrote: > Hi, > > This ITS says "fixed in master" and appears to be in 2.5 as well. > However 2.4 seems to still be affected. Is this fix a candidate for 2.4? It will be in 2.4.40 and is now in RE24. Thanks for catching that. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7500) libldap starttls crashes if invalid GnuTLS cipher suite string
by ryan＠nardis.ca 08 Apr '14

08 Apr '14

Hi, This ITS says "fixed in master" and appears to be in 2.5 as well. However 2.4 seems to still be affected. Is this fix a candidate for 2.4? thanks, Ryan

1 0

(ITS#7412)
by dcoutadeur＠linagora.com 04 Apr '14

04 Apr '14

Hi, Can you consider this alternative to replace ltb-check-password module into the contrib overlays ? (ITS#7832) Proposing ppolicy extended module for OpenLDAP http://www.openldap.org/its/index.cgi?findid=7832 Thank you in advance. David

1 0

(ITS#7832) Proposing ppolicy extended module for OpenLDAP
by dcoutadeur＠linagora.com 04 Apr '14

04 Apr '14

Full_Name: David Coutadeur Version: 2.4.39 OS: Debian wheezy 64 URL: http://62.210.236.82/incoming/ppm-1.0.tar.gz Submission from: (NULL) (92.103.166.6) Hi, I am proposing this module extending password policy for integration into contrib/slapd-modules. (see URL attached) I get inspired by the ltb check password module, but I finally rewrote everything from scratch to better include new functionnalities. You can consider this as a replacement for ITS Incoming/7412 The code has been tested a little, and a work has been done to make the code cleaner, but do not hesitate for any suggestion or remark. David

1 0

(ITS#7831) Double Free in autogroup.c
by mwarren＠symas.com 04 Apr '14

04 Apr '14

Full_Name: Mark Warren Version: 2.4.38 OS: Ubuntu 12.04.4 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.70.80.130) A double-free has been located in contrib/slapd-modules/autogroup/autogroup.c Lines: 1208 and 1215 Proposed solution: Remove Line 1215 diff --git a/contrib/slapd-modules/autogroup/autogroup.c b/contrib/slapd-modules/autogroup/autogroup.c index a977561..5bafe2f 100644 --- a/contrib/slapd-modules/autogroup/autogroup.c +++ b/contrib/slapd-modules/autogroup/autogroup.c @@ -1212,7 +1212,6 @@ autogroup_response( Operation *op, SlapReply *rs ) autogroup_add_group( op, agi, group_agd, NULL, &op->o_req_ndn, 1, 1); - overlay_entry_release_ov( op, e, 0, on ); ldap_pvt_thread_mutex_unlock( &agi->agi_mutex ); return SLAP_CB_CONTINUE; }

1 0

Re: (ITS#7412) check_password contrib module
by hyc＠symas.com 04 Apr '14

04 Apr '14

clem.oudot(a)gmail.com wrote: > Full_Name: Clément OUDOT > Version: > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.173.78.196) > > > As said by Guillaume Rousse in ITS#7348 ( > http://www.openldap.org/its/index.cgi/Incoming?id=7348;selectid=7348#themesg), I > would like to contribute the check_password module to OpenLDAP. > diff --git a/contrib/slapd-modules/check-password/README b/contrib/slapd-= > modules/check-password/README > new file mode 100644 > index 0000000..10191c2 > --- /dev/null > +++ b/contrib/slapd-modules/check-password/README > @@ -0,0 +1,146 @@ > + > +check_password.c - OpenLDAP pwdChecker library > + > +2007-06-06 Michael Steinmann <msl(a)calivia.com> > +2008-01-30 Pierre-Yves Bonnetain <py.bonnetain(a)ba-cst.com> > +2009 Clement Oudot <clem.oudot(a)gmail.com> - LTB-project > +2009 Jerome HUET - LTB-project > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following patch(es) were > developed by Clément OUDOT clem.oudot(a)gmail.com. I have not assigned rights > and/or interest in this work to any party. Something is not clear here. Your README clearly lists 3 other authors' names, yet your rights statement claims that you are the sole author. I don't see how we can safely touch this contribution with such ambiguous provenance. > > I, Clément OUDOT, hereby place 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#7829) MDB mdb_cursor_del causes records to be skipped
by h.b.furuseth＠usit.uio.no 03 Apr '14

03 Apr '14

Another mdb_cursor_del() issue: If the next operation moves/peeks at the cursor position, it does not always reset the C_DEL flag: * mdb_cursor_put(,&existing_key,, MDB_APPEND or MDB_NOOVERWRITE) works like mdb_cursor_get(, &existing_key,, MDB_SET) but does not clear C_DEL. So MDB_NEXT after that stays at &existing_key. The enclosed program illustrates this: the MDB_NEXTs give different results after the cursor was positioned at "f". * I'm guessing mdb_cursor_count() should reset C_DEL on the main cursor: The mdb_cursor_del() semantics seems to be something like "the cursor moves to the next item, however if the next operation is an MDB_NEXT* operation then it also returns that item. So the manner you peek at the cursor position determines whether the the next item is "next" or "current". But I haven't thought carefully about C_DEL vs. DUPSORT cursors. BTW, mc->mc_flags &= ~C_DEL; would be a bit simpler than if (mc->mc_flags & C_DEL) mc->mc_flags ^= C_DEL; ################################################################ #include <stdio.h> #include <stdlib.h> #include "lmdb.h" #define E(expr) CHECK((rc = (expr)) == MDB_SUCCESS, #expr) #define CHECK(test, msg) ((test) ? (void)0 : ((void)fprintf(stderr, \ "%s:%d: %s: %s\n", __FILE__, __LINE__, msg, mdb_strerror(rc)), abort())) int main(void) { int rc, i; char ch, *act; MDB_env *env; MDB_txn *txn; MDB_dbi dbi; MDB_cursor *cursor; MDB_cursor_op op; remove("test.mdb"); E(mdb_env_create(&env)); E(mdb_env_open(env, "test.mdb", MDB_NOSUBDIR, 0664)); E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_open(txn, NULL, 0, &dbi)); E(mdb_cursor_open(txn, dbi, &cursor)); for (op=MDB_NEXT, act="NEXT";; op=MDB_GET_CURRENT, act="GET_CURRENT") { MDB_val key, data = {0, ""}; for (ch = 'a'; ch <= 'h'; ch++) E(mdb_cursor_put(cursor, &(MDB_val){1, &ch}, &data, 0)); for (i = 0; i < 2; i++) { E(mdb_cursor_get(cursor, &key, NULL, MDB_FIRST)); E(mdb_cursor_del(cursor, 0)); if (i == 0) { E(mdb_cursor_get(cursor, &(MDB_val){1, "f"}, NULL, MDB_SET)); } else { rc = mdb_cursor_put(cursor, &(MDB_val){1, "f"}, &data, MDB_NOOVERWRITE); /* C_DEL vs. MDB_NEXT bug? */ CHECK(rc == MDB_KEYEXIST, "no-overwrite"); } rc = mdb_cursor_get(cursor, &key, &data, op); if (rc == MDB_SUCCESS) printf("MDB_%s = %c\n", act, *(char *)key.mv_data); else printf("MDB_%s = %s\n", act, mdb_strerror(rc)); } if (op == MDB_GET_CURRENT) break; } mdb_txn_abort(txn); mdb_env_close(env); return 0; }

1 0

Re: (ITS#7829) MDB mdb_cursor_del causes records to be skipped
by h.b.furuseth＠usit.uio.no 02 Apr '14

02 Apr '14

I wrote: > Nope. 69edafe28aef03b965c3d911be9ab8e340f914e1 "ITS#7829 more for > prev commit" breaks test054-syncreplication-parallel-load in RE24 > (with normal pagesize), every 2nd run or so. Or rather fca18d2586259c0e802d0276f86be696863b1905, not the ID I was using when bisecting:-)

1 0

Re: (ITS#7829) MDB mdb_cursor_del causes records to be skipped
by h.b.furuseth＠usit.uio.no 02 Apr '14

02 Apr '14

Howard Chu writes: > Thanks, confirmed. In a nested rebalance, doing a page merge with the > neighbor on the left was discarding the rebalanced state. Fixed now in > mdb.master Nope. 69edafe28aef03b965c3d911be9ab8e340f914e1 "ITS#7829 more for prev commit" breaks test054-syncreplication-parallel-load in RE24 (with normal pagesize), every 2nd run or so. Running ./scripts/test054-syncreplication-parallel-load for mdb... running defines.sh Starting provider slapd on TCP/IP port 9011... Using ldapsearch to check that provider slapd is running... Using ldapadd to create the context prefix entry in the provider... Starting consumer slapd on TCP/IP port 9014... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the provider directory... Waiting 7 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that provider slapd is running... Waiting 10 seconds to let the system catch up Using ldapmodify to modify provider directory... ldapmodify failed (80)! slapd.1.log says: 533bbaa2 mdb_modrdn: new ndn=cn=rosco p. coltrane,ou=retired,ou=people,dc=example,dc=com 533bbaa2 => mdb_dn2id("cn=rosco p. coltrane,ou=retired,ou=people,dc=example,dc=com") 533bbaa2 <= mdb_dn2id: get failed: MDB_NOTFOUND: No matching key/data pair found (-30798) 533bbaa2 => mdb_dn2id_delete 0x2a 533bbaa2 <= mdb_dn2id_delete 0x2a: -30798 533bbaa2 <=- mdb_modrdn: dn2id del failed: MDB_NOTFOUND: No matching key/data pair found (-30798) 533bbaa2 send_ldap_result: conn=1002 op=8 p=3 533bbaa2 send_ldap_result: err=80 matched="" text="DN index delete fail" This dn2id.c assert() would catch it. Passing -MDB_SET to catch it in a patched liblmdb before that. diff --git a/servers/slapd/back-mdb/dn2id.c b/servers/slapd/back-mdb/dn2id.c index ceacb17..8cb9d91 100644 --- a/servers/slapd/back-mdb/dn2id.c +++ b/servers/slapd/back-mdb/dn2id.c @@ -243,3 +243,4 @@ mdb_dn2id_delete( do { - rc = mdb_cursor_get( mc, &key, &data, MDB_SET ); + rc = mdb_cursor_get( mc, &key, &data, -MDB_SET ); + assert(!rc); if ( !rc ) { mdb.c fails at 1st assert, the rest is for handling -MDB_SET: diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 10a8358..71b0b93 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -5348,2 +5348,3 @@ mdb_cursor_set(MDB_cursor *mc, MDB_val *key, MDB_val *data, rc = mc->mc_dbx->md_cmp(key, &nodekey); + mdb_cassert(mc, op != (MDB_cursor_op)-MDB_SET || rc >= 0 || mc->mc_top); if (rc == 0) { @@ -5460,3 +5461,3 @@ set1: if (F_ISSET(leaf->mn_flags, F_DUPDATA)) { - if (op == MDB_SET || op == MDB_SET_KEY || op == MDB_SET_RANGE) { + if (op == MDB_SET || op == (MDB_cursor_op)-MDB_SET || op == MDB_SET_KEY || op == MDB_SET_RANGE) { rc = mdb_cursor_first(&mc->mc_xcursor->mx_cursor, data, NULL); @@ -5651,2 +5652,3 @@ mdb_cursor_get(MDB_cursor *mc, MDB_val *key, MDB_val *data, case MDB_SET_RANGE: + case (MDB_cursor_op)-MDB_SET: if (key == NULL) { @@ -5747,2 +5749,3 @@ fetchm: DPRINTF(("unhandled/unimplemented cursor operation %u", op)); + mdb_cassert(mc, 0); /* just checking that we never get here */ rc = EINVAL; #2 mdb_assert_fail () #3 mdb_cursor_set (mc=0x7fabb4102bb0, key=0x7fabbf276260, data=0x7fabbf276250, op=4294967281, exactp=0x7fabbf2761f0) at mdb.c:5349 #4 mdb_cursor_get (mc=0x7fabb4102bb0, key=0x7fabbf276260, data=0x7fabbf276250, op=4294967281) at mdb.c:5657 #5 mdb_dn2id_delete (op=0x7fabb4000960, mc=0x7fabb4102bb0, id=42, nsubs=1) at dn2id.c:244 #6 mdb_modrdn (op=0x7fabb4000960, rs=0x7fabbf276910) at modrdn.c:476 #7 overlay_op_walk (op=0x7fabb4000960, rs=0x7fabbf276910, which=op_modrdn, oi=0x1c2c120, on=0x0) at backover.c:671 #8 over_op_func (op=0x7fabb4000960, rs, which) at backover.c:723 #9 fe_op_modrdn (op=0x7fabb4000960, rs=0x7fabbf276910) at modrdn.c:314 #10 do_modrdn (op=0x7fabb4000960, rs=0x7fabbf276910) at modrdn.c:186 #11 connection_operation (ctx=0x7fabbf276a70, arg_v=0x7fabb4000960) at connection.c:1155 #12 connection_read_thread (ctx=0x7fabbf276a70, argv) at connection.c:1291 #13 ldap_int_thread_pool_wrapper (xpool=0x1bd7370) at tpool.c:688 (gdb) frame 3 #3 mdb_cursor_set (mc=0x7fabb4102bb0, key=0x7fabbf276260, data=0x7fabbf276250, op=4294967281, exactp=0x7fabbf2761f0) at mdb.c:5349 5349 mdb_cassert(mc, op != (MDB_cursor_op)-MDB_SET || rc >= 0 || mc->mc_top); (gdb) info locals nodekey = {mv_size = 8, mv_data = 0x7fabb01092da} rc = -8 mp = 0x7fabb0108310 leaf = 0x7fabb01092d2 __FUNCTION__ = "mdb_cursor_set" (gdb) set output-radix 16 (gdb) p *mp $1 = {mp_p = {p_pgno = 0x51, p_next = 0x51}, mp_pad = 0x0, mp_flags = 0x12, mp_pb = {pb = {pb_lower = 0x44, pb_upper = 0xa2a}, pb_pages = 0xa2a0044}, mp_ptrs = {0xfc2}} (gdb) p *leaf $2 = {mn_lo = 0x2e, mn_hi = 0x0, mn_flags = 0x0, mn_ksize = 0x8, mn_data = "\020"} (gdb) p *(MDB_ID*)key->mv_data $3 = 0x8 (gdb) p *(MDB_ID*)nodekey.mv_data $4 = 0x10 -- Hallvard

1 0

Re: (ITS#7742) New: PBKDF2 module for OpenLDAP
by michael＠stroeder.com 01 Apr '14

01 Apr '14

hyc(a)symas.com wrote: > hamano(a)osstech.co.jp wrote: >> Full_Name: HAMANO Tsukasa >> Version: git master >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/0001-New-PBKDF2-module.patch >> Submission from: (NULL) (240b:10:2640:bf0:c1b8:b6c9:76f:8964) >> >> >> PBKDF2(RFC 2898) suport for OpenLDAP >> See README for details. > > Thanks for the submission, added to git master. Any chance to have this in upcoming 2.4.40? I've successfully tested it before in a local build. Ciao, Michael.

1 0

Re: (ITS#7742) New: PBKDF2 module for OpenLDAP
by hyc＠symas.com 01 Apr '14

01 Apr '14

hamano(a)osstech.co.jp wrote: > Full_Name: HAMANO Tsukasa > Version: git master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/0001-New-PBKDF2-module.patch > Submission from: (NULL) (240b:10:2640:bf0:c1b8:b6c9:76f:8964) > > > PBKDF2(RFC 2898) suport for OpenLDAP > See README for details. Thanks for the submission, added to git master. > > -- > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by HAMANO Tsukasa <hamano(a)osstech.co.jp>. I > have not assigned rights and/or interest in this work to any party. > > Copyright 2013 HAMANO Tsukasa <hamano(a)osstech.co.jp> > Redistribution and use in source and binary forms, with or without > modification, are permitted only as authorized by the OpenLDAP Public > License. > > -- -- 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#7829) MDB mdb_cursor_del causes records to be skipped
by armon.dadgar＠gmail.com 01 Apr '14

01 Apr '14

--533b042f_327b23c6_a8c6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I agree that it would be great to have MDB=5FNOT=46OUND returned instead of EINVAL. =46or my purposes, I needed a work around to the issue, and this seemed to work. Additionally because I=E2=80=99m in Go an= d not C, I cannot easily make use of the system definition for EINVAL. Best Regards, Armon Dadgar =46rom:=C2=A0Hallvard Breien =46uruseth h.b.furuseth=40usit.uio.no Reply:=C2=A0Hallvard Breien =46uruseth h.b.furuseth=40usit.uio.no Date:=C2=A0April 1, 2014 at 8:36:43 AM To:=C2=A0armon.dadgar=40gmail.com armon.dadgar=40gmail.com Cc:=C2=A0openldap-its=40openldap.org openldap-its=40openldap.org Subject:=C2=A0 Re: (ITS=237829) MDB mdb=5Fcursor=5Fdel causes records to = be skipped =20 On =46ri, 2014-03-28 at 04:58 +0000, armon.dadgar=40gmail.com wrote: =20 > I have a gist demonstrating this: https://gist.github.com/armon/9825666= =20 Some notes about this code: =20 // LMDB will return EINVAL(22) for the GET=5FCURRENT op if =20 // there is no further keys. We treat this as no more =20 // keys being found. =20 if num, ok :=3D err.(mdb.Errno); ok && num =3D=3D 22 =7B =20 println(=22errno 22=22) =20 err =3D mdb.Not=46ound =20 =7D =20 The value of EINVAL is OS-dependent, it need not be 22. =20 EINVAL means you did something wrong, it's a bad idea to =20 assume it means any particular wrong thing. =46or one thing, =20 mdb might not keep catching that error. I'd follow up =20 with a test check that there are indeed no more keys. =20 That said, mdb=5Fcursor=5Fdel() followed by MDB=5FGET=5FCURRENT =20 seems to me a sensible thing to want to do. So I think =20 MDB=5FGET=5FCURRENT should return MDB=5FNOT=46OUND here. And maybe =20 also after cursor=5Fnext() returned MDB=5FNOT=46OUND, and on an =20 empty DB. OTOH maybe cursors would need to keep more state =20 to tell this from user errors which should get EINVAL. =20 --533b042f_327b23c6_a8c6 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <html><head><style>body=7Bfont-family:Helvetica,Arial;font-size:13px=7D</= style></head><body style=3D=22word-wrap: break-word; -webkit-nbsp-mode: s= pace; -webkit-line-break: after-white-space;=22><div id=3D=22bloop=5Fcust= omfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color: r= gba(0,0,0,1.0); margin: 0px; line-height: auto;=22>I agree that it would = be great to have MDB=5FNOT=46OUND returned</div><div id=3D=22bloop=5Fcust= omfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color: r= gba(0,0,0,1.0); margin: 0px; line-height: auto;=22>instead of EINVAL. =46= or my purposes, I needed a work around to the</div><div id=3D=22bloop=5Fc= ustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color= : rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22>issue, and this see= med to work. Additionally because I=E2=80=99m in Go and not</div><div id=3D= =22bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size= :13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22>C, I ca= nnot easily make use of the system definition for EINVAL.</div><div id=3D= =22bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size= :13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22><br></d= iv> <div id=3D=22bloop=5Fsign=5F1396376480489799936=22 class=3D=22bloop=5F= sign=22><div style=3D=22font-family:helvetica,arial;font-size:13px=22>Bes= t Regards,</div><div style=3D=22font-family:helvetica,arial;font-size:13p= x=22>Armon Dadgar<br></div></div> <div style=3D=22color:black=22><br>=46r= om: <span style=3D=22color:black=22>Hallvard Breien =46uruseth</span= > <a href=3D=22mailto:h.b.furuseth=40usit.uio.no=22>h.b.furuseth=40usit.u= io.no</a><br>Reply: <span style=3D=22color:black=22>Hallvard Breien = =46uruseth</span> <a href=3D=22mailto:h.b.furuseth=40usit.uio.no=22>h.b.f= uruseth=40usit.uio.no</a><br>Date: <span style=3D=22color:black=22>A= pril 1, 2014 at 8:36:43 AM</span><br>To: <span style=3D=22color:blac= k=22>armon.dadgar=40gmail.com</span> <a href=3D=22mailto:armon.dadgar=40g= mail.com=22>armon.dadgar=40gmail.com</a><br>Cc: <span style=3D=22col= or:black=22>openldap-its=40openldap.org</span> <a href=3D=22mailto:openld= ap-its=40openldap.org=22>openldap-its=40openldap.org</a><br>Subject:&nbsp= ;<span style=3D=22color:black=22> Re: (ITS=237829) MDB mdb=5Fcursor=5Fdel= causes records to be skipped <br></span></div><br> <blockquote type=3D=22= cite=22 class=3D=22clean=5Fbq=22><span><div><div></div><div>On =46ri, 201= 4-03-28 at 04:58 +0000, armon.dadgar=40gmail.com wrote: <br>> I have a gist demonstrating this: https://gist.github.com/armon/= 9825666 <br> <br>Some notes about this code: <br> // LMDB will return EINVAL(22) for the GET=5FCURRENT op if <br> // there is no further keys. We treat this as no more <br> // keys being found. <br> if num, ok :=3D err.(mdb.Errno); ok && num =3D=3D 22 =7B <br> println(=22errno 22=22) <br> err =3D mdb.Not=46ound <br> =7D <br> <br>The value of EINVAL is OS-dependent, it need not be 22. <br> <br>EINVAL means you did something wrong, it's a bad idea to <br>assume it means any particular wrong thing. =46or one thing, <br>mdb might not keep catching that error. I'd follow up <br>with a test check that there are indeed no more keys. <br> <br> <br>That said, mdb=5Fcursor=5Fdel() followed by MDB=5FGET=5FCURRENT <br>seems to me a sensible thing to want to do. So I think <br>MDB=5FGET=5FCURRENT should return MDB=5FNOT=46OUND here. And maybe <br>also after cursor=5Fnext() returned MDB=5FNOT=46OUND, and on an <br>empty DB. OTOH maybe cursors would need to keep more state <br>to tell this from user errors which should get EINVAL. <br> <br></div></div></span></blockquote></body></html> --533b042f_327b23c6_a8c6--

1 0

Re: (ITS#7829) MDB mdb_cursor_del causes records to be skipped
by h.b.furuseth＠usit.uio.no 01 Apr '14

01 Apr '14

On Fri, 2014-03-28 at 04:58 +0000, armon.dadgar(a)gmail.com wrote: > I have a gist demonstrating this: https://gist.github.com/armon/9825666 Some notes about this code: // LMDB will return EINVAL(22) for the GET_CURRENT op if // there is no further keys. We treat this as no more // keys being found. if num, ok := err.(mdb.Errno); ok && num == 22 { println("errno 22") err = mdb.NotFound } The value of EINVAL is OS-dependent, it need not be 22. EINVAL means you did something wrong, it's a bad idea to assume it means any particular wrong thing. For one thing, mdb might not keep catching that error. I'd follow up with a test check that there are indeed no more keys. That said, mdb_cursor_del() followed by MDB_GET_CURRENT seems to me a sensible thing to want to do. So I think MDB_GET_CURRENT should return MDB_NOTFOUND here. And maybe also after cursor_next() returned MDB_NOTFOUND, and on an empty DB. OTOH maybe cursors would need to keep more state to tell this from user errors which should get EINVAL.

1 0

Re: (ITS#7829) MDB mdb_cursor_del causes records to be skipped
by hyc＠symas.com 31 Mar '14

31 Mar '14

Hallvard Breien Furuseth wrote: > Sorry, forgot the crash info. Thanks, confirmed. In a nested rebalance, doing a page merge with the neighbor on the left was discarding the rebalanced state. Fixed now in mdb.master > > mdb.c:7419: Assertion 'NUMKEYS(mc->mc_pg[ptop]) > 1' failed in mdb_rebalance() > > (gdb) p *mc->mc_pg[ptop] > $1 = { > mp_p = {p_pgno = 24, p_next = 0x18}, mp_pad = 0, mp_flags = 17, > mp_pb = {pb = {pb_lower = 18, pb_upper = 1016}, pb_pages = 66584594}, > mp_ptrs = {1016} > } > (gdb) info locals > node = 0x0 > rc = -268443168 > ptop = 0 > minkeys = 1 > mn = { > mc_next = 0x7ffff5ce0010, mc_backup = 0x7fffe41013a0, mc_xcursor = 0x0, > mc_txn = 0x7fffe42c9700, mc_dbi = 6, mc_db = 0x7fffe42c9890, > mc_dbx = 0x7fffe42c3fb0, mc_dbflag = 0x7fffe42c3fb0 "\002", > mc_snum = 2, mc_top = 1, mc_flags = 65, > mc_pg = {0x7fffe4102840, 0x7fffe8109670, 0x2efffe300, 0x7fffefffe0c0, 0x7fffefffe0a0, 0x7fffefffe2c0, > 0x7fffefffe2c0, 0x53e7cd, 0x7fffefffe1c0, 0x7fffe40019f0, 0x7fffe41013a0, 0x7fffefffe2c0, 0x30c3669909, > 0xfbad8001, 0x7fffefffe2c0, 0x7fffefffe2c0, 0x7fffefffe2c0, 0x7fffefffe130, 0x7fffefffe2d0, 0x7fffefffe180, > 0x49c7ca, 0x7fffefffe140, 0x7fffefffe1dc, 0x1100000000, 0x0, 0x7fffefffe2d0, 0x7fffe4101528, 0x7fffefffe180, 0x1, > 0x7fffe81099d4, 0x7fffefffe260, 0x100000008}, > mc_ki = {5416, 58384, 32767, 0, 39380, 59408, 32767, 0, 39364, 59408, 32767, 0, 39400, 59408, 32767, 0, 39332, > 59408, 32767, 0, 68, 0, 0, 0, 15369, 50024, 48, 0, 57792, 61439, 32767, 0} > } > oldki = 0 > __FUNCTION__ = "mdb_rebalance" > (gdb) p *mc > $2 = { > mc_next = 0x0, mc_backup = 0x0, mc_xcursor = 0x7fffe4101528, > mc_txn = 0x7fffe42c9700, mc_dbi = 6, mc_db = 0x7fffe42c9890, > mc_dbx = 0x7fffe42c3fb0, mc_dbflag = 0x7fffe42cb3e6 "\t\n\n", > mc_snum = 2, mc_top = 1, mc_flags = 65, > mc_pg = {0x7fffe4102840, 0x7fffe8109670, 0x0, 0x40, 0x44, 0x0, 0x6a206e616d726568, 0x6f65703d756f2c72, > 0x653d63642c656c70, 0x642c656c706d6178, 0x302e006d6f633d63, 0x30235a3632353631, 0x2d1, 0x7fffe4000338, 0x81, > 0x7fffe4102c40, 0x7fffe42c7860, 0x20, 0x64, 0x0, 0x4, 0x1a, 0x19, 0x10, 0xe, 0xd, 0xb, 0xa, 0x9, 0x140, 0x84, > 0x0}, > mc_ki = {0, 5, 0, 0, 22160, 63214, 32767, 0, 32769, 0, 0, 0, 64592, 70, 0, 0, 22160, 63214, 32767, 0, 32775, 0, 0, > 0, 63424, 70, 0, 0, 22160, 63214, 32767, 0} > } > > Backtrace: > #2 mdb_assert_fail () > #3 mdb_rebalance (mc=0x7fffe41013a0) at mdb.c:7419 > #4 mdb_cursor_del0 (mc=0x7fffe41013a0) at mdb.c:7496 > #5 mdb_cursor_del (mc=0x7fffe41013a0, flags=0) at mdb.c:6360 > #6 mdb_idl_delete_keys (be, cursor=0x7fffe41013a0, keys, id=7) at idl.c:608 > #7 indexer (op=0x7fffe4000950, txn, ai, ad=0x838180, atname=0x837fc8, vals=0x7fffe40019f0, id=7, opid=2, mask=1814) at index.c:258 > #8 index_at_values (op=0x7fffe4000950, txn=0x7fffe42c9700, ad, type=0x837f60, tags=0x8381a0, vals=0x7fffe40019f0, id=7, opid=2) at index.c:337 > #9 mdb_index_values (op, txn, desc, vals, id, opid) at index.c:386 > #10 mdb_index_entry (op=0x7fffe4000950, txn=0x7fffe42c9700, opid=2, e=0x7fffe40017d0) at index.c:558 > #11 mdb_delete (op=0x7fffe4000950, rs=0x7fffefffe910) at delete.c:347 > #12 overlay_op_walk (op=0x7fffe4000950, rs=0x7fffefffe910, which=op_delete, oi=0x7fffe81036a0, on=0x0) at backover.c:671 > #13 over_op_func (op=0x7fffe4000950, rs, which) at backover.c:723 > #14 fe_op_delete (op=0x7fffe4000950, rs=0x7fffefffe910) at delete.c:174 > #15 do_delete (op=0x7fffe4000950, rs=0x7fffefffe910) at delete.c:95 > #16 connection_operation (ctx=0x7fffefffea70, arg_v=0x7fffe4000950) at connection.c:1155 > #17 connection_read_thread (ctx=0x7fffefffea70, argv) at connection.c:1291 > #18 ldap_int_thread_pool_wrapper (xpool=0x83b3b0) at tpool.c:688 > > Test output: > Running ldapadd to build slapd config database... > Running ldapadd to build slapd database... > Search the entire database... > Running ldapmodify to add a member... > Re-search the entire database... > Running ldapmodify to rename a member... > Re-search the entire database... > Running ldapmodify to rename a group... > Re-search the entire database... > Running ldapmodify to add self... > Re-search the entire database... > Running ldapdelete to remove a member... > Re-search the entire database... > Running ldapdelete to remove a group... > Re-search the entire database... > Adding groups with MAY member type schemas... > > Log ends with: > 533898e1 => index_entry_del( 7, "cn=Jessica Rabbit,ou=People,dc=example,dc=com" ) > 533898e1 mdb_idl_delete_keys: 7 [860433ad] > 533898e1 mdb_idl_delete_keys: 7 [00000000] > 533898e1 mdb_idl_delete_keys: 7 [aaacba45] > 533898e1 mdb_idl_delete_keys: 7 [e10d2617] > -- -- 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#7829) MDB mdb_cursor_del causes records to be skipped
by h.b.furuseth＠usit.uio.no 30 Mar '14

30 Mar '14

Sorry, forgot the crash info. mdb.c:7419: Assertion 'NUMKEYS(mc->mc_pg[ptop]) > 1' failed in mdb_rebalance() (gdb) p *mc->mc_pg[ptop] $1 = { mp_p = {p_pgno = 24, p_next = 0x18}, mp_pad = 0, mp_flags = 17, mp_pb = {pb = {pb_lower = 18, pb_upper = 1016}, pb_pages = 66584594}, mp_ptrs = {1016} } (gdb) info locals node = 0x0 rc = -268443168 ptop = 0 minkeys = 1 mn = { mc_next = 0x7ffff5ce0010, mc_backup = 0x7fffe41013a0, mc_xcursor = 0x0, mc_txn = 0x7fffe42c9700, mc_dbi = 6, mc_db = 0x7fffe42c9890, mc_dbx = 0x7fffe42c3fb0, mc_dbflag = 0x7fffe42c3fb0 "\002", mc_snum = 2, mc_top = 1, mc_flags = 65, mc_pg = {0x7fffe4102840, 0x7fffe8109670, 0x2efffe300, 0x7fffefffe0c0, 0x7fffefffe0a0, 0x7fffefffe2c0, 0x7fffefffe2c0, 0x53e7cd, 0x7fffefffe1c0, 0x7fffe40019f0, 0x7fffe41013a0, 0x7fffefffe2c0, 0x30c3669909, 0xfbad8001, 0x7fffefffe2c0, 0x7fffefffe2c0, 0x7fffefffe2c0, 0x7fffefffe130, 0x7fffefffe2d0, 0x7fffefffe180, 0x49c7ca, 0x7fffefffe140, 0x7fffefffe1dc, 0x1100000000, 0x0, 0x7fffefffe2d0, 0x7fffe4101528, 0x7fffefffe180, 0x1, 0x7fffe81099d4, 0x7fffefffe260, 0x100000008}, mc_ki = {5416, 58384, 32767, 0, 39380, 59408, 32767, 0, 39364, 59408, 32767, 0, 39400, 59408, 32767, 0, 39332, 59408, 32767, 0, 68, 0, 0, 0, 15369, 50024, 48, 0, 57792, 61439, 32767, 0} } oldki = 0 __FUNCTION__ = "mdb_rebalance" (gdb) p *mc $2 = { mc_next = 0x0, mc_backup = 0x0, mc_xcursor = 0x7fffe4101528, mc_txn = 0x7fffe42c9700, mc_dbi = 6, mc_db = 0x7fffe42c9890, mc_dbx = 0x7fffe42c3fb0, mc_dbflag = 0x7fffe42cb3e6 "\t\n\n", mc_snum = 2, mc_top = 1, mc_flags = 65, mc_pg = {0x7fffe4102840, 0x7fffe8109670, 0x0, 0x40, 0x44, 0x0, 0x6a206e616d726568, 0x6f65703d756f2c72, 0x653d63642c656c70, 0x642c656c706d6178, 0x302e006d6f633d63, 0x30235a3632353631, 0x2d1, 0x7fffe4000338, 0x81, 0x7fffe4102c40, 0x7fffe42c7860, 0x20, 0x64, 0x0, 0x4, 0x1a, 0x19, 0x10, 0xe, 0xd, 0xb, 0xa, 0x9, 0x140, 0x84, 0x0}, mc_ki = {0, 5, 0, 0, 22160, 63214, 32767, 0, 32769, 0, 0, 0, 64592, 70, 0, 0, 22160, 63214, 32767, 0, 32775, 0, 0, 0, 63424, 70, 0, 0, 22160, 63214, 32767, 0} } Backtrace: #2 mdb_assert_fail () #3 mdb_rebalance (mc=0x7fffe41013a0) at mdb.c:7419 #4 mdb_cursor_del0 (mc=0x7fffe41013a0) at mdb.c:7496 #5 mdb_cursor_del (mc=0x7fffe41013a0, flags=0) at mdb.c:6360 #6 mdb_idl_delete_keys (be, cursor=0x7fffe41013a0, keys, id=7) at idl.c:608 #7 indexer (op=0x7fffe4000950, txn, ai, ad=0x838180, atname=0x837fc8, vals=0x7fffe40019f0, id=7, opid=2, mask=1814) at index.c:258 #8 index_at_values (op=0x7fffe4000950, txn=0x7fffe42c9700, ad, type=0x837f60, tags=0x8381a0, vals=0x7fffe40019f0, id=7, opid=2) at index.c:337 #9 mdb_index_values (op, txn, desc, vals, id, opid) at index.c:386 #10 mdb_index_entry (op=0x7fffe4000950, txn=0x7fffe42c9700, opid=2, e=0x7fffe40017d0) at index.c:558 #11 mdb_delete (op=0x7fffe4000950, rs=0x7fffefffe910) at delete.c:347 #12 overlay_op_walk (op=0x7fffe4000950, rs=0x7fffefffe910, which=op_delete, oi=0x7fffe81036a0, on=0x0) at backover.c:671 #13 over_op_func (op=0x7fffe4000950, rs, which) at backover.c:723 #14 fe_op_delete (op=0x7fffe4000950, rs=0x7fffefffe910) at delete.c:174 #15 do_delete (op=0x7fffe4000950, rs=0x7fffefffe910) at delete.c:95 #16 connection_operation (ctx=0x7fffefffea70, arg_v=0x7fffe4000950) at connection.c:1155 #17 connection_read_thread (ctx=0x7fffefffea70, argv) at connection.c:1291 #18 ldap_int_thread_pool_wrapper (xpool=0x83b3b0) at tpool.c:688 Test output: Running ldapadd to build slapd config database... Running ldapadd to build slapd database... Search the entire database... Running ldapmodify to add a member... Re-search the entire database... Running ldapmodify to rename a member... Re-search the entire database... Running ldapmodify to rename a group... Re-search the entire database... Running ldapmodify to add self... Re-search the entire database... Running ldapdelete to remove a member... Re-search the entire database... Running ldapdelete to remove a group... Re-search the entire database... Adding groups with MAY member type schemas... Log ends with: 533898e1 => index_entry_del( 7, "cn=Jessica Rabbit,ou=People,dc=example,dc=com" ) 533898e1 mdb_idl_delete_keys: 7 [860433ad] 533898e1 mdb_idl_delete_keys: 7 [00000000] 533898e1 mdb_idl_delete_keys: 7 [aaacba45] 533898e1 mdb_idl_delete_keys: 7 [e10d2617] -- Hallvard

1 0

Re: (ITS#7829) MDB mdb_cursor_del causes records to be skipped
by h.b.furuseth＠usit.uio.no 30 Mar '14

30 Mar '14

hyc(a)symas.com writes: > Thanks for the report. Fixed now in mdb.master. That fix breaks test052-memberof with pagesize 1024. Unrealistic, but it's not a MAXKEYSIZE issue so it should not have made a difference. Tested with RE24 9e22d8f2cd5ed10cd1dd22acbd729a49e5ecc1ab + mdb.master~ or mdb.master ac3acc121855e4297d597a4d71e9863e1e1e2450 + this patch: diff --git a/libraries/liblmdb/lmdb.h b/libraries/liblmdb/lmdb.h index 2ebd43f..3f4a167 100644 --- a/libraries/liblmdb/lmdb.h +++ b/libraries/liblmdb/lmdb.h @@ -411,4 +411,4 @@ typedef enum MDB_cursor_op { /** Too big key/data, key is empty, or wrong DUPFIXED size */ -#define MDB_BAD_VALSIZE (-30781) -#define MDB_LAST_ERRCODE MDB_BAD_VALSIZE +#define MDB_BAD_VALSIZE (abort(),-30781) /* we don't hit MDB_MAXKEYSIZE */ +#define MDB_LAST_ERRCODE (-30781) /** @} */ diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 7e29058..ad9bfc6 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -405,3 +405,3 @@ static txnid_t mdb_debug_start; #ifndef MDB_MAXKEYSIZE -#define MDB_MAXKEYSIZE 511 +#define MDB_MAXKEYSIZE 400 /* max-max is 446 for psize=1024 on 64-bit hosts */ #endif @@ -3536,3 +3536,3 @@ mdb_env_open2(MDB_env *env) newenv = 1; - env->me_psize = env->me_os_psize; + env->me_psize = 1024; if (env->me_psize > MAX_PAGESIZE) -- Hallvard

1 0

Re: (ITS#7829) MDB mdb_cursor_del causes records to be skipped
by hyc＠symas.com 28 Mar '14

28 Mar '14

armon.dadgar(a)gmail.com wrote: > Full_Name: Armon Dadgar > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (50.78.97.10) > > > I have an issue where when iterating over data and deleting keys, the cursor > will incorrectly skip rows, and then returns an early NOTFOUND even though more > records still exist. > > I have a gist demonstrating this: https://gist.github.com/armon/9825666 > > I am using small Go wrapper around LMDB, version 0.9.11. > > The expected behavior is to numbers 1..91 printed. However, when I run it, > it gets to 16 and returns no further rows. > > Thanks for the report. Fixed now in mdb.master. -- -- 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#7825) LMDB: misleading error message
by timur.kristof＠gmail.com 28 Mar '14

28 Mar '14

On Fri Mar 28 2014 18:36:11 GMT+0100 (CET), Howard Chu wrote: > timur.kristof(a)gmail.com wrote: > > > Here's a small test case which will demonstrate it: > > http://pastebin.com/hHwD1srf > > As an aside, this is some pretty horrible code. Why are you using > MDB_GET_CURRENT after all of your cursor_get calls? It truly is horrendous. I wrote it in an attempt to (roughly) reproduce what one of my examples did in javascript. Then when I discovered what the issue really was, I forgot to clean it up before pastebinning. I hope it's still okay as a testcase for this bugreport :) > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- Timur Sent from my Jolla

1 0

Re: (ITS#7825) LMDB: misleading error message
by hyc＠symas.com 28 Mar '14

28 Mar '14

timur.kristof(a)gmail.com wrote: > Here's a small test case which will demonstrate it: > http://pastebin.com/hHwD1srf As an aside, this is some pretty horrible code. Why are you using MDB_GET_CURRENT after all of your cursor_get calls? -- -- 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#7830) MDB Size grown a lot during massive updates and concurrent read access
by antonin.meunier＠cgi.com 28 Mar '14

28 Mar '14

Full_Name: Antonin Meunier Version: 2.4.39 OS: Red Hat 6.5 URL: Submission from: (NULL) (195.6.127.108) Ldap is set to a maximum MDB database size of 80GB. Ldap uses 20GB of effective Size. There are approximately 60 index , 1500000 peoples and 4500000 groups. The LDAP is accessed in read / write by about 20 tomcat. In parallel to this, update treatment (inject ldif) are started performing lots of massive upates (750 000, 500 000 groups). When processing the massives updates, the MDB size increases to the 80max and therefore the treatment plant updates. If I stop all tomcat, the problem no longer occurs. So it seems that the problem comes from locks that are placed on the pages of indexes and data by readers and force to create new pages for changes with conservation of all intermediate pages. After that, the only way to find a "normal" size is to export the ldap , delete it and re-import the backup. The LDAP database is then again 20GB

1 0

Re: (ITS#7828) LMDB crash in mdb_cursor_put(MDB_CURRENT)
by sbn＠tbricks.com 27 Mar '14

27 Mar '14

Works after reverting commit (checked f537429) Thanks!

1 0

(ITS#7829) MDB mdb_cursor_del causes records to be skipped
by armon.dadgar＠gmail.com 27 Mar '14

27 Mar '14

Full_Name: Armon Dadgar Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.78.97.10) I have an issue where when iterating over data and deleting keys, the cursor will incorrectly skip rows, and then returns an early NOTFOUND even though more records still exist. I have a gist demonstrating this: https://gist.github.com/armon/9825666 I am using small Go wrapper around LMDB, version 0.9.11. The expected behavior is to numbers 1..91 printed. However, when I run it, it gets to 16 and returns no further rows.

1 0

Re: (ITS#7828) LMDB crash in mdb_cursor_put(MDB_CURRENT)
by hyc＠symas.com 26 Mar '14

26 Mar '14

h.b.furuseth(a)usit.uio.no wrote: > Doc bug, fixed recently: MDB_CURRENT must not change the data size. Wrong. This is a regression due to ITS#7793. That commit has now been reverted. > Also with DUPSORT the data item must sort in the same place as the > previous one, that needs to be documented too. I'll add this note to the doc. -- -- 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#7826)
by antonin.meunier＠cgi.com 26 Mar '14

26 Mar '14

--_005_F2AD894A2AA6704C8D712D76B50B8320AE7564B5SEEX023groupinf_ Content-Type: multipart/alternative; boundary="_000_F2AD894A2AA6704C8D712D76B50B8320AE7564B5SEEX023groupinf_" --_000_F2AD894A2AA6704C8D712D76B50B8320AE7564B5SEEX023groupinf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpUbyBjb21wbGVtZW50IHRoZSBpbmNpZGVudCwgd2UgaGF2ZSByZXNldCBvdXIgZGlyZWN0 b3J5IChleHBvcnQsIGRlbGV0ZSwgaW1wb3J0KSB0aGUgc2l6ZSBvZiB0aGUgZGlyZWN0b3J5IGlz IHJldHVybmVkIHRvIDIwR0INCkR1cmluZyB0aGUgcGFzc2FnZSBvZiBsZGlmIGFtZW5kaW5nIDc1 MCwwMDAgcGVvcGxlLCB0aGUgc2l6ZSBpcyBhZ2FpbiBpbmNyZWFzZWQgdG8gODBHQiAoYW5kIHNh dHVyYXRpb24pLg0KV2UgY291bGQgZnVydGhlciBpbmNyZWFzZSB0aGUgc2l6ZSBidXQgODBHQiBm b3IgZnVsbCByZWVsIHNpemUgb2YgMjBHQiwgYWxyZWFkeSBzZWVtIHRvIGRvIG11Y2guDQoNClRo ZSBzcGVjaWZpYyBwYXJhbWV0ZXJzIHRvIE1EQiBhcmU6DQojIGVjcml0dXJlIGRpZmbDqXLDqWUN CmRibm9zeW5jIFRSVUUNCiMgZWNyaXR1cmUgdG91cyBsZXMgMTUgbWludXRlcw0KY2hlY2twb2lu dCAwIDE1DQojIFNldCB0byAzMiBHbw0KIyAzMiBHYiBzaG91bGQgYmUgZW5vdWdoLi4uIG5vbiBk b25jIDgwR28NCiNtYXhzaXplIDM0MzU5NzM4MzY4DQptYXhzaXplIDg1ODk5MzQ1OTIwDQojIFBh cmFtZXRyZXMgTURCDQptYXhyZWFkZXJzIDEyNg0KbW9kZSAwNjAwDQojIFNob3VsZCBiZSBtb3Jl IHRoYW4gZW5vdWdoLi4uDQpzZWFyY2hzdGFjayAxNg0KDQpUaGUgbGRpZiBhcHBsaWVzIHRoZSBj aGFuZ2VzIGJlbG93IHRvIDc1MCAwMDAgcGVvcGxlcyA6DQpkbjogdWlkPTk5OTkxMDAwMDAwMDAx MjAwMSxvdT1wZXJzb25uZXMsb3U9Q1JJRixkYz1lbnQsZGM9ZnINCmNoYW5nZXR5cGU6IG1vZGlm eQ0KcmVwbGFjZTogdXNlclBhc3N3b3JkDQp1c2VyUGFzc3dvcmQ6IGF2bnA1emsNCg0KQW5kIHdo ZW4gdGhlIHNhdHVyYXRpb24gYmVjb21lICg4MEdvKSB3ZSBoYXZlIGVycm9yIGxvZyA6DQoyMDE0 LTAzLTI1VDEyOjE3OjQ2LjA0ODg2MCswMTowMCBsZGFwcDAxIHNsYXBkWzM5MjgzXTogY29ubj02 NzgyNCBvcD0wIFJFU1VMVCB0YWc9OTcgZXJyPTAgdGV4dD0NCjIwMTQtMDMtMjVUMTI6MTc6NDYu MDQ5MTUwKzAxOjAwIGxkYXBwMDEgc2xhcGRbMzkyODNdOiBjb25uPTY3ODI0IG9wPTEgTU9EIGRu PSJ1aWQ9MjAyNyxvdT1wZXJzb25uZXMsb3U9Q1JJRixkYz1lbnQsZGM9ZnIiDQoyMDE0LTAzLTI1 VDEyOjE3OjQ2LjA0OTE3NSswMTowMCBsZGFwcDAxIHNsYXBkWzM5MjgzXTogY29ubj02NzgyNCBv cD0xIE1PRCBhdHRyPXVzZXJQYXNzd29yZA0KMjAxNC0wMy0yNVQxMjoxNzo0Ni4wNDkzNDMrMDE6 MDAgbGRhcHAwMSBzbGFwZFszOTI4M106IHNsYXBfcXVldWVfY3NuOiBxdWVpbmcgMHg3ZmUyOTY3 ZmEyNzAgMjAxNDAzMjUxMTE3NDYuMDQ5MjcwWiMwMDAwMDAjMDAyIzAwMDAwMA0KMjAxNC0wMy0y NVQxMjoxNzo0Ni4wNDk1MzErMDE6MDAgbGRhcHAwMSBzbGFwZFszOTI4M106ID0+IG1kYl9pZGxf ZGVsZXRlX2tleTogY19kZWwgaWQgZmFpbGVkOiBNREJfTUFQX0ZVTEw6IEVudmlyb25tZW50IG1h cHNpemUgbGltaXQgcmVhY2hlZCAoLTMwNzkyKQ0KMjAxNC0wMy0yNVQxMjoxNzo0Ni4wNDk1NTgr MDE6MDAgbGRhcHAwMSBzbGFwZFszOTI4M106IGNvbm49Njc4MjQgb3A9MTogYXR0cmlidXRlICJl bnRyeUNTTiIgaW5kZXggZGVsZXRlIGZhaWx1cmUNCjIwMTQtMDMtMjVUMTI6MTc6NDYuMDQ5NTY1 KzAxOjAwIGxkYXBwMDEgc2xhcGRbMzkyODNdOiBjb25uPTY3ODI0IG9wPTEgUkVTVUxUIHRhZz0x MDMgZXJyPTgwIHRleHQ9DQoyMDE0LTAzLTI1VDEyOjE3OjQ2LjA0OTU3MiswMTowMCBsZGFwcDAx IHNsYXBkWzM5MjgzXTogc2xhcF9ncmFkdWF0ZV9jb21taXRfY3NuOiByZW1vdmluZyAweDdmZTIy NDEwMmY2MCAyMDE0MDMyNTExMTc0Ni4wNDkyNzBaIzAwMDAwMCMwMDIjMDAwMDAwDQoyMDE0LTAz LTI1VDEyOjE3OjQ2LjA0OTk0MiswMTowMCBsZGFwcDAxIHNsYXBkWzM5MjgzXTogY29ubj02Nzgy NCBvcD0yIFVOQklORA0KMjAxNC0wMy0yNVQxMjoxNzo0Ni4wNDk5NjMrMDE6MDAgbGRhcHAwMSBz bGFwZFszOTI4M106IGNvbm49Njc4MjQgZmQ9MTE4IGNsb3NlZA0KDQoNCg0KQW50b25pbiBNZXVu aWVyIHwgQ29uc3VsdGFudCBzb2x1dGlvbnMgc8Opbmlvcg0KT0JQIC0gTkJNIHwgQ0dJDQpJbW1l dWJsZSBBbmRyb23DqGRlLCA2IHJ1ZSBkZXMgY29tw6h0ZXMsIENTIDEwMDI2LCAzMzE4NyBMZSBI YWlsbGFuIENlZGV4IHwgRnJhbmNlDQpUIDogKzMzIDUgNTcgNzggNTkgNTQgfCBNIDogKzMzIDYg ODUgMzEgNjEgNzYNCmFudG9uaW4ubWV1bmllckBjZ2kuY29tPG1haWx0bzphbnRvbmluLm1ldW5p ZXJAY2dpLmNvbT4gfCB3d3cuY2dpLmNvbTxodHRwOi8vd3d3LmNnaS5jb20vPiB8IGdyYW5kYW5n bGUuZnIubG9naWNhLmNvbTxodHRwOi8vZ3JhbmRhbmdsZS5mci5sb2dpY2EuY29tLz4NCg0KQ0dJ IEZyYW5jZSBTQVMNCkNhcGl0YWwgOiAxMiA5MTMgOTMzIGV1cm9zIHwgUkNTIE5hbnRlcnJlIDcw MiAwNDIgNzU1DQpTacOoZ2Ugc29jaWFsIDogSW1tZXVibGUgQ0IxNiB8IDE3LCBwbGFjZSBkZXMg UmVmbGV0cyB8IDkyNDAwIENvdXJiZXZvaWUgfCBGcmFuY2UNCg0KW2NnaS1sb2dvMjAxMy1lbWFp bC00NXgyNS5wbmddDQoNCltlbnZpcm9ubWVudC1sb2dvLWVtYWlsLWZyLmdpZl0NCg0KQVZJUyBE RSBDT05GSURFTlRJQUxJVMOJIDogQ2UgbWVzc2FnZSBwZXV0IGNvbnRlbmlyIGRlcyByZW5zZWln bmVtZW50cyBjb25maWRlbnRpZWxzIGFwcGFydGVuYW50IGV4Y2x1c2l2ZW1lbnQgYXUgR3JvdXBl IENHSSBpbmMuIG91IMOgIHNlcyBmaWxpYWxlcy4gU2kgdm91cyBuJ8OqdGVzIHBhcyBsZSBkZXN0 aW5hdGFpcmUgaW5kaXF1w6kgb3UgcHLDqXZ1IGRhbnMgY2UgbWVzc2FnZSAob3UgcmVzcG9uc2Fi bGUgZGUgbGl2cmVyIGNlIG1lc3NhZ2Ugw6AgbGEgcGVyc29ubmUgaW5kaXF1w6llIG91IHByw6l2 dWUpIG91IHNpIHZvdXMgcGVuc2V6IHF1ZSBjZSBtZXNzYWdlIHZvdXMgYSDDqXTDqSBhZHJlc3PD qSBwYXIgZXJyZXVyLCB2b3VzIG5lIHBvdXZleiBwYXMgdXRpbGlzZXIgb3UgcmVwcm9kdWlyZSBj ZSBtZXNzYWdlLCBuaSBsZSBsaXZyZXIgw6AgcXVlbHF1J3VuIGQnYXV0cmUuIERhbnMgY2UgY2Fz LCB2b3VzIGRldmV6IGxlIGTDqXRydWlyZSBldCB2b3VzIMOqdGVzIHByacOpIGQnYXZlcnRpciBs J2V4cMOpZGl0ZXVyIGVuIHLDqXBvbmRhbnQgYXUgY291cnJpZWwu4oCLDQoNCg0K --_000_F2AD894A2AA6704C8D712D76B50B8320AE7564B5SEEX023groupinf_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VmVyZGFuYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRl IGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMg Q2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRl IGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uaHBz DQoJe21zby1zdHlsZS1uYW1lOmhwczt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMjA1MCIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJG UiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBjbGFzcz0iaHBzIj48c3BhbiBsYW5nPSJFTiI+VG8gY29tcGxlbWVudCB0 aGUgaW5jaWRlbnQsIHdlIGhhdmUgcmVzZXQ8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOIj4N CjxzcGFuIGNsYXNzPSJocHMiPm91ciBkaXJlY3Rvcnk8L3NwYW4+IDxzcGFuIGNsYXNzPSJocHMi PihleHBvcnQ8L3NwYW4+LCBkZWxldGUsIDxzcGFuIGNsYXNzPSJocHMiPg0KaW1wb3J0KTwvc3Bh bj4gPHNwYW4gY2xhc3M9ImhwcyI+dGhlIHNpemUgb2YgdGhlPC9zcGFuPiA8c3BhbiBjbGFzcz0i aHBzIj5kaXJlY3RvcnkgaXM8L3NwYW4+DQo8c3BhbiBjbGFzcz0iaHBzIj5yZXR1cm5lZDwvc3Bh bj4gPHNwYW4gY2xhc3M9ImhwcyI+dG8gMjBHQjwvc3Bhbj4gPGJyPg0KPHNwYW4gY2xhc3M9Imhw cyI+RHVyaW5nPC9zcGFuPiA8c3BhbiBjbGFzcz0iaHBzIj50aGUgcGFzc2FnZSBvZjwvc3Bhbj4g PHNwYW4gY2xhc3M9ImhwcyI+DQpsZGlmPC9zcGFuPiA8c3BhbiBjbGFzcz0iaHBzIj5hbWVuZGlu Zzwvc3Bhbj4gPHNwYW4gY2xhc3M9ImhwcyI+NzUwLDAwMDwvc3Bhbj4gPHNwYW4gY2xhc3M9Imhw cyI+DQpwZW9wbGU8L3NwYW4+LCB0aGUgc2l6ZSBpcyA8c3BhbiBjbGFzcz0iaHBzIj5hZ2Fpbjwv c3Bhbj4gPHNwYW4gY2xhc3M9ImhwcyI+aW5jcmVhc2VkIHRvPC9zcGFuPg0KPHNwYW4gY2xhc3M9 ImhwcyI+ODBHQjwvc3Bhbj4gPHNwYW4gY2xhc3M9ImhwcyI+KGFuZDwvc3Bhbj4gPHNwYW4gY2xh c3M9ImhwcyI+c2F0dXJhdGlvbikuPC9zcGFuPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImhwcyI+PHNwYW4gbGFuZz0iRU4iPldlIGNv dWxkPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTiI+DQo8c3BhbiBjbGFzcz0iaHBzIj5mdXJ0 aGVyIGluY3JlYXNlPC9zcGFuPiA8c3BhbiBjbGFzcz0iaHBzIj50aGUgc2l6ZTwvc3Bhbj4gPHNw YW4gY2xhc3M9ImhwcyI+DQpidXQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJocHMiPjgwR0I8L3NwYW4+ IDxzcGFuIGNsYXNzPSJocHMiPmZvcjwvc3Bhbj4gPHNwYW4gY2xhc3M9ImhwcyI+DQpmdWxsIHJl ZWwgc2l6ZTwvc3Bhbj4gb2YgPHNwYW4gY2xhc3M9ImhwcyI+MjBHQjwvc3Bhbj4sIDxzcGFuIGNs YXNzPSJocHMiPmFscmVhZHkgc2VlbTwvc3Bhbj4NCjxzcGFuIGNsYXNzPSJocHMiPnRvIGRvIG11 Y2g8L3NwYW4+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOIj48YnI+DQo8c3BhbiBjbGFzcz0iaHBzIj5UaGU8L3NwYW4+IDxzcGFuIGNs YXNzPSJocHMiPnNwZWNpZmljPC9zcGFuPiA8c3BhbiBjbGFzcz0iaHBzIj4NCnBhcmFtZXRlcnM8 L3NwYW4+IDxzcGFuIGNsYXNzPSJocHMiPnRvPC9zcGFuPiA8c3BhbiBjbGFzcz0iaHBzIj5NREI8 L3NwYW4+IDxzcGFuIGNsYXNzPSJocHMiPg0KYXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4jIGVjcml0dXJlIGRpZmbDqXLDqWU8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRibm9zeW5jIFRSVUU8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiMgZWNyaXR1cmUgdG91cyBsZXMgMTUgbWludXRlczxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y2hlY2twb2ludCAwIDE1PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4jIFNldCB0byAzMiBHbzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+IyAzMiBHYiBzaG91bGQgYmUgZW5vdWdoLi4uIG5vbiBk b25jIDgwR288bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiNtYXhzaXplIDM0 MzU5NzM4MzY4PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5tYXhzaXplIDg1 ODk5MzQ1OTIwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4jIFBhcmFtZXRy ZXMgTURCPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5tYXhyZWFkZXJzIDEy NjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bW9kZSAwNjAwPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4jIFNob3VsZCBiZSBtb3JlIHRoYW4gZW5vdWdo Li4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zZWFyY2hzdGFjayAxNjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iaHBzIj48c3BhbiBsYW5nPSJFTiI+ VGhlPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTiI+DQo8c3BhbiBjbGFzcz0iaHBzIj5sZGlm PC9zcGFuPiA8c3BhbiBjbGFzcz0iaHBzIj5hcHBsaWVzIHRoZSBjaGFuZ2VzPC9zcGFuPiA8c3Bh biBjbGFzcz0iaHBzIj4NCmJlbG93PC9zcGFuPiB0byA8c3BhbiBjbGFzcz0iaHBzIj43NTA8L3Nw YW4+Jm5ic3A7PHNwYW4gY2xhc3M9ImhwcyI+MDAwPC9zcGFuPiBwZW9wbGVzIDoNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIj5kbjog dWlkPTk5OTkxMDAwMDAwMDAxMjAwMSxvdT1wZXJzb25uZXMsb3U9Q1JJRixkYz1lbnQsZGM9ZnI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF TiI+Y2hhbmdldHlwZTogbW9kaWZ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4iPnJlcGxhY2U6IHVzZXJQYXNzd29yZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIj51c2VyUGFz c3dvcmQ6IGF2bnA1ems8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4iPkFuZCB3aGVuIHRoZSBzYXR1cmF0aW9uIGJlY29t ZSAoODBHbykgd2UgaGF2ZSBlcnJvciBsb2cgOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+MjAxNC0wMy0yNVQxMjoxNzo0Ni4wNDg4NjAmIzQzOzAxOjAwIGxk YXBwMDEgc2xhcGRbMzkyODNdOiBjb25uPTY3ODI0IG9wPTAgUkVTVUxUIHRhZz05NyBlcnI9MCB0 ZXh0PQ0KPGJyPg0KMjAxNC0wMy0yNVQxMjoxNzo0Ni4wNDkxNTAmIzQzOzAxOjAwIGxkYXBwMDEg c2xhcGRbMzkyODNdOiBjb25uPTY3ODI0IG9wPTEgTU9EIGRuPSZxdW90O3VpZD0yMDI3LG91PXBl cnNvbm5lcyxvdT1DUklGLGRjPWVudCxkYz1mciZxdW90Ow0KPGJyPg0KMjAxNC0wMy0yNVQxMjox Nzo0Ni4wNDkxNzUmIzQzOzAxOjAwIGxkYXBwMDEgc2xhcGRbMzkyODNdOiBjb25uPTY3ODI0IG9w PTEgTU9EIGF0dHI9dXNlclBhc3N3b3JkDQo8YnI+DQoyMDE0LTAzLTI1VDEyOjE3OjQ2LjA0OTM0 MyYjNDM7MDE6MDAgbGRhcHAwMSBzbGFwZFszOTI4M106IHNsYXBfcXVldWVfY3NuOiBxdWVpbmcg MHg3ZmUyOTY3ZmEyNzAgMjAxNDAzMjUxMTE3NDYuMDQ5MjcwWiMwMDAwMDAjMDAyIzAwMDAwMA0K PGJyPg0KMjAxNC0wMy0yNVQxMjoxNzo0Ni4wNDk1MzEmIzQzOzAxOjAwIGxkYXBwMDEgc2xhcGRb MzkyODNdOiA9Jmd0OyBtZGJfaWRsX2RlbGV0ZV9rZXk6IGNfZGVsIGlkIGZhaWxlZDogTURCX01B UF9GVUxMOiBFbnZpcm9ubWVudCBtYXBzaXplIGxpbWl0IHJlYWNoZWQgKC0zMDc5MikNCjxicj4N CjIwMTQtMDMtMjVUMTI6MTc6NDYuMDQ5NTU4JiM0MzswMTowMCBsZGFwcDAxIHNsYXBkWzM5Mjgz XTogY29ubj02NzgyNCBvcD0xOiBhdHRyaWJ1dGUgJnF1b3Q7ZW50cnlDU04mcXVvdDsgaW5kZXgg ZGVsZXRlIGZhaWx1cmUNCjxicj4NCjIwMTQtMDMtMjVUMTI6MTc6NDYuMDQ5NTY1JiM0MzswMTow MCBsZGFwcDAxIHNsYXBkWzM5MjgzXTogY29ubj02NzgyNCBvcD0xIFJFU1VMVCB0YWc9MTAzIGVy cj04MCB0ZXh0PQ0KPGJyPg0KMjAxNC0wMy0yNVQxMjoxNzo0Ni4wNDk1NzImIzQzOzAxOjAwIGxk YXBwMDEgc2xhcGRbMzkyODNdOiBzbGFwX2dyYWR1YXRlX2NvbW1pdF9jc246IHJlbW92aW5nIDB4 N2ZlMjI0MTAyZjYwIDIwMTQwMzI1MTExNzQ2LjA0OTI3MFojMDAwMDAwIzAwMiMwMDAwMDANCjxi cj4NCjIwMTQtMDMtMjVUMTI6MTc6NDYuMDQ5OTQyJiM0MzswMTowMCBsZGFwcDAxIHNsYXBkWzM5 MjgzXTogY29ubj02NzgyNCBvcD0yIFVOQklORCA8YnI+DQoyMDE0LTAzLTI1VDEyOjE3OjQ2LjA0 OTk2MyYjNDM7MDE6MDAgbGRhcHAwMSBzbGFwZFszOTI4M106IGNvbm49Njc4MjQgZmQ9MTE4IGNs b3NlZDxzcGFuIGxhbmc9IkVOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+QW50b25pbiBNZXVuaWVyPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+fCA8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zdWx0YW50IHNvbHV0aW9ucyBzw6luaW9y PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PQlAgLSBOQk0g fCBDR0k8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkltbWV1YmxlIEFuZHJvbcOoZGUsIDYgcnVlIGRlcyBjb23DqHRl cywgQ1MgMTAwMjYsIDMzMTg3IExlIEhhaWxsYW4gQ2VkZXggfCBGcmFuY2U8YnI+DQpUIDombmJz cDsmIzQzOzMzIDUgNTcgNzggNTkgNTQgfCBNIDogJiM0MzszMyA2IDg1IDMxIDYxIDc2PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNBMjk3OTEiPjxicj4NCjxhIGhyZWY9 Im1haWx0bzphbnRvbmluLm1ldW5pZXJAY2dpLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUi PmFudG9uaW4ubWV1bmllckBjZ2kuY29tPC9zcGFuPjwvYT4gfA0KPHU+PGEgaHJlZj0iaHR0cDov L3d3dy5jZ2kuY29tLyI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPnd3dy5jZ2kuY29tPC9zcGFu PjwvYT48L3U+IHwNCjx1PjxhIGhyZWY9Imh0dHA6Ly9ncmFuZGFuZ2xlLmZyLmxvZ2ljYS5jb20v Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+Z3JhbmRhbmdsZS5mci5sb2dpY2EuY29tPC9zcGFu PjwvYT48L3U+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibHVl Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkNHSSBGcmFuY2UgU0FTPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DYXBpdGFsJm5ic3A7OiAxMiZuYnNwOzkxMyZu YnNwOzkzMyBldXJvcw0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPnw8L3NwYW4+IFJDUyBO YW50ZXJyZSA3MDImbmJzcDswNDImbmJzcDs3NTU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNpw6hnZSBzb2NpYWwg OiBJbW1ldWJsZSBDQjE2DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+fDwvc3Bhbj4gMTcs IHBsYWNlIGRlcyBSZWZsZXRzIDxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4NCnw8L3NwYW4+ IDkyNDAwIENvdXJiZXZvaWUgfCBGcmFuY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIzNiIgaGVpZ2h0PSIyMCIgaWQ9IkltYWdl X3gwMDIwXzEiIHNyYz0iY2lkOmltYWdlMDA1LnBuZ0AwMUNGNDhEOS5CNDZERURDMCIgYWx0PSJj Z2ktbG9nbzIwMTMtZW1haWwtNDV4MjUucG5nIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtjb2xvcjpibGFjayI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIyNjQiIGhlaWdodD0iMTYi IGlkPSJJbWFnZV94MDAyMF8zIiBzcmM9ImNpZDppbWFnZTAwNi5wbmdAMDFDRjQ4RDkuQjQ2REVE QzAiIGFsdD0iZW52aXJvbm1lbnQtbG9nby1lbWFpbC1mci5naWYiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlItQ0EiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+QVZJUyBERSBDT05GSURFTlRJQUxJVMOJJm5ic3A7OiBDZSBtZXNzYWdlIHBldXQg Y29udGVuaXIgZGVzIHJlbnNlaWduZW1lbnRzIGNvbmZpZGVudGllbHMgYXBwYXJ0ZW5hbnQgZXhj bHVzaXZlbWVudCBhdSBHcm91cGUgQ0dJIGluYy4gb3Ugw6Agc2VzIGZpbGlhbGVzLg0KIFNpIHZv dXMgbifDqnRlcyBwYXMgbGUgZGVzdGluYXRhaXJlIGluZGlxdcOpIG91IHByw6l2dSBkYW5zIGNl IG1lc3NhZ2UgKG91IHJlc3BvbnNhYmxlIGRlIGxpdnJlciBjZSBtZXNzYWdlIMOgIGxhIHBlcnNv bm5lIGluZGlxdcOpZSBvdSBwcsOpdnVlKSBvdSBzaSB2b3VzIHBlbnNleiBxdWUgY2UgbWVzc2Fn ZSB2b3VzIGEgw6l0w6kgYWRyZXNzw6kgcGFyIGVycmV1ciwgdm91cyBuZSBwb3V2ZXogcGFzIHV0 aWxpc2VyIG91IHJlcHJvZHVpcmUgY2UgbWVzc2FnZSwNCiBuaSBsZSBsaXZyZXIgw6AgcXVlbHF1 J3VuIGQnYXV0cmUuIERhbnMgY2UgY2FzLCB2b3VzIGRldmV6IGxlIGTDqXRydWlyZSBldCB2b3Vz IMOqdGVzIHByacOpIGQnYXZlcnRpciBsJ2V4cMOpZGl0ZXVyIGVuIHLDqXBvbmRhbnQgYXUgY291 cnJpZWwuPC9zcGFuPjxzcGFuIGxhbmc9IkZSLUNBIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbWJyaWEgTWF0aCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjpibGFjayI+4oCLPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F2AD894A2AA6704C8D712D76B50B8320AE7564B5SEEX023groupinf_-- --_005_F2AD894A2AA6704C8D712D76B50B8320AE7564B5SEEX023groupinf_ Content-Type: image/png; name="image005.png" Content-Description: image005.png Content-Disposition: inline; filename="image005.png"; size=1648; creation-date="Wed, 26 Mar 2014 08:56:49 GMT"; modification-date="Wed, 26 Mar 2014 08:56:49 GMT" Content-ID: <image005.png(a)01CF48D9.B46DEDC0> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACQAAAAUCAYAAADlep81AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAXwSURBVEhL zVZrbBRVFD73zt3udNmlbHnYpYhQYE3rD2OJQFV8JNAYVATlB1hACwLVtAl/lOAPmiUmioSkoSVZ bLAhsfGBBlK1kvpKMBADIvIwTRqyMYW2BIF2u+2+ZuYcz50+pFhSfnKzs7tz53z3fufc75wzKhKJ wP001P1ERnMZl9D6aMs0r1RPIsIcCdKwAR2QsmcyZk/VV628ejcnaupacpO+nCcQsEQiKNSGUvYr lO2Jnn/OfB6psPTUrtpLxpVQ52P8bCYgWBbI9k+ryv/+H6E10ZapeaC2InleE0izJcBkATTEGnEw Dapr88HWc0iwr6lqxZkRYmubm715iekbk6baJpEeIoBpQnPhiwgtArw5KRTsqoy2fsa4fRBOKJGA HZNBLO8HB72A77FpdAyhLdHWEik8dUSwPFcKJi7AIwST0ZQAbKJJAkTYAgxnAH/jKZfQ+rqWB3LN /AMKaJVHSEPbKqaiGKuHReRxBBV4hVEQRyvF5Pd3dAD5CvKDPmHkZQRCltcecc51fku0JWST+mSK MBYPgOMSyBJCiuAPQdDDt7kkqHiK9IT4nsm6zjOuLWiZ6qBPypeTfL4eJs8EIAV4nkhoHAhB87wg Fxg6Wu5neLBphvdgMnrCGUPIBqM6TxqLE2SDV0htdIkPe28OqBOha4GeHrPTZwcDxX2IzxqCKlHy 3voUwX4nIAwm47gRYSc6HCn3Qtb4xW+nXUIDfjU/aeOjTGU13waVPZs12enKa7yhauraCpOmeDPD THOYjEUYs22oOFy94sJ/gLIM/z+lr8po21GfpdL8W8y+bUCtMSZjAV1hWpuatpafvGMjvc6FtbXN X+SGps87Gwtay4K9OYN3I5Q07Wc4KjNYIyxAQltiY1P1i7eRGYtsqipv1zObo61v80+hxjEek0T1 h6uGyOyqrRWx4EI/mOCdCabTy3Op4Gwr1dN5uT1S7iyrO8tHPmP8CHHsHteLso4hA5SArPzybuEc O0/zA1IJrYFBcrp4h59HnsegyOsxPTs4OZbcQMdNdTN3wEBv/jkmu7Mj/LztS/SNT0iCMPUTziAQ JOxJduD6vRASIAOuiPnI+NjiFnAiD49gENQg0NJ84Xk6LnSSDMmhT9qBjnDYgI4YQSh/fEJ8Sv2C jTWINeEZ8KcK2PLyRKTYetA9Zu2MEMFcgsm3YYjdG+gnhzh6rr+2/iZIT7SuMoQ4wZp8l4udLoB+ G/FVBu2ZCMiZ/2ccHCsHhMcHxsxBcJ5jzO8aF+wNZ5KF8WgK6AcO4iJFYt1QVZp4KDOtzgya9lVT yFkEQhLSti0Nrccbq1ecHw9e+XHrKgSZkOlsm+NVV5QURdxaBBfQtzjzTrHoT+6OlOmAfKPxLP6N 7PS6iakMWahg78kbA4VlDRzOD/URsC7mZhUc4Y33K7SPNXLvGuo93U8JctYYEtbbAvc0bl/506aD 3x/hpNjhcHRzhJiLZB1iXB3jjjDupt6AyU+5VzIuod2RCNYc/vXAQCqxJE+oVWkumiaIBUmkeq4r NZuirb1dIe4iIGb5pZyh6w4iupljkPFRUlglAaFe4voFpjAeTiM22EM4V+Ts44NZ/uW2ou8mPDm3 ddS/vnSAC+S2RK6dYU28wj2MdcH5BxDW33oVLV7d2xLcIqSEuMY1VpXf4vZRlRROKkfAao4ufyQH UZSM7Izca7SsA9KAGw6asaIiKuqI6cdeH5PM8JUiHH3rGP1Tv738enFtbcWSwrI3kHCdDVTqByPI 2oIke58E7JUEf9mSvvUnbVcfw6S6F9U2b3ikcOoGy8EKklTKIs/TOJ3wfehoPt1xhy46gMdOl5XZ RTHwQqLvcpycWUxG62201Ix5H2qPRBwuw4deqGv5usCnSvnVYE4WyJMmyEhJnamkuvQpE79TE6cj FdnTjFvzQdvRvKlYmgQqTKNj8nsRcd+7Dqi6r6bTF7/bvjKlseGO41ZPaOH7t6Rq8HBDVKCujaw5 7gsaA/vYYLTy3qsov9pZfottf5zIXuuWbTqHrzHm/wLUFr4zzKdK5gAAAABJRU5ErkJggg== --_005_F2AD894A2AA6704C8D712D76B50B8320AE7564B5SEEX023groupinf_ Content-Type: image/png; name="image006.png" Content-Description: image006.png Content-Disposition: inline; filename="image006.png"; size=3311; creation-date="Wed, 26 Mar 2014 08:56:49 GMT"; modification-date="Wed, 26 Mar 2014 08:56:49 GMT" Content-ID: <image006.png(a)01CF48D9.B46DEDC0> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAQgAAAAQCAYAAADqBOG9AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAxvSURBVHja 7VoNcFTVFb7v3mtIJQgaRBShCFakSPmpVhEDqLRqwaoFRasIogNVYUAo8ishFCFACPt2sySr5IcY qFEGBRUUpCjjdOpABepQSsFarWUsatoZbGc62Ln9zn33be6+fbsJyjhgd5gz7L537rnn97vn3A0r KSlhLdGgVwYXO9Vc7Ti261OllGzNmhzlKEdnPrXI8Pvj+0ru3fkzxVYyNfPtGZ+/r94fk3NcjnKU Awi2819vLpy0Y4KSpY5yIo5qX1aginfP+88BdfD+nPNylKP/Y4DYrw4+VPzbeSfOjxUqFmGKu0L/ f3H0ov9G3l1x4CP16fAzytBS1jEX8Bzl6BQBhFIn+mw6tuFPY9+6TzmrHE3tazqoUa+OPjjr/Vm3 KqUuCBWYYGfLhBzCY3wET/AR0pVXnQ6GcpfP4HH+KIDiWwHg6MDKWA/92WW9QG2+kkNd1om5st8Z nRQuu4joa9inDfm8te91fBRzKF4szi49ZXpA1qmUd5rHNmt+6nqIe/WQESCOqmMDG/685g+XvthT oeAVrxKKR0BPoYuoZKpoR5F64cMXXgNIXJSugLyeV4gPeEzU8YSoE65Yw2Jy2OnhHP4AHHBeCnDE +K3ojp6hz05U7IADL/kqewAQe/Fyfs+ZnEQA05lEX0Oynu9ExJYs7y9GTF73v5v4dJLlcpiMyVPW wZKsUynvdCadny6/O2PsvXpYlxUgTijVZ86umQ+zmWw8i7HxAIe1/GkAhCsXAV3GsxlsgnugfAoA omPoBhFRZSk0FIHdZAKeh80reK2ow/PrzPu+UHgUKc2jopZ4rESdxxsANC4f14xw+V15JZ6BaGwA XchX47sHSE+D94k0pyCheJ2o5TG5hD3HRKAYRtK+QYDA8/vM3vMs3oeoI+I10L9MDgLvWbB3mmX7 JLILfLdZ/Nfj+fiTtR9r7sW7q8GfAOCMD7c/v6uRcTNsHA4ZcxGjxWb9hCz+vM8fu0g2imMY6ZT0 Z5zvJWKlsmewO4Q+ca1/XF4dYv80OvW1D2ppH1ERao+JJ4/y5fDl37DXuJR4lcki7eNyeYMTExvT AMKVRbQH7RWif2e+VsenqEX/0jqXj9WA48rBrZFnZIbbR+ti/OG0/CN7IIOV5fewYpGWXyl5CT0o p8nnWePn8inW+yna/wR4yAl8nwiefOv7WK17Ob89Uz4iFlQPa5MxpxOVTWTnjdw+ssshdegsejhx z8SzA8r+HAYqFhgXsK6AWr4AQNziuGID2sDuAJPulAzYMOYlhIjhFB/F6uGwiKiEvAFQ8hpeLT6h 5ALvXeCp0LwR+SS+T9W8MT6fggxnFXDqSOKyiAi8VdjnMl6JUSaGZKoQfyEZAcT8AYpmBcmhvX1d LH1HQGadPWLo4nL5ErYee7h8MoBlvqe/PIiO6BVejTURFEqMj0bSbqYgEsHujZ4dosHi3w47+xr7 K7Q/6vT6NaxM9s9of1Q8S+t1YKmQkICmQJvtp8/6GZ+OgvpAry/nE5w68SY+/yJFHmwgW4xNSyjJ 9NqoOA7/lGudXPE0neo8LtagC6yndjPgqyUMyaVj4soIvt8ZsP8lPLudQCro7xR7Ip49OmYJsdv3 j4nXYNKDfAzfbRaufDs4YmD9L+kgYFuZtPXH/pux9ldJW1r0rziMva/A8+LWy5MDdO6G2qflDQnk n2ePJyNKIy4VaiC/FgQOrQdMzEfj81Irfo/zesiJ8pU6H1xWCP+/ZQHoW4hDO21rtfgr9BsDHqk7 Qvpezm9hOj6iMWM9atD06kH73Inwpk7VnZoe2f3IG0fV0QvvWT/qwRu3Dde/WgDBPKoE1QAgos6/ WZQ14f8mJy6aIOg9tpCdmwIahJZx8RGU3Yrgb0WQ4z4KagPiUBo8TlTugUJD8XkQCnsDGUJgBZ6d npPkYh8gUAy96bTC+65OlP/OLxDwHsHzbgZNOxPyBZOaOgbwfJslsKaS32U7NAgQVoDmU1eibUnI Yr8Dwv8odvZ9jwcFFJc/BN2IxH+SCM4dbhxck+QvYwOtAO6kAjTrnyFe+ODacPtFjd95QJ/Z+DyX kitg/2EDEI8B+VckO7aYeFnbbcuLigbYMkfbtFo8B3kLsDYf798AXzutnyt+beRNJoAJuV8qIH1B Rdhjp46fZT90uEPfG5Sm+zvUnucYpyIM+P42f+QjX5MPQ0ageaQf9mmbon9MvIk1V7Xav34nE6PO 6yTkke3wI0vwexyXvxuUl8WeQg1wpL+dXwDWwJpF5CN/DPMByB+D8G6OyQfSd4uVX1u8QxQHhsmH JH9zftxs5Wd6PXqAZgGE66grXuyrlh1eVo+RIa/bos4lrIqtwGjhUZSt0giIsaH9inZfnL0sT+Wv zFMyIemXjeMhM/0Iv2UPkoiKXU6VeB6gU8NXy1W6hYPRkF1jivwS22CNfOvI8bIchdaXih+JeAjO rdFEIw+KBk4cQK0vjL88ZI7tCjkLgKA1vErUCpMgLQDEVJ7g7+igV4tK8PzEJMwr2K+LSYg6pttS OZSQ2EPjpINrgvwmIFupeKz1RURh9pMMJMSPUgqCWvqA/cmCMwmlW8QweVHxFP5t1zatETGMCP3x vhPevxySYNR9zA25w7lDj5uVogon2gHEpL9tPyWf7kBC/B1qD/YiH6WNfBGvxcX7c4LFk7be1j89 PkVav3JR6R1erDvFIKs+LcpDrlWIIzqHvZH2Ua/jFbW+vEz2WB35tJT8MiNpygEVGD3o8MOzH1v6 ztT6up49Jn6bCNxM/GYH/DXbyvearPVoA4T++bKMqcs3Xq4GR6/a3G/OZUsHzu61eODcXouvLOmz +OqZ353gM99cPuzu5XuWfvHTxpEqb4WkjuKzDJd+DWEAAWO2oePo4CcbHN6TTmGf3yT0dn+GppPf GPgE2soSE8CkQ9AujddzlNdyzs9w6UJt4LNmbAGffKclfSFroX9JRwkCnjHJjqDUv6MQDUiIm/TM 7rXsS+gzPaPuIshv7H+dktQ/0Q2gDA21HzJIN6PjAtAsah9D7G+jT0DwBO0JyHuGZm1TKNfS3YgB iO1Wgm3XAIG9qMjT4hcVb+tOroz14WvkIUb3ALb9LrvAzLBp/s5gDwHEtkyXxhp4XLk3JKbN64P6 W/HxOlTWH4B4RHrFXUgxyKpPS/KoQ/QBGOcr8vhB37++vIz24GSnOwEzMjfnV+BS24w8czHy5NEa f3/ybVJfFLytr7lz+ru5F5rl54Nln50f9a2pxyRAaJBYyVR+RRvVfnU7dU5lgab8eJ4ScRo1ZHHz z5+qX92HdcVDthURsKQBBKEoneYZbqWvhFIvYkbeAqfMobU0h/r8NC7AyEYzqvTDeLLOaQCvK5dS Iuq2Gae5Uym2EOn5CQHUl2ou34+RZgvAYlXwZxvsNcWppj3lPH/+yqYv/cRHe9LepAMc9z2TsI3+ SKM7FoCBCehjREbeTdZcmuRPs5/uA1DwSNwbw+zXJ3LzCTed5IfYP1bPmN58PT1oT6o/WQ+cGLXa n1Hp6p8KvbGs0TqlGrFHW31PUsv3w+5eafEDQFHngtOznkAmaD94zg3zd4g9k8kenF7vgX96aLzc 9HgF1rdN09+KD5J9EGy4BqfkRtJZd3CwwbyvCNEnqzyKlZ7xwUsxpO4GgHFDUF5o/q1tjheocyC/ +qXlX0Qu1wVs5KfEL1gPXj7NptzSAOSNiNMD/rLzoyJrPfr564pEEiA0SES5YjFHsVWYlJYx1eOF nqrfqwNSAIJo48cbi4teCwcIfcJYN68hDuvC6lk3cpR/k+rz00xKqGjxdsSzbhS4wCzcjcis1w7X lNByO4cAk6Q9zdr81uhLe+q9rT+w0jM4dPRv9GmtL9OXa8uz+U/W/kzyg/Zn3b8Ff+oEs9+TvvpU 1DI6h/1NCBWM5rtT3+3kheoX4u80e0qT+p5PJ3tr42Wv17oG9U+Nj6R7EZz467z7E8tnmN+D+rRC Xp6tnz0+2vKy5V+2/ArkSTtb36z1YPJJ5xL9nUhpWr6k5kdp8/qs+Uh/DwO0UDZhgSqs7aju3ztO VXy0+qXD6r3HbWU+UZ8tKt+3XLVZBDCJsn8EASJHOTrNfvfv61+O5uhL/K0KjwMYQE6Fo/Iq26iJ +yapZX9c/puP1bFJdGnpM+5XB8Y9/8/nG6fumqz61/dVMoY1Uf45ZpjCnCNzlKNvKEBgTOjtU0G8 oPdxdbw3gKFDkHGP2vOd9U3rr2MjWR82C/wJUFxeFvzDoxzlKEffHPofSxluCl3TycEAAAAASUVO RK5CYII= --_005_F2AD894A2AA6704C8D712D76B50B8320AE7564B5SEEX023groupinf_--

1 0

Re: (ITS#7828) LMDB crash in mdb_cursor_put(MDB_CURRENT)
by h.b.furuseth＠usit.uio.no 26 Mar '14

26 Mar '14

Doc bug, fixed recently: MDB_CURRENT must not change the data size. Also with DUPSORT the data item must sort in the same place as the previous one, that needs to be documented too.

1 0

Re: (ITS#7825) LMDB: misleading error message
by timur.kristof＠gmail.com 26 Mar '14

26 Mar '14

--001a11c13346e990f604f57e2991 Content-Type: text/plain; charset=UTF-8 Hi, For further information, see the discussion here: https://github.com/Venemo/node-lmdb/pull/20 We genuinely thought that there had been something wrong with our value sizes somewhere, so I wasted several hours debugging in the wrong place. Then, by accident I discovered that it's in fact an issue with V8's GC. I definitely suggest to choose one of the solutions that don't cost any execution time when there is no error. Perhaps mdb_dbi_close could return an error (or crash) when the dbi is still used by a cursor. That'd eliminate the issue but it'd also mean an API/ABI break. Best regards, Timur On Tue, Mar 25, 2014 at 10:37 AM, Hallvard Breien Furuseth < h.b.furuseth(a)usit.uio.no> wrote: > On Sat, 2014-03-22 at 22:49 +0000, timur.kristof(a)gmail.com wrote: > > When you operate on a dbi using a cursor and accidentally close the dbi > before > > committing the transaction of the cursor, mdb_txn_commit will return > > MDB_BAD_VALSIZE. This is quite misleading because the problem doesn't > actually > > have anything to do with what the error message suggests. ("Too big > key/data, > > key is empty, or wrong DUPFIXED size") > > > > I suggest to either add a new kind of error code for this situation or > to extend > > the description of MDB_BAD_VALSIZE. > > Let's see -- here are the options I can see (after an IRC chat): > > 1) Extending the MDB_BAD_VALSIZE description. Simple. However: > > This is documented as a user error, and it's one which lmdb > won't always catch. If you also called mdb_dbi_open() and the > DBI got reused, lmdb silently updates the wrong named database. > > So I'm a bit wary about both of these fixes: Documenting this > case can be misleading if it makes users expect it to be caught. > > Unless people know better - it corresponds to EBADF for using a > closed file descriptor, not caught if open() reused it. > > > 2) Catch this case and instead return a generic "something is > wrong" - MDB_BAD_TXN or MDB_INCOMPATIBLE. > And maybe assert(did not happen) to teach users to avoid this. > > Needs to be done where md_name is used: Commit/drop(named DB), > page_search(stale named DB), cursor_touch(clean named DB). Or > pass F_SUBDATA inwards and tweak the "return MDB_BAD_VALSIZE" > statements to detect this. > > After playing around a bit, I guess this is my favorite. > > > 3) Leave the misleading message alone, which can send the user > off to a wild goose chase (as described on IRC). > > > Or we can add code to also catch close followed by open: > > 4) Put hash(DB name) in MDB_db.md_pad and verify it before > overwriting a named DB. Costs execution time even when there's > no error. Must be done in commit, drop and maybe cursor_touch. > (I've pushed a demo patch for just commit.) > > 5) Add field MDB_dbx.md_dbiseq = DBI usage sequence number, > incremented when dbi_open creates (not reuses) a DBI and in > dbi_close. Copy it to a new malloced array txn->mt_dbiseqs[] > in write txns, verify it in at least commit and drop. > This means close()-open(same DB) will also be caught, which > seems a good thing since with (4) it will work unreliably: > Only if open() reuses the same DBI for the same DB. > --001a11c13346e990f604f57e2991 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div>Hi,<br><br>For further information, see the disc= ussion here: <a href=3D"https://github.com/Venemo/node-lmdb/pull/20">https:= //github.com/Venemo/node-lmdb/pull/20</a><br></div><div>We genuinely though= t that there had been something wrong with our value sizes somewhere, so I = wasted several hours debugging in the wrong place. Then, by accident I disc= overed that it's in fact an issue with V8's GC.<br> </div><div><br>I definitely suggest to choose one of the solutions that don= 't cost any execution time when there is no error. <br><br></div>Perhap= s mdb_dbi_close could return an error (or crash) when the dbi is still used= by a cursor. That'd eliminate the issue but it'd also mean an API/= ABI break.<br> <br></div>Best regards,<br>Timur<br><div><div><br><br></div></div></div><di= v class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Mar 25, = 2014 at 10:37 AM, Hallvard Breien Furuseth <span dir=3D"ltr"><<a href=3D= "mailto:h.b.furuseth@usit.uio.no" target=3D"_blank">h.b.furuseth(a)usit.uio.n= o</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">On Sat, 2014-03-22 at 22:49 +0000, <a href= =3D"mailto:timur.kristof@gmail.com">timur.kristof(a)gmail.com</a> wrote:<br> > When you operate on a dbi using a cursor and accidentally close the db= i before<br> > committing the transaction of the cursor, mdb_txn_commit will return<b= r> > MDB_BAD_VALSIZE. This is quite misleading because the problem doesn&#3= 9;t actually<br> > have anything to do with what the error message suggests. ("Too b= ig key/data,<br> > key is empty, or wrong DUPFIXED size")<br> ><br> > I suggest to either add a new kind of error code for this situation or= to extend<br> > the description of MDB_BAD_VALSIZE.<br> <br> Let's see -- here are the options I can see (after an IRC chat):<br> <br> 1) Extending the MDB_BAD_VALSIZE description. Simple. However:<br> <br> This is documented as a user error, and it's one which lmdb<br> won't always catch. =C2=A0If you also called mdb_dbi_open() and the<br> DBI got reused, lmdb silently updates the wrong named database.<br> <br> So I'm a bit wary about both of these fixes: Documenting this<br> case can be misleading if it makes users expect it to be caught.<br> <br> Unless people know better - it corresponds to EBADF for using a<br> closed file descriptor, not caught if open() reused it.<br> <br> <br> 2) Catch this case and instead return a generic "something is<br> wrong" - MDB_BAD_TXN or MDB_INCOMPATIBLE.<br> And maybe assert(did not happen) to teach users to avoid this.<br> <br> Needs to be done where md_name is used: Commit/drop(named DB),<br> page_search(stale named DB), cursor_touch(clean named DB). =C2=A0Or<br> pass F_SUBDATA inwards and tweak the "return MDB_BAD_VALSIZE"<br> statements to detect this.<br> <br> After playing around a bit, I guess this is my favorite.<br> <br> <br> 3) Leave the misleading message alone, which can send the user<br> off to a wild goose chase (as described on IRC).<br> <br> <br> Or we can add code to also catch close followed by open:<br> <br> 4) Put hash(DB name) in MDB_db.md_pad and verify it before<br> overwriting a named DB. =C2=A0Costs execution time even when there's<br= > no error. =C2=A0Must be done in commit, drop and maybe cursor_touch.<br> (I've pushed a demo patch for just commit.)<br> <br> 5) Add field MDB_dbx.md_dbiseq =3D DBI usage sequence number,<br> incremented when dbi_open creates (not reuses) a DBI and in<br> dbi_close. =C2=A0Copy it to a new malloced array txn->mt_dbiseqs[]<br> in write txns, verify it in at least commit and drop.<br> This means close()-open(same DB) will also be caught, which<br> seems a good thing since with (4) it will work unreliably:<br> Only if open() reuses the same DBI for the same DB.<br> </blockquote></div><br></div> --001a11c13346e990f604f57e2991--

1 0

(ITS#7828) LMDB crash in mdb_cursor_put(MDB_CURRENT)
by sbn＠tbricks.com 25 Mar '14

25 Mar '14

Full_Name: Dmitri Shubin Version: LMDB 0.9.11 (2727e97) OS: Linux (CentOS 6) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.239.140.98) Hi! I got a crash inside LMDB in mdb_cursor_put() functions when I trying to modify the record under cursor. Simple test: $ cat test-mdb_current.c #include <stdio.h> #include <stdlib.h> #include "lmdb.h" #define E(expr) CHECK((rc = (expr)) == MDB_SUCCESS, #expr) #define CHECK(test, msg) ((test) ? (void)0 : ((void)fprintf(stderr, \ "%s:%d: %s: %s\n", __FILE__, __LINE__, msg, mdb_strerror(rc)), abort())) #define DBDIR "./testdb" int main() { int rc; MDB_env *env; MDB_dbi dbi; MDB_txn *txn; MDB_val key, data; MDB_cursor *cursor; int key_v = 17; char data_v[] = "0123456789"; E(system("rm -rf " DBDIR " && mkdir " DBDIR)); E(mdb_env_create(&env)); E(mdb_env_open(env, DBDIR, 0, 0664)); E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_dbi_open(txn, NULL, 0, &dbi)); /* put some data */ key.mv_data = &key_v; key.mv_size = sizeof(key_v); data.mv_data = data_v; data.mv_size = sizeof(data_v); E(mdb_put(txn, dbi, &key, &data, 0)); E(mdb_txn_commit(txn)); /* replace using cursor */ E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_cursor_open(txn, dbi, &cursor)); E(mdb_cursor_get(cursor, &key, &data, MDB_SET)); data.mv_data = data_v; data.mv_size = sizeof(data_v) - 1; E(mdb_cursor_put(cursor, &key, &data, MDB_CURRENT)); mdb_cursor_close(cursor); E(mdb_txn_commit(txn)); mdb_dbi_close(env, dbi); mdb_env_close(env); return 0; } $ gcc -g test-mdb_current.c -llmdb -L. -Wl,-rpath,. $ ./a.out Segmentation fault (core dumped) $ gdb a.out ... Program terminated with signal 11, Segmentation fault. #0 0x00007fefaba9895c in mdb_leaf_size (env=0xbd8010, key=0x0, data=0x7fff59e6a830) at mdb.c:6430 6430 sz = LEAFSIZE(key, data); (gdb) bt #0 0x00007fefaba9895c in mdb_leaf_size (env=0xbd8010, key=0x0, data=0x7fff59e6a830) at mdb.c:6430 #1 0x00007fefaba97c53 in mdb_cursor_put (mc=0xbda2f0, key=0x0, data=0x7fff59e6a830, flags=64) at mdb.c:6178 #2 0x0000000000400ee0 in main () at test-mdb_current.c:51 (gdb) l 6425 static size_t 6426 mdb_leaf_size(MDB_env *env, MDB_val *key, MDB_val *data) 6427 { 6428 size_t sz; 6429 6430 sz = LEAFSIZE(key, data); 6431 if (sz > env->me_nodemax) { 6432 /* put on overflow page */ 6433 sz -= data->mv_size - sizeof(pgno_t); 6434 } (gdb) p key $1 = (MDB_val *) 0x0 If I remove MDB_CURRENT flag from mdb_cursor_put() call it works fine. Thanks!

1 0

Re: (ITS#7827) Typo in slapacl can causes unclean database
by hyc＠symas.com 25 Mar '14

25 Mar '14

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: openldap master > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.58.125) > > > As reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741248, slapacl > when used with a base that is not contained in the OpenLDAP configuration can > cause unclean DB messages. Fixed now in master > > To reproduce, I had to disable the monitor database in my configuration, so that > there was only the cn=config db and a primary BDB based backend. It also does > not occur if the suffix for the database is "" (as that contains everything). > > If the suffix of the DB is specific(such as "cn=zimbra"), then you can cause the > unclean shutdown status to trigger by running slapacl against a suffix that is > not contained in the slapd configuration: > > zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F > /opt/zimbra/data/ldap/config -b "cn=zimbraaaaa" -D > "uid=zimbra,cn=admins,cn=zimbra" entry > 5331d242 hdb_monitor_db_open: monitoring disabled; configure monitor database to > enable > 5331d242 hdb_db_open: database "cn=zimbra": unclean shutdown detected; > attempting recovery. > 5331d242 hdb_db_open: database "cn=zimbra": recovery skipped in read-only mode. > Run manual recovery if errors are encountered. > authcDN: "uid=zimbra,cn=admins,cn=zimbra" > cn=zimbraaaaa: no target database has been found for baseDN="slapacl"; you may > try with "-u" (dry run). > zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F > /opt/zimbra/data/ldap/config -b "cn=zimbra" -D "uid=zimbra,cn=admins,cn=zimbra" > entry > 5331d258 hdb_db_open: database "cn=zimbra": unclean shutdown detected; > attempting recovery. > 5331d258 hdb_db_open: database "cn=zimbra": recovery skipped in read-only mode. > Run manual recovery if errors are encountered. > 5331d258 hdb_monitor_db_open: monitoring disabled; configure monitor database to > enable > authcDN: "uid=zimbra,cn=admins,cn=zimbra" > entry: write(=wrscxd) > zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F > /opt/zimbra/data/ldap/config -b "cn=zimbra" -D "uid=zimbra,cn=admins,cn=zimbra" > entry > 5331d262 hdb_db_open: database "cn=zimbra": unclean shutdown detected; > attempting recovery. > 5331d262 hdb_db_open: database "cn=zimbra": recovery skipped in read-only mode. > Run manual recovery if errors are encountered. > 5331d262 hdb_monitor_db_open: monitoring disabled; configure monitor database to > enable > authcDN: "uid=zimbra,cn=admins,cn=zimbra" > entry: write(=wrscxd) > > Even running db_recover does not fix it: > > zimbra@zre-ldap001:~/data/ldap/hdb/db$ db_recover > zimbra@zre-ldap001:~/data/ldap/hdb/db$ cd > zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F > /opt/zimbra/data/ldap/config -b "cn=zimbra" -D "uid=zimbra,cn=admins,cn=zimbra" > entry > 5331d350 hdb_db_open: database "cn=zimbra": unclean shutdown detected; > attempting recovery. > 5331d350 hdb_db_open: database "cn=zimbra": recovery skipped in read-only mode. > Run manual recovery if errors are encountered. > 5331d350 hdb_monitor_db_open: monitoring disabled; configure monitor database to > enable > authcDN: "uid=zimbra,cn=admins,cn=zimbra" > entry: write(=wrscxd) > > After starting slapd, the db is properly cleaned up: > > zimbra@zre-ldap001:~$ ps -eaf | grep slapd > zimbra 1655 1 3 12:05 ? 00:00:00 /opt/zimbra/openldap/sbin/slapd > -l LOCAL0 -u zimbra -h ldap://zre-ldap001.eng.zimbra.com:389 ldapi:/// -F > /opt/zimbra/data/ldap/config > > zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F > /opt/zimbra/data/ldap/config -b "cn=zimbra" -D "uid=zimbra,cn=admins,cn=zimbra" > entry > authcDN: "uid=zimbra,cn=admins,cn=zimbra" > entry: write(=wrscxd) > > > > -- -- 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#7827) Typo in slapacl can causes unclean database
by quanah＠OpenLDAP.org 25 Mar '14

25 Mar '14

Full_Name: Quanah Gibson-Mount Version: openldap master OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.58.125) As reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741248, slapacl when used with a base that is not contained in the OpenLDAP configuration can cause unclean DB messages. To reproduce, I had to disable the monitor database in my configuration, so that there was only the cn=config db and a primary BDB based backend. It also does not occur if the suffix for the database is "" (as that contains everything). If the suffix of the DB is specific(such as "cn=zimbra"), then you can cause the unclean shutdown status to trigger by running slapacl against a suffix that is not contained in the slapd configuration: zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F /opt/zimbra/data/ldap/config -b "cn=zimbraaaaa" -D "uid=zimbra,cn=admins,cn=zimbra" entry 5331d242 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable 5331d242 hdb_db_open: database "cn=zimbra": unclean shutdown detected; attempting recovery. 5331d242 hdb_db_open: database "cn=zimbra": recovery skipped in read-only mode. Run manual recovery if errors are encountered. authcDN: "uid=zimbra,cn=admins,cn=zimbra" cn=zimbraaaaa: no target database has been found for baseDN="slapacl"; you may try with "-u" (dry run). zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F /opt/zimbra/data/ldap/config -b "cn=zimbra" -D "uid=zimbra,cn=admins,cn=zimbra" entry 5331d258 hdb_db_open: database "cn=zimbra": unclean shutdown detected; attempting recovery. 5331d258 hdb_db_open: database "cn=zimbra": recovery skipped in read-only mode. Run manual recovery if errors are encountered. 5331d258 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable authcDN: "uid=zimbra,cn=admins,cn=zimbra" entry: write(=wrscxd) zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F /opt/zimbra/data/ldap/config -b "cn=zimbra" -D "uid=zimbra,cn=admins,cn=zimbra" entry 5331d262 hdb_db_open: database "cn=zimbra": unclean shutdown detected; attempting recovery. 5331d262 hdb_db_open: database "cn=zimbra": recovery skipped in read-only mode. Run manual recovery if errors are encountered. 5331d262 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable authcDN: "uid=zimbra,cn=admins,cn=zimbra" entry: write(=wrscxd) Even running db_recover does not fix it: zimbra@zre-ldap001:~/data/ldap/hdb/db$ db_recover zimbra@zre-ldap001:~/data/ldap/hdb/db$ cd zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F /opt/zimbra/data/ldap/config -b "cn=zimbra" -D "uid=zimbra,cn=admins,cn=zimbra" entry 5331d350 hdb_db_open: database "cn=zimbra": unclean shutdown detected; attempting recovery. 5331d350 hdb_db_open: database "cn=zimbra": recovery skipped in read-only mode. Run manual recovery if errors are encountered. 5331d350 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable authcDN: "uid=zimbra,cn=admins,cn=zimbra" entry: write(=wrscxd) After starting slapd, the db is properly cleaned up: zimbra@zre-ldap001:~$ ps -eaf | grep slapd zimbra 1655 1 3 12:05 ? 00:00:00 /opt/zimbra/openldap/sbin/slapd -l LOCAL0 -u zimbra -h ldap://zre-ldap001.eng.zimbra.com:389 ldapi:/// -F /opt/zimbra/data/ldap/config zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F /opt/zimbra/data/ldap/config -b "cn=zimbra" -D "uid=zimbra,cn=admins,cn=zimbra" entry authcDN: "uid=zimbra,cn=admins,cn=zimbra" entry: write(=wrscxd)

1 0

Re: (ITS#7825) LMDB: misleading error message
by h.b.furuseth＠usit.uio.no 25 Mar '14

25 Mar '14

I wrote: > Let's see -- here are the options I can see (after an IRC chat): > (...) > 2) Catch this case and instead return a generic "something is > wrong" - MDB_BAD_TXN or MDB_INCOMPATIBLE. > (...) Duh, I forgot (6) Like (2) but create a new error code after all. Then we can document in its description that it's not caught reliably. That wasn't hard:-)

1 0

Re: (ITS#7825) LMDB: misleading error message
by h.b.furuseth＠usit.uio.no 25 Mar '14

25 Mar '14

On Sat, 2014-03-22 at 22:49 +0000, timur.kristof(a)gmail.com wrote: > When you operate on a dbi using a cursor and accidentally close the dbi before > committing the transaction of the cursor, mdb_txn_commit will return > MDB_BAD_VALSIZE. This is quite misleading because the problem doesn't actually > have anything to do with what the error message suggests. ("Too big key/data, > key is empty, or wrong DUPFIXED size") > > I suggest to either add a new kind of error code for this situation or to extend > the description of MDB_BAD_VALSIZE. Let's see -- here are the options I can see (after an IRC chat): 1) Extending the MDB_BAD_VALSIZE description. Simple. However: This is documented as a user error, and it's one which lmdb won't always catch. If you also called mdb_dbi_open() and the DBI got reused, lmdb silently updates the wrong named database. So I'm a bit wary about both of these fixes: Documenting this case can be misleading if it makes users expect it to be caught. Unless people know better - it corresponds to EBADF for using a closed file descriptor, not caught if open() reused it. 2) Catch this case and instead return a generic "something is wrong" - MDB_BAD_TXN or MDB_INCOMPATIBLE. And maybe assert(did not happen) to teach users to avoid this. Needs to be done where md_name is used: Commit/drop(named DB), page_search(stale named DB), cursor_touch(clean named DB). Or pass F_SUBDATA inwards and tweak the "return MDB_BAD_VALSIZE" statements to detect this. After playing around a bit, I guess this is my favorite. 3) Leave the misleading message alone, which can send the user off to a wild goose chase (as described on IRC). Or we can add code to also catch close followed by open: 4) Put hash(DB name) in MDB_db.md_pad and verify it before overwriting a named DB. Costs execution time even when there's no error. Must be done in commit, drop and maybe cursor_touch. (I've pushed a demo patch for just commit.) 5) Add field MDB_dbx.md_dbiseq = DBI usage sequence number, incremented when dbi_open creates (not reuses) a DBI and in dbi_close. Copy it to a new malloced array txn->mt_dbiseqs[] in write txns, verify it in at least commit and drop. This means close()-open(same DB) will also be caught, which seems a good thing since with (4) it will work unreliably: Only if open() reuses the same DBI for the same DB.

1 0

Re: (ITS#7616) syncrepl enhancement: defer requests when refreshing
by hyc＠symas.com 24 Mar '14

24 Mar '14

This is a multi-part message in MIME format. --------------050807020608030505070800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit hyc(a)symas.com wrote: > Michael Ströder wrote: >> hyc(a)symas.com wrote: >>> I was considering returning LDAP_BUSY for this case, but it may make more >>> sense to return a REFERRAL to the provider instead. (Although again, if we >>> have two MMR servers pointed at each other starting at the same time, they >>> would just refer to each other and clients would get nowhere until one of them >>> finishes its refresh.) >> >> IMO referrals are harmful. >> Just returning LDAP_BUSY seems best to me because if reliable HA is really >> important for a deployment you have decent load-balancers in front of your >> LDAP server which should do a proper health-check. The attached patch should provide the desired behavior. It needs more testing though. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------050807020608030505070800 Content-Type: text/plain; charset=UTF-8; name="diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="diff.txt" diff --git a/servers/slapd/syncrepl.c b/servers/slapd/syncrepl.c index 9b5c0f3..4ea8a70 100644 --- a/servers/slapd/syncrepl.c +++ b/servers/slapd/syncrepl.c @@ -148,6 +148,8 @@ static int syncrepl_add_glue_ancestors( /* delta-mmr overlay handler */ static int syncrepl_op_modify( Operation *op, SlapReply *rs ); +static int syncrepl_op_search( Operation *op, SlapReply *rs ); + /* callback functions */ static int dn_callback( Operation *, SlapReply * ); static int nonpresent_callback( Operation *, SlapReply * ); @@ -216,16 +218,14 @@ init_syncrepl(syncinfo_t *si) if ( !syncrepl_ov.on_bi.bi_type ) { syncrepl_ov.on_bi.bi_type = "syncrepl"; syncrepl_ov.on_bi.bi_op_modify = syncrepl_op_modify; + syncrepl_ov.on_bi.bi_op_search = syncrepl_op_search; overlay_register( &syncrepl_ov ); } - /* delta-MMR needs the overlay, nothing else does. - * This must happen before accesslog overlay is configured. - */ - if ( si->si_syncdata && - !overlay_is_inst( si->si_be, syncrepl_ov.on_bi.bi_type )) { + if (!overlay_is_inst( si->si_be, syncrepl_ov.on_bi.bi_type )) { overlay_config( si->si_be, syncrepl_ov.on_bi.bi_type, -1, NULL, NULL ); - if ( !ad_reqMod ) { + /* delta-MMR needs this. Must happen before accesslog overlay is configured. */ + if ( si->si_syncdata && !ad_reqMod ) { const char *text; logschema *ls = &accesslog_sc; @@ -1179,6 +1179,7 @@ do_syncrep2( } else { rc = -2; } + si->si_refreshDone = 1; goto done; case LDAP_RES_INTERMEDIATE: @@ -2164,6 +2165,31 @@ syncrepl_op_modify( Operation *op, SlapReply *rs ) } static int +syncrepl_op_search( Operation *op, SlapReply *rs ) +{ + slap_overinst *on = (slap_overinst *)op->o_bd->bd_info; + syncinfo_t *si; + + /* Allow syncrepl internal searches */ + if ( op->o_conn->c_conn_idx == -1 ) + return SLAP_CB_CONTINUE; + + /* Check if any of our consumers are refreshing */ + for ( si = op->o_bd->be_syncinfo; si; si = si->si_next ) { + /* If we have some state, allow other consumers to progress */ + if ( si->si_cookieState->cs_num > 0 && + op->o_sync > SLAP_CONTROL_IGNORED ) + return SLAP_CB_CONTINUE; + /* If we have any consumer refreshing, reject searches */ + if ( !si->si_refreshDone ) { + send_ldap_error( op, rs, LDAP_BUSY, "syncrepl refresh in progress" ); + return rs->sr_err; + } + } + return SLAP_CB_CONTINUE; +} + +static int syncrepl_message_to_op( syncinfo_t *si, Operation *op, --------------050807020608030505070800--

1 0

Re: (ITS#7336) Ldapmodify crashes slapd when updating olcTLSVerifyClient attribute via TLS authentication
by ck＠cksoft.de 23 Mar '14

23 Mar '14

Hi, I can confirm that openldap-2.4.39 still has in issue with this. When connecting via TLS I tried to modify olcTLSVerifyClient from never to try with following ldif: dn: cn=config changetype: modify replace: olcTLSVerifyClient olcTLSVerifyClient: try this caused slapd to hang indefinetely. I was able to successfully modify above when connecting without TLS. I need to complete my current task but will set up a small proof of concept later on in my lab. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/

1 0

(ITS#7825) LMDB: misleading error message
by timur.kristof＠gmail.com 22 Mar '14

22 Mar '14

Full_Name: Timur Kristóf Version: LMDB latest master OS: Fedora 20 URL: Submission from: (NULL) (94.248.245.60) Hi, I'm the author of the Node.js LMDB binding and I've found an interesting issue that might be useful to share with other people who develop bindings or applications on LMDB. When you operate on a dbi using a cursor and accidentally close the dbi before committing the transaction of the cursor, mdb_txn_commit will return MDB_BAD_VALSIZE. This is quite misleading because the problem doesn't actually have anything to do with what the error message suggests. ("Too big key/data, key is empty, or wrong DUPFIXED size") I suggest to either add a new kind of error code for this situation or to extend the description of MDB_BAD_VALSIZE. Here's a small test case which will demonstrate it: http://pastebin.com/hHwD1srf Best regards, Timur Kristóf

1 0

Re: (ITS#7822) Segmentation fault while modifying olcDbMaxSize
by quanah＠zimbra.com 21 Mar '14

21 Mar '14

--On Friday, March 21, 2014 10:28 AM +0000 frederic.poisson(a)admin.gmessaging.net wrote: > Full_Name: Frederic POISSON > Version: 2.4.39 > OS: Linux RHEL5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (57.250.229.136) > > > Hello, > I have a Segmentation fault while i'm updating the value of olcDbMaxSize > parameter to a number inside olcDatabase={1}mdb,cn=config. The result of > a gdb backtrace show this error : > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x42499940 (LWP 31424)] > 0x0000000000553683 in ppolicy_connection_destroy (bd=0x424989d0, > conn=0x18ab2a50) at ppolicy.c:1260 > 1260 if ( !BER_BVISEMPTY( &pwcons[conn->c_conn_idx].dn )) { > > The ldif for the modification is : > dn: olcDatabase={1}mdb,cn=config > changetype: modify > replace: olcDbMaxSize > olcDbMaxSize: 20737418240 > > I will push onto FTP the full log of the backtrace, the cn=config.ldif > from slapcat. Hoping it could help for resolution. Please provide the full backtrace in the ITS --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7824) Segmentation fault while modifying olcDbMaxSize
by frederic.poisson＠admin.gmessaging.net 21 Mar '14

21 Mar '14

Full_Name: Frederic POISSON Version: 2.4.39 OS: Linux RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (57.250.229.136) Hello, I have a Segmentation fault while i'm updating the value of olcDbMaxSize parameter to a number inside olcDatabase={1}mdb,cn=config. The result of a gdb backtrace show this error : Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42499940 (LWP 31424)] 0x0000000000553683 in ppolicy_connection_destroy (bd=0x424989d0, conn=0x18ab2a50) at ppolicy.c:1260 1260 if ( !BER_BVISEMPTY( &pwcons[conn->c_conn_idx].dn )) { The ldif for the modification is : dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcDbMaxSize olcDbMaxSize: 20737418240 I will push onto FTP the full log of the backtrace, the cn=config.ldif from slapcat. Hoping it could help for resolution. Regards,

1 0

(ITS#7823) Segmentation fault while modifying olcDbMaxSize
by frederic.poisson＠admin.gmessaging.net 21 Mar '14

21 Mar '14

Full_Name: Frederic POISSON Version: 2.4.39 OS: Linux RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (57.250.229.136) Hello, I have a Segmentation fault while i'm updating the value of olcDbMaxSize parameter to a number inside olcDatabase={1}mdb,cn=config. The result of a gdb backtrace show this error : Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42499940 (LWP 31424)] 0x0000000000553683 in ppolicy_connection_destroy (bd=0x424989d0, conn=0x18ab2a50) at ppolicy.c:1260 1260 if ( !BER_BVISEMPTY( &pwcons[conn->c_conn_idx].dn )) { The ldif for the modification is : dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcDbMaxSize olcDbMaxSize: 20737418240 I will push onto FTP the full log of the backtrace, the cn=config.ldif from slapcat. Hoping it could help for resolution. Regards,

1 0

(ITS#7822) Segmentation fault while modifying olcDbMaxSize
by frederic.poisson＠admin.gmessaging.net 21 Mar '14

21 Mar '14

Full_Name: Frederic POISSON Version: 2.4.39 OS: Linux RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (57.250.229.136) Hello, I have a Segmentation fault while i'm updating the value of olcDbMaxSize parameter to a number inside olcDatabase={1}mdb,cn=config. The result of a gdb backtrace show this error : Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42499940 (LWP 31424)] 0x0000000000553683 in ppolicy_connection_destroy (bd=0x424989d0, conn=0x18ab2a50) at ppolicy.c:1260 1260 if ( !BER_BVISEMPTY( &pwcons[conn->c_conn_idx].dn )) { The ldif for the modification is : dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcDbMaxSize olcDbMaxSize: 20737418240 I will push onto FTP the full log of the backtrace, the cn=config.ldif from slapcat. Hoping it could help for resolution. Regards,

1 0

(ITS#7821) address of strcasecmp in ldapsearch.c
by heiko.nardmann＠itechnical.de 20 Mar '14

20 Mar '14

Full_Name: Heiko Nardmann Version: 2.4.39 OS: MinGW32 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:a60:f08d:1:159e:f75f:8f0:44f1) In clients/tools/ldapsearch.c the address of 'strcasecmp' is taken (inside 'dosearch()') around line 1455. That means that 'strcasecmp' is exported as an undefined symbol into ldapsearch.o even if 'strcasecmp' is declared as 'always_inline'. MinGW is such a platform which offers 'strcasecmp' by providing an inline version of 'strcasecmp' (redirecting it to 'stricmp'). So this taking of an address breaks linking. Workaround: before 'dosearch()' I place a local wrapper: static int local_strcasecmp(const char *s1, const char *s2) { return strcasecmp(s1, s2); } and inside 'dosearch' instead of if( sortattr ) { (void) ldap_sort_entries( ld, &res, ( *sortattr == '\0' ) ? NULL : sortattr, strcasecmp ); } I now have if( sortattr ) { (void) ldap_sort_entries( ld, &res, ( *sortattr == '\0' ) ? NULL : sortattr, local_strcasecmp ); } Some options to really solve that issue: 1) use my approach for all platforms. 2) change autoconf stuff to detect whether 'strcasecmp' is just inlined (MinGW) or a "real" function (other platforms). Thx in advance! Heiko

1 0

Re: (ITS#7587) slapd crashes when using pcache overlay applied to a translucent proxy
by hyc＠symas.com 18 Mar '14

18 Mar '14

amoneger(a)cisco.com wrote: > Full_Name: Alex > Version: 2.4.35 > OS: Centos 6.3 (2.6.32-279.el6.x86_64 #1 SMP) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.103.25.102) > > > When using the pcache overlay over a translucent proxy, the slapd daemon crashes > after the second LDAP request which misses the cache. For example, the following > requests will trigger the issue. The important part is to miss the cache. > Assuming nothing is cached for the aaaa and bbbb uid, the following request will > trigger the issue (172.16.206.156 being the openldap server): Thanks for the report, this is now fixed in git master. > ldapsearch -x -H ldap://172.16.206.156 -b "ou=yyyy,o=xxxx" -LLL "uid=aaaa" uid > st > ldapsearch -x -H ldap://172.16.206.156 -b "ou=yyyy,o=xxxx" -LLL "uid=bbbb" uid > st > > Whether aaaa and bbbb exist or not does not matter. > > The following config is used: > > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/misc.schema > include /usr/local/etc/openldap/schema/nis.schema > > moduleload pcache.la > moduleload translucent.la > > database bdb > suffix "o=xxxx" > #checkpoint 1024 15 > rootdn "uid=amoneger,ou=yyyy,o=xxxx" > overlay translucent > translucent_local uidNumber,gidNumber,homeDirectory,loginShell > translucent_strict > rootdn "uid=amoneger,ou=yyyy,o=xxxx" > uri ldap://zzzz/ > #tls ldaps tls_reqcert=demand > tls_cacert=/usr/local/etc/openldap/certs/Cisco_ca_chain > overlay pcache > pcache bdb 10000 1 50 100 > pcacheAttrset 0 * > pcacheTemplate (uid=) 0 3600 > pcacheBind (uid=) 0 1800 sub ou=yyyy,o=xxxx > pcacheOffline TRUE > pcachePersist TRUE > pcacheValidate FALSE > directory /var/cache/ldap > cachesize 1000 > index pcacheQueryid eq > > The crash seems to be caused by a SIGABRT which is raised by libc free() due to > a double free. Here is the traceback: > Breakpoint 2, 0x000000312aa33f10 in abort () from /lib64/libc.so.6 > (gdb) c > Continuing. > > Program received signal SIGABRT, Aborted. > 0x000000312aa328a5 in raise () from /lib64/libc.so.6 > (gdb) bt > #0 0x000000312aa328a5 in raise () from /lib64/libc.so.6 > #1 0x000000312aa34085 in abort () from /lib64/libc.so.6 > #2 0x000000312aa707b7 in __libc_message () from /lib64/libc.so.6 > #3 0x000000312aa760e6 in malloc_printerr () from /lib64/libc.so.6 > #4 0x000000000042391e in do_search (op=0x7f135c000b80, rs=0x7f1366764930) at > search.c:263 > #5 0x0000000000421449 in connection_operation (ctx=0x7f1366764a90, > arg_v=0x7f135c000b80) at connection.c:1155 > #6 0x0000000000421c25 in connection_read_thread (ctx=0x7f1366764a90, > argv=<value optimized out>) at connection.c:1291 > #7 0x00000000005601f0 in ldap_int_thread_pool_wrapper (xpool=0x1f42770) at > tpool.c:688 > #8 0x000000312b207851 in start_thread () from /lib64/libpthread.so.0 > #9 0x000000312aae890d in clone () from /lib64/libc.so.6 > > I was unable to track back the particular piece of code triggering the double > free, but the same pointer p is freed twice by ber_memfree_x() in memory.c: > > (gdb) delete 3 > (gdb) break search.c:263 > Breakpoint 4 at 0x5645df: file search.c, line 263. > (gdb) c > Continuing. > > Breakpoint 4, do_search (op=0x7fa554002930, rs=0x7fa5623a4930) at search.c:263 > 263 op->o_tmpfree( op->ors_attrs, op->o_tmpmemctx ); > (gdb) s > slap_sl_free (ptr=0x1d64a10, ctx=0x7fa554002780) at sl_malloc.c:493 > 493 { > (gdb) s > 498 if (!ptr) > (gdb) s > 501 if (No_sl_malloc || !sh || ptr < sh->sh_base || ptr >= sh->sh_end) { > (gdb) s > 502 ber_memfree_x(ptr, NULL); > (gdb) s > 649 } > (gdb) s > 502 ber_memfree_x(ptr, NULL); > (gdb) s > ber_memfree_x (p=0x1d64a10, ctx=0x0) at memory.c:127 > 127 { > (gdb) s > 128 if( p == NULL ) { > (gdb) s > 134 if( ber_int_memory_fns == NULL || ctx == NULL ) { > (gdb) s > 160 } > (gdb) s > 152 free( p ); > (gdb) print p > $1 = (void *) 0x1d64a10 > (gdb) x/10x p > 0x1d64a10: 0x00000001 0x00000000 0x005ffd31 0x00000000 > 0x1d64a20: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x1d64a30: 0x00000000 0x00000000 > (gdb) c > Continuing. > [New Thread 0x7fa561994700 (LWP 5823)] > > Breakpoint 4, do_search (op=0x7fa554002930, rs=0x7fa5623a4930) at search.c:263 > 263 op->o_tmpfree( op->ors_attrs, op->o_tmpmemctx ); > (gdb) s > slap_sl_free (ptr=0x1d64a10, ctx=0x7fa554002780) at sl_malloc.c:493 > 493 { > (gdb) s > 498 if (!ptr) > (gdb) s > 501 if (No_sl_malloc || !sh || ptr < sh->sh_base || ptr >= sh->sh_end) { > (gdb) s > 502 ber_memfree_x(ptr, NULL); > (gdb) s > 649 } > (gdb) s > 502 ber_memfree_x(ptr, NULL); > (gdb) s > ber_memfree_x (p=0x1d64a10, ctx=0x0) at memory.c:127 > 127 { > (gdb) s > 128 if( p == NULL ) { > (gdb) s > 134 if( ber_int_memory_fns == NULL || ctx == NULL ) { > (gdb) s > 160 } > (gdb) s > 152 free( p ); > (gdb) print P > No symbol "P" in current context. > (gdb) print p > $2 = (void *) 0x1d64a10 > (gdb) x/10x p > 0x1d64a10: 0x00000000 0x00000000 0x005ffd31 0x00000000 > 0x1d64a20: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x1d64a30: 0x00000000 0x00000000 > > So the same pointer is being freed twice by the 2 connections which miss the > cache. I'm unable to figure out who is responsible for that call though, but the > same op->ors_attrs is freed by do_search(): > > if ( op->ors_attrs != NULL ) { > op->o_tmpfree( op->ors_attrs, op->o_tmpmemctx ); > > Parameters seem correct in both cases: > (gdb) print op->o_hdr->oh_tmpmfuncs->bmf_free > $12 = (BER_MEMFREE_FN *) 0x4733f0 <slap_sl_free> > (gdb) print op->o_request.oq_search.rs_attrs > $15 = (AttributeName *) 0x1f85a10 > > The call is done via connection_operation(), but that code part is a bit above > my head, so I'm unable to track this further. > > I thought this could be due to a threading problem, but building slapd with > --with-threads=no does not make a difference. > > I tried uploading the core dump to your ftp server, but seems like there is an > issue with ftp.openldap.org > [root@centos63 tmp]# ftp ftp.openldap.org > Trying 204.152.186.57... > Connected to ftp.openldap.org (204.152.186.57). > 220- OpenLDAP FTP Service > 220 boole.openldap.org FTP server (Version 6.00LS) ready. > Name (ftp.openldap.org:cisco): anonymous > 331 Guest login ok, send your email address as password. > Password: > 230- Copyright 1998-2010, The OpenLDAP Foundation, All Rights Reserved. > 230- COPYING RESTRICTIONS APPLY, see: > 230- ftp://ftp.openldap.org/COPYRIGHT > 230- ftp://ftp.openldap.org/LICENSE > 230 Guest login ok, access restrictions apply. > Remote system type is UNIX. > Using binary mode to transfer files. > ftp> cd incoming > 250 CWD command successful. > ftp> binary > 200 Type set to I. > ftp> put core-slapd-6-55-55-26548-1368063267 > local: core-slapd-6-55-55-26548-1368063267 remote: > core-slapd-6-55-55-26548-1368063267 > 227 Entering Passive Mode (204,152,186,57,242,33) > 553 core-slapd-6-55-55-26548-1368063267: No space left on device. > > Let me know if you need anything. I can provide further debugs or cores. I'm > also happy to try things out. > > Cheers, > Alex > > -- -- 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#7723
by hyc＠symas.com 18 Mar '14

18 Mar '14

michael(a)stroeder.com wrote: > Could anybody please review the patch Jan provided in his last follow-up? > > http://www.openldap.org/its/index.cgi?findid=7723#followup9 > > Anythin wrong with his reference count fix? > > We are getting occasional seg faults in slapo-rwm which are very hard to > reproduce and therefore are considering this patch. Looks OK to me, committed to master. Please report back any positive/negative results. -- -- 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#7723
by michael＠stroeder.com 18 Mar '14

18 Mar '14

Could anybody please review the patch Jan provided in his last follow-up? http://www.openldap.org/its/index.cgi?findid=7723#followup9 Anythin wrong with his reference count fix? We are getting occasional seg faults in slapo-rwm which are very hard to reproduce and therefore are considering this patch. Ciao, Michael.

1 0

Re: (ITS#7820) slapo-constraint falsely allows add with count 1
by pierangelo.masarati＠polimi.it 15 Mar '14

15 Mar '14

On 03/15/2014 05:38 PM, michael(a)stroeder.com wrote: > Full_Name: > Version: 2.4.39 > OS: not relevant > URL: > Submission from: (NULL) (79.219.107.130) > > > Not sure whether this is a regression caused by the fix for ITS#7773. > > Given this constraint: > > constraint_attribute > uid > count 1 > restrict="ldap:///ou=example??sub?(objectClass=account)" > > One can still add two 'uid' values when sending an add request like this: > > dn: uid=test1,ou=example > changetype: add > objectClass: account > uid: test2 > [..] > > Generally I don't like this magic of accepting both attribute values from DN and > entry. :-/ Indeed, the check (and magic) of adding distinguished value(s) to entry occurs during entry_naming_check(), which occurs during entry_schema_check(), which occurs in the backend add operations, right after overlays had a chance to look at the entry. 2 approaches: a) anticipate naming check b) duplicate naming check in slapo-constraint (b) is a waste, but "localized"; not sure what would be the side effects of (a). p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7820) slapo-constraint falsely allows add with count 1
by michael＠stroeder.com 15 Mar '14

15 Mar '14

Full_Name: Version: 2.4.39 OS: not relevant URL: Submission from: (NULL) (79.219.107.130) Not sure whether this is a regression caused by the fix for ITS#7773. Given this constraint: constraint_attribute uid count 1 restrict="ldap:///ou=example??sub?(objectClass=account)" One can still add two 'uid' values when sending an add request like this: dn: uid=test1,ou=example changetype: add objectClass: account uid: test2 [..] Generally I don't like this magic of accepting both attribute values from DN and entry. :-/

1 0

Re: (ITS#7673) rwm and bad ACL evaluation
by hyc＠symas.com 15 Mar '14

15 Mar '14

michael(a)stroeder.com wrote: > This is a cryptographically signed message in MIME format. Is it really necessary to sign your emails to the ITS? The PKCS7 signature is longer than the message text. > --------------ms020400000305090906010704 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > Mosemann, Russell wrote: >>> Did you already try with this? >>> >>> rwm-drop-unrequested-attrs no >> =20 >> If you look through the messages >> (http://www.openldap.org/its/index.cgi?findid=3D7673), you will see tha= > t the >> same suggestion was made by Pierangelo Masarati 6 months ago in followu= > p 5. >> My response in followup 6 was that it doesn't work. A quick test indica= > tes >> that it still does not work in 2.4.39. > > I had a similar issue myself before: > > http://www.openldap.org/its/index.cgi?findid=3D7495 > > Using extra_attrs as suggested by Hallvard gave seg fault as result. > Did not investigate it further though. > > Using slapo-rwm is a pain. One will hit many seg faults. There are quite a few open bug reports against slapo-rwm. Patches welcome. > > Ciao, Michael. -- -- 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#7673) rwm and bad ACL evaluation
by michael＠stroeder.com 15 Mar '14

15 Mar '14

This is a cryptographically signed message in MIME format. --------------ms020400000305090906010704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mosemann, Russell wrote: >> Did you already try with this? >> >> rwm-drop-unrequested-attrs no >=20 > If you look through the messages > (http://www.openldap.org/its/index.cgi?findid=3D7673), you will see tha= t the > same suggestion was made by Pierangelo Masarati 6 months ago in followu= p 5. > My response in followup 6 was that it doesn't work. A quick test indica= tes > that it still does not work in 2.4.39. I had a similar issue myself before: http://www.openldap.org/its/index.cgi?findid=3D7495 Using extra_attrs as suggested by Hallvard gave seg fault as result. Did not investigate it further though. Using slapo-rwm is a pain. One will hit many seg faults. Ciao, Michael. --------------ms020400000305090906010704 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMzE1MTEwMDAyWjAj BgkqhkiG9w0BCQQxFgQUUSa2ArlMv5dRmzJlQRq5PcrRHkUwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAvyDf1DHX6lO5GY/rJUE8fG+SMoafXeCK H7gMAa2TDdkjvgjPDrfVSXHu+c0SGwayuluYm+A1NLPrJ0yuDD056fBFEBle/2mf6iD/AUC4 WqoLNLNtNAXomiyHoztxopV83jzbbA4xCHMvPr9PRtbtrr+uTmZGjOcxuEBj+0K+nUM4xFAU OFWve6ySjrFpGj/7JfTkgMq2hqlkmLn6v9VgqqldkY5lEEKDbS3pFPyi+cTpB8EGh5uANGv9 q2ga1fkbkSBrMHEntQdvdT/puvVPZPJxgtL7ooTIXvmCQVMGnUEtOylUgYpCpCUHq3LXJ7dE DM2tyDJ3+1IRihV81j/h0AAAAAAAAA== --------------ms020400000305090906010704--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs