June 2013 - openldap-bugs

Re: (ITS#7623) P_SUBP page inn MDB dirty_list
by h.b.furuseth＠usit.uio.no 16 Jun '13

16 Jun '13

Howard Chu writes: > Obviously this and the preceding line can be reduced to > mp->mp_flags = fp->mp_flags ^ (P_DIRTY|P_SUBP|P_FAKE); They are not equivalent. fp->mp_flags can be P_LEAF|P_DIRTY in branch "yes, convert it" and P_LEAF|P_DIRTY|P_SUBP|P_FAKE in the other branch. > With P_FAKE removed if your patch isn't kept. No, I don't want to steal a bit just for debugging either. I'm happy with "mp->mp_flags = (fp->mp_flags | P_DIRTY) & ~P_SUBP;" if the above was just a thinko. Well, I might include P_FAKE in my mdb/tests branch, #defined as 0 except when the MDB_TEST macro turns it on. -- Hallvard

1 0

Re: (ITS#7623) P_SUBP page inn MDB dirty_list
by hyc＠symas.com 16 Jun '13

16 Jun '13

hyc(a)symas.com wrote: > This is a multi-part message in MIME format. > --------------010403050509060707070108 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > h.b.furuseth(a)usit.uio.no wrote: >> Full_Name: Hallvard B Furuseth >> Version: RE24 + mdb.master 2d0b362b6f2b1247eb693008a39efaf341f15e82 >> OS: Linux x86_64 >> URL: >> Submission from: (NULL) (193.69.163.163) >> Submitted by: hallvard >> >> >> test043-delta-syncrepl crashes in RE24 + mdb.master + this patch. >> A sub-cursor sees a regular (non-sub) page which has P_SUB set, >> in dirty_list. The flag comes from the fake page in cursor_put. > > The flag is being propagated when the page grows and turns into a real page. > Fixed by this simple patch. Obviously this and the preceding line can be reduced to mp->mp_flags = fp->mp_flags ^ (P_DIRTY|P_SUBP|P_FAKE); With P_FAKE removed if your patch isn't kept. -- -- 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#7623) P_SUBP page inn MDB dirty_list
by hyc＠symas.com 16 Jun '13

16 Jun '13

This is a multi-part message in MIME format. --------------010403050509060707070108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE24 + mdb.master 2d0b362b6f2b1247eb693008a39efaf341f15e82 > OS: Linux x86_64 > URL: > Submission from: (NULL) (193.69.163.163) > Submitted by: hallvard > > > test043-delta-syncrepl crashes in RE24 + mdb.master + this patch. > A sub-cursor sees a regular (non-sub) page which has P_SUB set, > in dirty_list. The flag comes from the fake page in cursor_put. The flag is being propagated when the page grows and turns into a real page. Fixed by this simple patch. I don't think we actually want to keep the debug code/flag you added, but I'll leave it to you to commit. > > Patch: > - Set P_FAKE flag for debugging, to see where the flag comes from. > - assert(not P_SUB) in page_get. > - valloc pages so we can see from the page address that it is > a regular page. > > --- libraries/liblmdb/mdb.c > +++ libraries/liblmdb/mdb.c > @@ -59,2 +59,3 @@ > #include <unistd.h> > +#include <malloc.h> > > @@ -582,2 +583,3 @@ typedef struct MDB_page { > #define P_SUBP 0x40 /**< for #MDB_DUPSORT sub-pages */ > +#define P_FAKE 0x80 /**< fake page */ > /** @} */ > @@ -1271,3 +1273,3 @@ mdb_page_malloc(MDB_cursor *mc, unsigned num) > } > - if ((ret = malloc(sz)) != NULL) { > + if ((ret = valloc(sz)) != NULL) { > VGMEMP_ALLOC(env, ret, sz); > @@ -2478,2 +2480,3 @@ mdb_txn_commit(MDB_txn *txn) > dp = txn->mt_u.dirty_list[i].mptr; > + assert(!(dp->mp_flags & P_SUBP)); > if (dp->mp_pgno != next) { > @@ -4069,2 +4072,3 @@ mdb_page_get(MDB_txn *txn, pgno_t pgno, MDB_page **ret, > int *lvl) > p = dl[x].mptr; > + /* assert(!(p->mp_flags & P_SUBP)); */ > goto done; > @@ -5164,3 +5168,3 @@ more: > fp->mp_pgno = mc->mc_pg[mc->mc_top]->mp_pgno; > - fp->mp_flags = P_LEAF|P_DIRTY|P_SUBP; > + fp->mp_flags = P_LEAF|P_DIRTY|P_SUBP|P_FAKE; > fp->mp_lower = PAGEHDRSZ; > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------010403050509060707070108 Content-Type: text/plain; charset=UTF-8; name="dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dif.txt" diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index c9f98cc..1bc0f14 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -5242,6 +5242,7 @@ reuse: flags |= F_DUPDATA; } mp->mp_flags = fp->mp_flags | P_DIRTY; + mp->mp_flags &= ~(P_SUBP|P_FAKE); mp->mp_pad = fp->mp_pad; mp->mp_lower = fp->mp_lower; mp->mp_upper = fp->mp_upper + offset; --------------010403050509060707070108--

1 0

(ITS#7625) ppolicy doesn't support changing olcPasswordHash without restart
by joke＠seiken.de 14 Jun '13

14 Jun '13

Full_Name: Joke de Buhr Version: 2.4.35 OS: fedora 18 64bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.5.143.82) While using the password policy overlay changing the parameter olcPasswordHash causes an error upon password update. When changing the password via ldappasswd after changing the parameter olcPasswordHash the error Constraint violation (19) Password policy only allows one password value if returned to the client. Changing the password isn't possible until slapd is restarted. After restarting slapd changing the password works again. Please refer to my postings [1] on the mailing list. [1] http://www.openldap.org/lists/openldap-technical/201306/msg00122.html

1 0

(ITS#6970)
by breuil＠craig.fr 14 Jun '13

14 Jun '13

Hi, i'm also experiencing slapd deadlocks/lockups when using memberOf & autogroup, w/ 2.4.31. Both modules/overlays seem to step on each other's toes when updating an entry. Not 100% sure if it's the same issue as the OP was experiencing though. My config is the following : - i have a ou=people branch with inetOrgPerson objects, each one having an organization attr. - i have a ou=groups branch with groupOfNames objects, each populated by autogroup by using a labeledURI doing a filter on the organization attr (among other conditions) of the inetOrgPerson objects. - and finally, i have memberOf overlay that updates the inetOrgPerson objects with the final groups membership. When modifiying the organization attribute of an inetOrgPerson (and thus triggering an update of groups & membership at the same time), slapd deadlocks. It happens both if the inetOrgPerson gets out of a group, or is now a new member of a group (only showing the tail of the debug log, but i can provide it all): 51bb233b oc_check_required entry (uid=person,ou=people,dc=myorg,dc=fr), objectClass "inetOrgPerson" 51bb233b oc_check_allowed type "cn" 51bb233b oc_check_allowed type "structuralObjectClass" 51bb233b oc_check_allowed type "entryUUID" 51bb233b oc_check_allowed type "creatorsName" 51bb233b oc_check_allowed type "createTimestamp" 51bb233b oc_check_allowed type "objectClass" 51bb233b oc_check_allowed type "uid" 51bb233b oc_check_allowed type "givenName" 51bb233b oc_check_allowed type "sn" 51bb233b oc_check_allowed type "userPassword" 51bb233b oc_check_allowed type "title" 51bb233b oc_check_allowed type "employeeType" 51bb233b oc_check_allowed type "roomNumber" 51bb233b oc_check_allowed type "mail" 51bb233b oc_check_allowed type "telephoneNumber" 51bb233b oc_check_allowed type "memberOf" 51bb233b oc_check_allowed type "o" 51bb233b oc_check_allowed type "entryCSN" 51bb233b oc_check_allowed type "modifyTimestamp" 51bb233b oc_check_allowed type "modifiersName" 51bb233b => entry_encode(0x00000006): 51bb233b <= entry_encode(0x00000006): At that point, there are three active threads in gdb: ^C Program received signal SIGINT, Interrupt. 0x00007ffff5c67e75 in pthread_join () from /lib/x86_64-linux-gnu/libpthread.so.0 (gdb) info thread Id Target Id Frame 3 Thread 0x7ffff0f53700 (LWP 16492) 0x00007ffff5c6b2d4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 2 Thread 0x7ffff1754700 (LWP 16491) 0x00007ffff59b10d3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6 * 1 Thread 0x7ffff7ebb700 (LWP 16490) 0x00007ffff5c67e75 in pthread_join () from /lib/x86_64-linux-gnu/libpthread.so.0 thread 1 & 2 seem okay... (gdb) bt #0 0x00007ffff5c67e75 in pthread_join () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007ffff7f0fca9 in slapd_daemon () at ../../../../servers/slapd/daemon.c:2930 #2 0x00007ffff7ef687c in main (argc=<optimized out>, argv=<optimized out>) at ../../../../servers/slapd/main.c:1012 (gdb) thread 2 [Switching to thread 2 (Thread 0x7ffff1754700 (LWP 16491))] #0 0x00007ffff59b10d3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007ffff59b10d3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff7f0d721 in slapd_daemon_task (ptr=<optimized out>) at ../../../../servers/slapd/daemon.c:2540 #2 0x00007ffff5c66b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x00007ffff59b0a7d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x0000000000000000 in ?? () but thread 3 seems to lock with himself, maybe trying to modify the same entry via autogroup & memberof at the same time ? (gdb) thread 3 [Switching to thread 3 (Thread 0x7ffff0f53700 (LWP 16492))] #0 0x00007ffff5c6b2d4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 (gdb) bt #0 0x00007ffff5c6b2d4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007ffff74fe9ab in __db_pthread_mutex_lock () from /usr/lib/x86_64-linux-gnu/libdb-5.1.so #2 0x00007ffff758d5ca in __lock_get_internal () from /usr/lib/x86_64-linux-gnu/libdb-5.1.so #3 0x00007ffff758e9b3 in __lock_vec () from /usr/lib/x86_64-linux-gnu/libdb-5.1.so #4 0x00007ffff758ef18 in __lock_vec_pp () from /usr/lib/x86_64-linux-gnu/libdb-5.1.so #5 0x00007ffff32234a0 in hdb_cache_entry_db_relock (bdb=bdb@entry=0x7ffff83226a0, txn=<optimized out>, ei=0x7ffff82db7b0, rw=rw@entry=1, tryOnly=tryOnly@entry=0, lock=lock@entry=0x7ffff0f4fc70) at cache.c:198 #6 0x00007ffff3223eb3 in hdb_cache_modify (bdb=bdb@entry=0x7ffff83226a0, e=e@entry=0x7ffff85045c8, newAttrs=0x7ffff8517f48, txn=<optimized out>, lock=lock@entry=0x7ffff0f4fc70) at cache.c:1231 #7 0x00007ffff321255a in hdb_modify (op=0x7ffff0f503b0, rs=0x7ffff0f501d0) at modify.c:711 #8 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff0f503b0, rs=0x7ffff0f501d0, which=op_modify, oi=0x7ffff8325c90, on=0x0) at ../../../../servers/slapd/backover.c:671 #9 0x00007ffff7f8031b in over_op_func (op=0x7ffff0f503b0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #10 0x00007ffff29dabb9 in memberof_value_modify (op=op@entry=0x7ffff0f50d40, ndn=<optimized out>, ad=0x7ffff82d3420, old_dn=old_dn@entry=0x0, old_ndn=old_ndn@entry=0x0, new_dn=new_dn@entry=0x7ffff0f50d68, new_ndn=new_ndn@entry=0x7ffff0f50d78) at ../../../../../servers/slapd/overlays/memberof.c:411 #11 0x00007ffff29db548 in memberof_res_modify (op=0x7ffff0f50d40, rs=<optimized out>) at ../../../../../servers/slapd/overlays/memberof.c:1457 #12 0x00007ffff7f227d6 in slap_response_play (op=op@entry=0x7ffff0f50d40, rs=rs@entry=0x7ffff0f50cd0) at ../../../../servers/slapd/result.c:507 #13 0x00007ffff7f22d6e in send_ldap_response (op=op@entry=0x7ffff0f50d40, rs=rs@entry=0x7ffff0f50cd0) at ../../../../servers/slapd/result.c:582 #14 0x00007ffff7f23816 in slap_send_ldap_result (op=0x7ffff0f50d40, rs=0x7ffff0f50cd0) at ../../../../servers/slapd/result.c:860 #15 0x00007ffff3211e67 in hdb_modify (op=0x7ffff0f50d40, rs=0x7ffff0f50cd0) at modify.c:749 #16 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff0f50d40, rs=0x7ffff0f50cd0, which=op_modify, oi=0x7ffff8325c90, on=0x0) at ../../../../servers/slapd/backover.c:671 #17 0x00007ffff7f8031b in over_op_func (op=0x7ffff0f50d40, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #18 0x00007ffff2be449f in autogroup_add_member_to_group (op=op@entry=0x7ffff82d9ab0, dn=dn@entry=0x7ffff82d9ad8, ndn=ndn@entry=0x7ffff82d9ae8, age=age@entry=0x7ffff82f8ed0) at autogroup.c:146 #19 0x00007ffff2be6aa2 in autogroup_response (op=0x7ffff82d9ab0, rs=<optimized out>) at autogroup.c:1302 #20 0x00007ffff7f7f598 in over_back_response (op=0x7ffff82d9ab0, rs=0x7ffff0f52a50) at ../../../../servers/slapd/backover.c:237 #21 0x00007ffff7f227d6 in slap_response_play (op=op@entry=0x7ffff82d9ab0, rs=rs@entry=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:507 #22 0x00007ffff7f22d6e in send_ldap_response (op=op@entry=0x7ffff82d9ab0, rs=rs@entry=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:582 #23 0x00007ffff7f23816 in slap_send_ldap_result (op=0x7ffff82d9ab0, rs=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:860 #24 0x00007ffff3211e67 in hdb_modify (op=0x7ffff82d9ab0, rs=0x7ffff0f52a50) at modify.c:749 #25 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff82d9ab0, rs=0x7ffff0f52a50, which=op_modify, oi=0x7ffff8325c90, on=0x0) at ../../../../servers/slapd/backover.c:671 #26 0x00007ffff7f8031b in over_op_func (op=0x7ffff82d9ab0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #27 0x00007ffff7f2a569 in fe_op_modify (op=0x7ffff82d9ab0, rs=0x7ffff0f52a50) at ../../../../servers/slapd/modify.c:303 #28 0x00007ffff7f2c42d in do_modify (op=0x7ffff82d9ab0, rs=0x7ffff0f52a50) at ../../../../servers/slapd/modify.c:177 #29 0x00007ffff7f12961 in connection_operation (ctx=ctx@entry=0x7ffff0f52ba0, arg_v=arg_v@entry=0x7ffff82d9ab0) at ../../../../servers/slapd/connection.c:1150 #30 0x00007ffff7f12c84 in connection_read_thread (ctx=0x7ffff0f52ba0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 #31 0x00007ffff7a73ff3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #32 0x00007ffff5c66b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #33 0x00007ffff59b0a7d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #34 0x0000000000000000 in ?? () If i examine the three hdb_modify() calls in that trace, the one in #7 and the one in #24 try to work on the same entry (dummy value is the modified inetOrgPerson), and the one in #15 modifies the groupOfNames from which the inetOrgPerson is a new member. I suppose it shouldn't happen... -- Landry Breuil Mouton a 5 pattes du CRAIG

1 0

Re: (ITS#7580) autogroup module blowing slapd when using a labeledURI without attribute specification ?
by h.b.furuseth＠usit.uio.no 13 Jun '13

13 Jun '13

Pushed to master, along with the same change to autogroup_member_search_modify_cb(). -- Hallvard

1 0

Re: (ITS#7580) autogroup module blowing slapd when using a labeledURI without attribute specification ?
by breuil＠craig.fr 13 Jun '13

13 Jun '13

With help from hbf on #openldap on irc, managed to track this down to autogroup.c:autogroup_member_search_cb(). https://github.com/benegon/openldap/blob/master/contrib/slapd-modules/autog… In my usecase with labeledURI: ldap:///ou=people,dc=example,dc=org??one?(&(objectClass=inetOrgPerson)(o=myorg)) agf->agf_anlist is NULL since no attributes were specified, and the else branch is taken. In that branch, the e_name & e_nname from rs->sr_entry are assigned to lvals[0] & lnvals[0], and those two structs are local to the else branch. Later on, they assigned to vals & nvals, but when you get out of the else branch they're not in the scope anymore -> mod.sm_values & mod.sm_nvalues potentially get garbage. Declaring lvals & lnvals arrays outside of the branch (ie at the same spot as vals & nvals) fixes the assert for me, tested on debian sid with rebuilt 2.4.31 packages, but the fix should probably be the same for git master. Inline patch fixing the issue (probably mangled in the output....) diff --git a/contrib/slapd-modules/autogroup/autogroup.c b/contrib/slapd-modules/autogroup/autogroup.c index 06e1407..091a42f 100644 --- a/contrib/slapd-modules/autogroup/autogroup.c +++ b/contrib/slapd-modules/autogroup/autogroup.c @@ -331,6 +331,7 @@ autogroup_member_search_cb( Operation *op, SlapReply *rs ) const char *text = NULL; char textbuf[1024]; struct berval *vals, *nvals; + struct berval lvals[ 2 ], lnvals[ 2 ]; int numvals; Debug(LDAP_DEBUG_TRACE, "==> autogroup_member_search_cb <%s>\n", @@ -347,7 +348,6 @@ autogroup_member_search_cb( Operation *op, SlapReply *rs ) return 0; } } else { - struct berval lvals[ 2 ], lnvals[ 2 ]; lvals[ 0 ] = rs->sr_entry->e_name; BER_BVZERO( &lvals[ 1 ] ); lnvals[ 0 ] = rs->sr_entry->e_nname; -- Landry Breuil

1 0

(ITS#7624) Active Directory schema with OpenLdap
by suresh.raja＠vernal.is 13 Jun '13

13 Jun '13

Full_Name: Suresh raja Version: 2.4.35 OS: Windows Server 2008 R2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.124.116.202) I want to use my Active Directory User's, and Groups same as in OpenLDAP. Ist Possible means.. 1. Need step-by-step configuration in Windows Server 2008 R2 2. How can i modify OpenLDAP server schema with Active Directory schema 3. Can i Sync Active Directory and OpenLDAP(windows) 4. Even my AD Server was Down, the schema should be in OpenLDAP, and should be connect as locally... Thanks in Advance.. Regards, Suresh

1 0

(ITS#7623) P_SUBP page inn MDB dirty_list
by h.b.furuseth＠usit.uio.no 12 Jun '13

12 Jun '13

Full_Name: Hallvard B Furuseth Version: RE24 + mdb.master 2d0b362b6f2b1247eb693008a39efaf341f15e82 OS: Linux x86_64 URL: Submission from: (NULL) (193.69.163.163) Submitted by: hallvard test043-delta-syncrepl crashes in RE24 + mdb.master + this patch. A sub-cursor sees a regular (non-sub) page which has P_SUB set, in dirty_list. The flag comes from the fake page in cursor_put. Patch: - Set P_FAKE flag for debugging, to see where the flag comes from. - assert(not P_SUB) in page_get. - valloc pages so we can see from the page address that it is a regular page. --- libraries/liblmdb/mdb.c +++ libraries/liblmdb/mdb.c @@ -59,2 +59,3 @@ #include <unistd.h> +#include <malloc.h> @@ -582,2 +583,3 @@ typedef struct MDB_page { #define P_SUBP 0x40 /**< for #MDB_DUPSORT sub-pages */ +#define P_FAKE 0x80 /**< fake page */ /** @} */ @@ -1271,3 +1273,3 @@ mdb_page_malloc(MDB_cursor *mc, unsigned num) } - if ((ret = malloc(sz)) != NULL) { + if ((ret = valloc(sz)) != NULL) { VGMEMP_ALLOC(env, ret, sz); @@ -2478,2 +2480,3 @@ mdb_txn_commit(MDB_txn *txn) dp = txn->mt_u.dirty_list[i].mptr; + assert(!(dp->mp_flags & P_SUBP)); if (dp->mp_pgno != next) { @@ -4069,2 +4072,3 @@ mdb_page_get(MDB_txn *txn, pgno_t pgno, MDB_page **ret, int *lvl) p = dl[x].mptr; + /* assert(!(p->mp_flags & P_SUBP)); */ goto done; @@ -5164,3 +5168,3 @@ more: fp->mp_pgno = mc->mc_pg[mc->mc_top]->mp_pgno; - fp->mp_flags = P_LEAF|P_DIRTY|P_SUBP; + fp->mp_flags = P_LEAF|P_DIRTY|P_SUBP|P_FAKE; fp->mp_lower = PAGEHDRSZ; Backtrace: #4 mdb_page_get (txn=0x7f7d70104970, pgno=36, ret=0x7f7d70106e30, lvl=0x0) at ./../../../libraries/liblmdb/mdb.c:4072 p = 0x7f7d70118000 *p = {mp_p.p_pgno = 0x24, mp_pad = 0x7000, mp_flags = P_LEAF|P_DIRTY|P_SUBP|P_FAKE, mp_pb.pb = {pb_lower = 0x3c, pb_upper = 0x87e}, ...} #5 mdb_page_search (mc=0x7f7d70106de8, key=0x7f7d7b2fe6f0, flags=0) at ./../../../libraries/liblmdb/mdb.c:4264 #6 mdb_cursor_set (mc=0x7f7d70106de8, key=0x7f7d7b2fe6f0, data=0x7f7d7b2fbf80, op=MDB_SET, exactp=0x7f7d7b2fbf94) at ./../../../libraries/liblmdb/mdb.c:4690 #7 mdb_cursor_put (mc=0x7f7d70106de8, key=0x7f7d7b2fe6f0, data=0x7f7d7b2fe5a0, flags=16) at ./../../../libraries/liblmdb/mdb.c:5107 #8 mdb_cursor_put (mc=0x7f7d70106c60, key=0x7f7d7b2fe700, data=0x7f7d7b2fe6f0, flags=38) at ./../../../libraries/liblmdb/mdb.c:5413 #9 mdb_dn2id_add (op=0x7f7d7b2fec70, mcp=0x7f7d70106c60, mcd=0x7f7d70106c60, pid=1, nsubs=1, upsub=1, e=0x1109f98) at dn2id.c:141 #10 mdb_add (op=0x7f7d7b2fec70, rs=0x7f7d7b2fec00) at add.c:341 #11 overlay_op_walk (op=0x7f7d7b2fec70, rs=0x7f7d7b2fec00, which=op_add, oi=0x10bff00, on=0x0) at backover.c:671 #12 over_op_func (op=0x7f7d7b2fec70, rs, which) at backover.c:723 #13 over_op_add (op, rs) at backover.c:774 #14 accesslog_response (op, rs) at accesslog.c:1835 #15 over_back_response (op=0x7f7d700008f0, rs=0x7f7d7b300920) at backover.c:237 #16 slap_response_play (op=0x7f7d700008f0, rs=0x7f7d7b300920) at result.c:491 #17 send_ldap_response (op=0x7f7d700008f0, rs=0x7f7d7b300920) at result.c:566 #18 slap_send_ldap_result (op=0x7f7d700008f0, rs=0x7f7d7b300920) at result.c:844 #19 mdb_modify (op=0x7f7d700008f0, rs=0x7f7d7b300920) at modify.c:655 #20 overlay_op_walk (op=0x7f7d700008f0, rs=0x7f7d7b300920, which=op_modify, oi=0x10c0d50, on=0x0) at backover.c:671 #21 over_op_func (op=0x7f7d700008f0, rs, which) at backover.c:723 #22 over_op_modify (op, rs) at backover.c:762 #23 fe_op_modify (op=0x7f7d700008f0, rs=0x7f7d7b300920) at modify.c:303 #24 do_modify (op=0x7f7d700008f0, rs=0x7f7d7b300920) at modify.c:177 #25 connection_operation (ctx=0x7f7d7b300a70, arg_v=0x7f7d700008f0) at connection.c:1155 #26 connection_read_thread (ctx=0x7f7d7b300a70, argv) at connection.c:1291 #27 ldap_int_thread_pool_wrapper (xpool=0x106b320) at tpool.c:688

1 0

Fwd: RE: (ITS#7577) hdb and mdb derefere aliases differently
by hyc＠symas.com 12 Jun '13

12 Jun '13

Fix verified. -------- Original Message -------- Subject: RE: (ITS#7577) hdb and mdb derefere aliases differently Date: Wed, 12 Jun 2013 09:49:16 +0000 From: <Juergen.Sprenger(a)swisscom.com> To: <hyc(a)symas.com> I've checked with openldap-HEAD-95241fa.tar.gz, and it looks very good now. Identical results and very good performance. Looks like the cause was Gentoo ebuild. Done everything manually and no problems anymore. Juergen Sprenger -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Thursday, June 06, 2013 8:05 PM To: Sprenger Jürgen, ITS-OUS-OP-IFM-MIR-UCH Subject: Re: (ITS#7577) hdb and mdb derefere aliases differently Juergen.Sprenger(a)swisscom.com wrote: > File is transferred, name is mdb-test-juergen.tar.gz I've tested your data+config using both git master and RE24 and both give identical results for mdb and hdb. Seems something is wrong in your build. > > Juergen Sprenger > > -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: Wednesday, June 05, 2013 5:24 PM > To: Sprenger Jürgen, ITS-OUS-OP-IFM-MIR-UCH > Subject: Re: (ITS#7577) hdb and mdb derefere aliases differently > > Juergen.Sprenger(a)swisscom.com wrote: >> Please use this public key: > > OK, you should be able to ssh/scp to juergen(a)ada.openldap.org now. >> >> ssh-dss AAAAB3NzaC1kc3MAAAEBANJd7abNzD+Ejrg33Vbl8TZm6hMpI8Y02XnwfhP6CMy6w2IVjyvMsuuLp1ioJvIvgVFSCwp6lO1FnbxNTzKyhcY+f2Apo7DDQtT+faZkhPRaTwG+hht5ZsxDAEPQVuGxk9jVzLOK8D4hqTs43P5zKQLmAtqnTompWwtmNH8qfHSiNRlr6lmbMQigWfGoRqJ6rdyRulfA1tYo4yRsprM5OA0E6tzBukMPtCNerXDjI8C1M0IopTVfcbqaDsO9Q66UntAIonI5sESEfTd6v8dUTb4Z2ZcanMVZpjlqKWdr/MCYBuCXR2oiDiens92S2M3U9zLtcW1tTAO+sWdcJvqeugUAAAAVAOtW0p5t0Hme1wsKmG6DpDyqkp5rAAABAFyTRnAkwT9DM7BxyMOefJtY8rhP4RylINbJqoJ2H36OiYFoblk9G0Si1qMhKvLBceoaqswSIFOaIpe0vGWydlInGuJOEZxKCuhbYT+oDGRfOZzLU4668HHeK9aoBHoo5xFb/YWDQVi0+XoQDX+CpCcauthknISuCFcWqpALwrTqj9MRL3wan5oUOzRyiQXmyCwvRgsxt4Ee42Za+ZXnqP0wj255OOPy4btI82Njhx/fPJbUNA1uIE4TnO6tMkeGwZ2T/io4K2Wrmq0anigEfTf4WJX8og0PDajI4htcwOCrzWTHrqDtmFGRii4uSAMjigMVg6rt7b7IfoMYN7UCG7sAAAEAKDivKfQjbvgglMoz5vhZs95EOSGm7R0rItfCQjUHcGtYjDagGsLRDXQn0DXLUxBsbOkiymouNl1d5x0+DLhKg8IDz+RbGCTJ6CJnCbu7OQanXVwTWpPBAL7mjA8Z0sts6weuXXLVZpbgdh8RBS11pH1eW/CXgdL05mFexkgMQ1i5V6L+KgEl+X3KtbRTTYBh0VCUJN2hRjMRCqzXbp6yyq6s+pzcCGBKymiVds! C! > Q5MKlfAI87 > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+kLFaC5QaGex > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+QU > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+9enlA3N7W4w > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+7g > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+oqUDTaGa5Yv > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+y4 > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+jNA== > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+dsa-key-200 > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+71 > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+012 >> >> Juergen Sprenger >> >> -----Original Message----- >> From: Howard Chu [mailto:hyc@symas.com] >> Sent: Thursday, May 30, 2013 3:03 PM >> To: Sprenger Jürgen, ITS-OUS-OP-IFM-MIR-UCH >> Subject: Re: (ITS#7577) hdb and mdb derefere aliases differently >> >> Juergen.Sprenger(a)swisscom.com wrote: >>> Sorry, company mail gateway removed the attached file. >>> >>> Where can I upload the mentioned archive? >> >> Send me an SSH public key and I'll set up an account on ada.openldap.org for you. >> >>> >>> Juergen Sprenger >>> >>> -----Original Message----- >>> From: Howard Chu [mailto:hyc@symas.com] >>> Sent: Wednesday, May 29, 2013 4:22 PM >>> To: Sprenger Jürgen, ITS-OUS-OP-IFM-MIR-UCH >>> Subject: Re: (ITS#7577) hdb and mdb derefere aliases differently >>> >>> Juergen.Sprenger(a)swisscom.com wrote: >>>> The following file(s) has been removed because it violated the Swisscom security policy: >>>> >>>> ldap-hdb.sh >>>> ldap-mdb.sh >>>> >>>> >>>> Sorry, still can't get it working. >>>> >>>> Attached You will find my setup as a tarfile: >>> >>> There was no attachment on your email. >>>> >>>> mdb-test/ root/mdbtest.ldif # testdata >>>> mdb-test/ root/ldap-hdb.sh # script to switch config to hdb >>>> mdb-test/ root/ldap-mdb.sh # script to switch config to mdb >>>> >>>> mdb-test/etc/openldap/ # complete directory, but keys and certs removed >>>> mdb-test/etc/openldap/slapd.conf.hdb # slapd.conf using Berkeley DB >>>> mdb-test/etc/openldap/slapd.conf.mdb # slapd.conf using mdb >>>> >>>> mdb-test/etc/ldap.conf >>>> mdb-test/etc/ldap.conf.sudo link to >>>> mdb-test/etc/openldap/ldap.conf.sudo >>>> >>>> Juergen Sprenger >>>> >>>> -----Original Message----- >>>> From: Howard Chu [mailto:hyc@symas.com] >>>> Sent: Friday, May 17, 2013 6:24 PM >>>> To: Sprenger Jürgen, ITS-OUS-OP-IFM-MIR-UCH >>>> Subject: Re: (ITS#7577) hdb and mdb derefere aliases differently >>>> >>>> Juergen.Sprenger(a)swisscom.com wrote: >>>>> Checked out 201ddbe3e4d8eb39830b96eefa559900952bc022, compiled, installed. >>>>> >>>>> # md5sum openldap-2.4.35/servers/slapd/back-mdb/search.c >>>>> 30f4e29eb7b4d0348f0e7ef100d0ba63 >>>>> openldap-2.4.35/servers/slapd/back-mdb/search.c >>>>> >>>>> But I still get different results: >>>> >>>> OK, try once more, commit a8c1438688f74081257d2aaba4e12814b9c8668f >>>> >>>>> >>>>> ## mdb ## >>>>> # ldapsearch -xLLL -b ou=account,dc=its,dc=scom -s sub -D cn=itsAgent,ou=customerAgent,dc=scom -w ****** '(&(objectClass=posixAccount)(uid=tgdspju1))' >>>>> (result is empty) >>>>> >>>>> May 17 14:30:54 openldap-dev slapd[21001]: conn=1007 fd=13 ACCEPT >>>>> from >>>>> IP=127.0.0.1:36262 (IP=0.0.0.0:389) May 17 14:30:54 openldap-dev >>>>> slapd[21001]: conn=1007 op=0 BIND >>>>> dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 May 17 >>>>> 14:30:54 openldap-dev slapd[21001]: conn=1007 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 May 17 14:30:54 openldap-dev slapd[21001]: conn=1007 op=0 RESULT tag=97 err=0 text= May 17 14:30:54 openldap-dev slapd[21001]: conn=1007 op=1 SRCH base="ou=account,dc=its,dc=scom" scope=2 deref=3 filter="(&(objectClass=posixAccount)(uid=tgdspju1))" >>>>> May 17 14:30:57 openldap-dev slapd[21001]: conn=1007 op=1 SEARCH >>>>> RESULT tag=101 err=0 nentries=0 text= May 17 14:30:57 openldap-dev >>>>> slapd[21001]: conn=1007 op=2 UNBIND May 17 14:30:57 openldap-dev >>>>> slapd[21001]: conn=1007 fd=13 closed >>>>> >>>>> ## hdb ## >>>>> # ldapsearch -xLLL -b ou=account,dc=its,dc=scom -s sub -D cn=itsAgent,ou=customerAgent,dc=scom -w ****** '(&(objectClass=posixAccount)(uid=tgdspju1))' >>>>> dn: uid=tgdspju1,ou=Person,dc=its,dc=scom >>>>> ... >>>>> >>>>> May 17 14:33:06 openldap-dev slapd[21089]: conn=1001 fd=13 ACCEPT >>>>> from >>>>> IP=127.0.0.1:36267 (IP=0.0.0.0:389) May 17 14:33:06 openldap-dev >>>>> slapd[21089]: conn=1001 op=0 BIND >>>>> dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 May 17 >>>>> 14:33:06 openldap-dev slapd[21089]: conn=1001 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 May 17 14:33:06 openldap-dev slapd[21089]: conn=1001 op=0 RESULT tag=97 err=0 text= May 17 14:33:06 openldap-dev slapd[21089]: conn=1001 op=1 SRCH base="ou=account,dc=its,dc=scom" scope=2 deref=3 filter="(&(objectClass=posixAccount)(uid=tgdspju1))" >>>>> May 17 14:33:07 openldap-dev slapd[21089]: conn=1001 op=1 SEARCH >>>>> RESULT tag=101 err=0 nentries=1 text= May 17 14:33:07 openldap-dev >>>>> slapd[21089]: conn=1001 op=2 UNBIND May 17 14:33:07 openldap-dev >>>>> slapd[21089]: conn=1001 fd=13 closed >>>>> >>>>> Juergen Sprenger >>>>> >>>>> -----Original Message----- >>>>> From: Howard Chu [mailto:hyc@symas.com] >>>>> Sent: Friday, May 17, 2013 1:34 PM >>>>> To: Sprenger Jürgen, ITS-OUS-OP-IFM-MIR-UCH; >>>>> openldap-its(a)openldap.org >>>>> Subject: Re: (ITS#7577) hdb and mdb derefere aliases differently >>>>> >>>>> Juergen.Sprenger(a)swisscom.com wrote: >>>>>> tried the fix fb537d747c6fd43e08986e99b1fe7781660feaf3 >>>>> >>>>> There was a followup commit also needed. >>>>> 201ddbe3e4d8eb39830b96eefa559900952bc022 >>>>> >>>>> Just get the latest. >>>>> >>>> >>>> >>> >>> >> >> > > -- -- 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#7622) LMDB cursor _NEXT/_PREV
by hyc＠OpenLDAP.org 12 Jun '13

12 Jun '13

Full_Name: Howard Chu Version: 2.4.34 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc Using MDB_PREV on an initialized empty DB (that was non-empty when the cursor was initialized) returns SUCCESS when it should return NOTFOUND. Bug introduced by commit 5c1ee7f7ba9580d5ff29e74cbb02eee335c33d94 Fixed in c2cac4588a40480c020d320b544bc5f8e72adb11

1 0

(ITS#7621) LMDB mdb_stat() bug
by hyc＠OpenLDAP.org 12 Jun '13

12 Jun '13

Full_Name: Howard Chu Version: 2.4.32+ OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc In a0993354a603a970889ad5c160c289ecca316f81 txn_begin() was changed to defer reading a DB's root node until it was actually referenced, instead of always reading all DB root nodes at the beginning of a txn. Other ops already handled this case but mdb_stat() didn't, so if mdb_stat() was called for a named DB in a fresh txn that hadn't yet referenced any named DBs, it just returned zeroes in the stat structure. (The mainDB root node is always read so there was no issue there.) Fixed in bcb67dd22f06a7f7c85350bc548c50ccfc27dbaa

1 0

(ITS#7620) LMDB overflow page management
by hyc＠OpenLDAP.org 12 Jun '13

12 Jun '13

Full_Name: Howard Chu Version: 2.4.35 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc Pages that are dirtied get pulled out of the freeDB. If they are freed in the same txn they should be returned to their original place in the freeDB instead of joining the current txn's list of freed pages. This is particularly important for overflow pages because otherwise we can consume a lot of overflow pages rapidly in some cases. Commit e7f6767ea815fe0ada1f95037dfdec176ec4d5bb in mdb.master is for this issue, but it needs additional fixes.

1 0

(ITS#7619) Unable to start OpenLDAP 2.4.35 with Oracle 10g
by lokesh.kumar1＠thomsonreuters.com 11 Jun '13

11 Jun '13

Full_Name: Lokesh Kumar Version: 2.4.35 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (163.231.6.66) I am unable to start the LDAP on my linux machine with openldap-2.4.35 using back-sql with Oracle 10g as my datasource. I am able to connect to the Oracle database, but it fails to load the data on to the LDAP object schema. I am using the default sample data for Oracle RDBMS and the schema files which comes with the installable. Can you please look into this and let me know if I am missing something here? My sladp.config file looks like this: include <InstallFolder>/etc/openldap/schema/core.schema include <InstallFolder>/etc/openldap/schema/cosine.schema include <InstallFolder>/etc/openldap/schema/inetorgperson.schema pidfile <InstallFolder>/var/run/slapd.pid argsfile <InstallFolder>/var/run/slapd.args database sql suffix "dc=example,dc=com" rootdn "cn=root,dc=example,dc=com" rootpw secret dbname OracleODBC-10g dbuser username dbpasswd password subtree_cond "UPPER(ldap_entries.dn) LIKE CONCAT('%',UPPER(?))" insentry_stmt "INSERT INTO ldap_entries (id,dn,oc_map_id,parent,keyval) VALUES (ldap_entry_ids.nextval,?,?,?,?)" upper_func UPPER has_ldapinfo_dn_ru no The startup console output looks something like this: . . . 51b70f81 backsql_load_schema_map(): oc_query "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings" 51b70f81 objectClass: id="1" name="inetOrgPerson" keytbl="persons" keycol="id" create_proc="call create_person(?)" create_keyval="" delete_proc="call delete_person(?)" expect_return="0"create_hint="" 51b70f81 backsql_load_schema_map(): objectClass "inetOrgPerson": keytbl="persons" keycol="id" 51b70f81 create_proc="call create_person(?)" 51b70f81 delete_proc="call delete_person(?)" 51b70f81 expect_return: add=0, del=0; attributes: 51b70f81 objectClass: id="2" name="document" keytbl="documents" keycol="id" create_proc="call create_document(?)" create_keyval="" delete_proc="call delete_document(?)" expect_return="0"create_hint="" 51b70f81 backsql_load_schema_map(): objectClass "document": keytbl="documents" keycol="id" 51b70f81 create_proc="call create_document(?)" 51b70f81 delete_proc="call delete_document(?)" 51b70f81 expect_return: add=0, del=0; attributes: 51b70f81 objectClass: id="3" name="organization" keytbl="institutes" keycol="id" create_proc="call create_org(?)" create_keyval="" delete_proc="call delete_org(?)" expect_return="0"create_hint="" 51b70f81 backsql_load_schema_map(): objectClass "organization": keytbl="institutes" keycol="id" 51b70f81 create_proc="call create_org(?)" 51b70f81 delete_proc="call delete_org(?)" 51b70f81 expect_return: add=0, del=0; attributes: 51b70f81 backsql_load_schema_map(): at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" 51b70f81 backsql_oc_get_attr_mapping(): executing at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "document" with param oc_id=2 51b70f81 backsql_oc_get_attr_mapping(): error executing at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "document" with param oc_id=2 51b70f81 Return code: -1 51b70f81 <==backsql_load_schema_map() 51b70f81 backsql_db_open(): schema mapping failed, exiting 51b70f81 backend_startup_one (type=sql, suffix="dc=example,dc=com"): bi_db_open failed! (1) 51b70f81 slapd shutdown: initiated . . .

1 0

Re: (ITS#7618) pcache overlay does not allow the use of NOT ("!") in templates
by hyc＠symas.com 10 Jun '13

10 Jun '13

amoneger(a)cisco.com wrote: > Full_Name: Alex Moneger > Version: 2.4.35 > OS: centos 6.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.103.25.102) > > > Hi, > > When trying to define a template which query contains a '!', slapd complains > about a syntax issue in the config file and refuses to start. This is by design. Read the Proxy Cache design paper. http://www.openldap.org/pub/ -- -- 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#7618) pcache overlay does not allow the use of NOT ("!") in templates
by amoneger＠cisco.com 10 Jun '13

10 Jun '13

Full_Name: Alex Moneger Version: 2.4.35 OS: centos 6.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.103.25.102) Hi, When trying to define a template which query contains a '!', slapd complains about a syntax issue in the config file and refuses to start. This is because there seems to be a missing check for '!' in template_attrs() in pcache.c, so '!' char is passed to slap_bv2ad() which correctly errors out. i.e: May 27 20:53:53 centos63 slapd[44623]: line 71 (pcacheTemplate (&(gidNumber=)(objectClass=)(cn=*)(&(gidNumber=*)(!(gidNumber=)))) 0 3600) May 27 20:53:53 centos63 slapd[44623]: /etc/openldap/pcache.conf: line 71: unable to parse template: AttributeDescription contains inappropriate characters. I believe the use of "not" should be allowed in cacheable templates, since they appear to be a valid search filter definition as per RFC 2254. The fix is very easy. I cannot upload the diff to the ftp server, since it errors with space related errors when uploading the file. Content of the diff: --- openldap-2.4.35/servers/slapd/overlays/pcache.c 2013-03-28 15:41:51.000000000 +0000 +++ openldap-2.4.35/servers/slapd/overlays/pcache.c0 2013-05-27 21:27:20.847919253 +0100 @@ -523,7 +523,7 @@ allop = an_find( attrs, slap_bv_all_operational_attrs ); for (;;) { - while ( *p1 == '(' || *p1 == '&' || *p1 == '|' || *p1 == ')' ) p1++; + while ( *p1 == '(' || *p1 == '&' || *p1 == '|' || *p1 == ')' || *p1 == '!') p1++; p2 = strchr( p1, '=' ); if ( !p2 ) break; It can be applied this way if you consider this of any use: cd "${HOME}"/openldap-2.4.35 patch -p0 --verbose < ~/pcache.p0 Cheers, Alex

1 0

RE: (ITS#7617) Stack issue Openldap!ldap_unbind_s
by quanah＠zimbra.com 07 Jun '13

07 Jun '13

--On Friday, June 07, 2013 8:34 AM +0000 lily.zhang(a)emc.com wrote: > Hi > > Thank you for looking at it. > > A dump is generated when user login via LDAP account. > [w:\thirdparty\openldap-2.4.16\libraries\libldap\tls_o.c @ 793] 1fd5c238 OpenLDAP 2.4.16 is years old. Please confirm you see the issue using a current release. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#7617) Stack issue Openldap!ldap_unbind_s
by lily.zhang＠emc.com 07 Jun '13

07 Jun '13

Hi Thank you for looking at it. A dump is generated when user login via LDAP account. 1. This is the code call in my code: NAVsint32 status = ldap_unbind_s( _ldapHandle ); 2. Below is the call stack and the content of _ldapHandle(dap 0x1b4b3d58). From the call stack, it seems call stack corrupts in function call ldap_unbind_s(). 3. Issue can be solved by restarting the process, but issue can reproduced once in while in the user's environment. 4. Please let me if you need other material about this issue. 0:112:x86> kb *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 1fd5c19c 0cb83b74 12ad21c8 1b291110 0cb839e8 0x56414e24 1fd5c1a8 0cb839e8 23fb4c18 23fa62f0 0cd41433 SecurityProvider!ri_cert_ctx_free+0x30 1fd5c1b4 0cd41433 1b291110 0cd4e533 1b291110 SecurityProvider!ri_cert_free+0x6d 1fd5c1bc 0cd4e533 1b291110 4173e2a8 00000000 Openldap!R_CERT_free+0x19 1fd5c1d0 0cd41a41 23fa62f0 4173e1d8 4173e1d8 Openldap!R_SSL_SESSION_free+0x9a 1fd5c1e8 0cd35e32 4173e1d8 0000002f 4173e1d8 Openldap!R_SSL_free+0x11e 1fd5c214 0cd265a7 00000168 4aaaf310 1fd5c238 Openldap!SSL_free+0xe2 1fd5c224 0cd2eefe 390c45b0 390b7c18 390c45b0 Openldap!tlso_sb_remove+0x57 [w:\thirdparty\openldap-2.4.16\libraries\libldap\tls_o.c @ 793] 1fd5c238 0cd2f3e6 390b7c10 0cdc8b04 00000014 Openldap!ber_sockbuf_remove_io+0x9e [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 230] 1fd5c250 0cd2eb03 390b7c10 1fd5c280 0cd272a8 Openldap!ber_int_sb_destroy+0x76 [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 405] 1fd5c25c 0cd272a8 390b7c10 74834c39 00000000 Openldap!ber_sockbuf_free+0x53 [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 75] 1fd5c280 0cd26f41 1b4b3d58 00000001 00000000 Openldap!ldap_ld_free+0x2f8 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 195] 1fd5c29c 0cd272e0 1b4b3d58 00000000 00000000 Openldap!ldap_unbind_ext+0x71 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 52] 1fd5c2b0 0cb019fe 1b4b3d58 1fd5c35c 48d8e868 Openldap!ldap_unbind_s+0x10 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 213] 1fd5c2c4 0cafd615 eedd5f4e 1fd5c35c 1fd5c4ec SecurityProvider!ecom::caprovider::OpenLDAPLogin::_disconnect+0x1e [z:\naviservices\providers\securityprovider\commonauthenticationprovider\openldaplogin.cpp @ 1344] 1fd5c2e0 0caf98dd eedd5956 1fd5c324 1fd5c324 SecurityProvider!ecom::caprovider::OpenLDAPLogin::~OpenLDAPLogin+0x35 [z:\naviservices\providers\securityprovider\commonauthenticationprovider\openldaplogin.cpp @ 198] 1fd5c4f8 0cada203 1fd5c63c 1fd5c64c 1fd5c5d4 SecurityProvider!ecom::caprovider::OpenLDAPAuthLoginContext::login+0x37d [z:\naviservices\providers\securityprovider\commonauthenticationprovider\openldapauthlogincontext.cpp @ 159] 1fd5c604 0cabd419 1fd5c63c 1fd5c64c 1fd5c724 SecurityProvider!ecom::caprovider::NaviCA_LDAPFeature::AuthenticateUser+0x203 [z:\naviservices\providers\securityprovider\commonauthenticationprovider\generated\mynavica_ldapfeature.cpp @ 1415] 1fd5c634 0ca668db 4aab2ba0 00000006 00000007 SecurityProvider!NaviSec_SecurityAdmin::AuthenticateCAUser+0x69 [z:\naviservices\providers\securityprovider\generated\navisec_securityadminmethods.cpp @ 4211] 1fd5c734 0ca63e3b 1fd5c85c 4aab2ba0 00000006 SecurityProvider!NaviSec_Authentication::CanUserAccess+0x1bb [z:\naviservices\providers\securityprovider\generated\navisec_authenticationmethods.cpp @ 154] 0:112:x86> dt -r8 ldap 0x1b4b3d58 Openldap!ldap +0x000 ld_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x000 sbi_setup : 0x0cd2f700 int Openldap!sb_stream_setup+0 +0x004 sbi_remove : (null) +0x008 sbi_ctrl : 0x0cd2f740 int Openldap!sb_stream_ctrl+0 +0x00c sbi_read : 0x0cd2f5b0 long Openldap!sb_stream_read+0 +0x010 sbi_write : 0x0cd2f620 long Openldap!sb_stream_write+0 +0x014 sbi_close : 0x0cd2f690 int Openldap!sb_stream_close+0 +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab2c30 +0x010 sbiod_next : (null) +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x000 sbi_setup : 0x0cd2f700 int Openldap!sb_stream_setup+0 +0x004 sbi_remove : (null) +0x008 sbi_ctrl : 0x0cd2f740 int Openldap!sb_stream_ctrl+0 +0x00c sbi_read : 0x0cd2f5b0 long Openldap!sb_stream_read+0 +0x010 sbi_write : 0x0cd2f620 long Openldap!sb_stream_write+0 +0x014 sbi_close : 0x0cd2f690 int Openldap!sb_stream_close+0 +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x00c sbiod_pvt : 0x4aab2c30 +0x010 sbiod_next : (null) +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x000 sbi_setup : 0x0cd2f700 int Openldap!sb_stream_setup+0 +0x004 sbi_remove : (null) +0x008 sbi_ctrl : 0x0cd2f740 int Openldap!sb_stream_ctrl+0 +0x00c sbi_read : 0x0cd2f5b0 long Openldap!sb_stream_read+0 +0x010 sbi_write : 0x0cd2f620 long Openldap!sb_stream_write+0 +0x014 sbi_close : 0x0cd2f690 int Openldap!sb_stream_close+0 +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab2c30 +0x010 sbiod_next : (null) +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x004 ld_options : ldapoptions +0x000 ldo_valid : 2 +0x004 ldo_debug : 0 +0x008 ldo_tm_api : timeval +0x000 tv_sec : -1 +0x004 tv_usec : 0 +0x010 ldo_tm_net : timeval +0x000 tv_sec : 30 +0x004 tv_usec : 0 +0x018 ldo_version : 3 +0x01c ldo_deref : 0 +0x020 ldo_timelimit : 0 +0x024 ldo_sizelimit : 0 +0x028 ldo_tls_ctx : (null) +0x02c ldo_tls_connect_cb : (null) +0x030 ldo_tls_connect_arg : (null) +0x034 ldo_tls_info : ldaptls +0x000 lt_certfile : (null) +0x004 lt_keyfile : (null) +0x008 lt_dhfile : (null) +0x00c lt_cacertfile : (null) +0x010 lt_cacertdir : (null) +0x014 lt_ciphersuite : (null) +0x018 lt_crlfile : (null) +0x01c lt_randfile : (null) +0x020 lt_protocol_min : 0 +0x058 ldo_tls_mode : 0 +0x05c ldo_tls_require_cert : 0 +0x060 ldo_tls_impl : 0 +0x064 ldo_tls_crlcheck : 0 +0x068 ldo_defludp : (null) +0x06c ldo_defport : 389 +0x070 ldo_defbase : (null) +0x074 ldo_defbinddn : (null) +0x078 ldo_def_sasl_mech : (null) +0x07c ldo_def_sasl_realm : (null) +0x080 ldo_def_sasl_authcid : (null) +0x084 ldo_def_sasl_authzid : (null) +0x088 ldo_sasl_secprops : sasl_security_properties +0x000 min_ssf : 0 +0x004 max_ssf : 0x7fffffff +0x008 maxbufsize : 0xffffff +0x00c security_flags : 0x11 +0x010 property_names : (null) +0x014 property_values : (null) +0x0a0 ldo_refhoplimit : 5 +0x0a4 ldo_sctrls : (null) +0x0a8 ldo_cctrls : (null) +0x0ac ldo_rebind_proc : (null) +0x0b0 ldo_rebind_params : (null) +0x0b4 ldo_nextref_proc : (null) +0x0b8 ldo_nextref_params : (null) +0x0bc ldo_urllist_proc : (null) +0x0c0 ldo_urllist_params : (null) +0x0c4 ldo_conn_cbs : (null) +0x0c8 ldo_booleans : 0 +0x0d0 ld_lberoptions : 1 +0x0d4 ld_errno : 0 +0x0d8 ld_error : (null) +0x0dc ld_matched : (null) +0x0e0 ld_referrals : (null) +0x0e4 ld_msgid : 4 +0x0e8 ld_requests : (null) +0x0ec ld_responses : (null) +0x0f0 ld_nabandoned : 0 +0x0f4 ld_abandoned : (null) +0x0f8 ld_cache : (null) +0x0fc ld_defconn : (null) +0x100 ld_conns : (null) +0x104 ld_selectinfo : (null) -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] Sent: 2013$BG/(B6$B7n(B7$BF|(B 16:19 To: Zhang, Lily (USD) Subject: Re: (ITS#7617) Stack issue Openldap!ldap_unbind_s *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#7617. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#7617) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#7617) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=7617 Please remember to retain your issue tracking number (ITS#7617) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

(ITS#7617) Stack issue Openldap!ldap_unbind_s
by lily.zhang＠emc.com 07 Jun '13

07 Jun '13

Full_Name: Zhang, Lily Version: 2.4.16 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (168.159.144.57) Here is the code we call ldap_unbind_s(). void OpenLDAPLogin::_disconnect() { if (_ldapHandle == NULL) { return; } // ldap_unbind_s will free up the space // allocated for the LDAP handle NAVsint32 status = ldap_unbind_s( _ldapHandle ); if (status != LDAP_SUCCESS) { return; } _ldapHandle = NULL; } Here is the call stack, eip become an invalid pointer. If the process was restarted, issue was disappeared, but it may be reproduced sometimes later. Please help me have a look that whether is a bug that fixed in the latest version. *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 1fd5c19c 0cb83b74 12ad21c8 1b291110 0cb839e8 0x56414e24 1fd5c1a8 0cb839e8 23fb4c18 23fa62f0 0cd41433 SecurityProvider!ri_cert_ctx_free+0x30 1fd5c1b4 0cd41433 1b291110 0cd4e533 1b291110 SecurityProvider!ri_cert_free+0x6d 1fd5c1bc 0cd4e533 1b291110 4173e2a8 00000000 Openldap!R_CERT_free+0x19 1fd5c1d0 0cd41a41 23fa62f0 4173e1d8 4173e1d8 Openldap!R_SSL_SESSION_free+0x9a 1fd5c1e8 0cd35e32 4173e1d8 0000002f 4173e1d8 Openldap!R_SSL_free+0x11e 1fd5c214 0cd265a7 00000168 4aaaf310 1fd5c238 Openldap!SSL_free+0xe2 1fd5c224 0cd2eefe 390c45b0 390b7c18 390c45b0 Openldap!tlso_sb_remove+0x57 [w:\thirdparty\openldap-2.4.16\libraries\libldap\tls_o.c @ 793] 1fd5c238 0cd2f3e6 390b7c10 0cdc8b04 00000014 Openldap!ber_sockbuf_remove_io+0x9e [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 230] 1fd5c250 0cd2eb03 390b7c10 1fd5c280 0cd272a8 Openldap!ber_int_sb_destroy+0x76 [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 405] 1fd5c25c 0cd272a8 390b7c10 74834c39 00000000 Openldap!ber_sockbuf_free+0x53 [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 75] 1fd5c280 0cd26f41 1b4b3d58 00000001 00000000 Openldap!ldap_ld_free+0x2f8 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 195] 1fd5c29c 0cd272e0 1b4b3d58 00000000 00000000 Openldap!ldap_unbind_ext+0x71 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 52] 1fd5c2b0 0cb019fe 1b4b3d58 1fd5c35c 48d8e868 Openldap!ldap_unbind_s+0x10 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 213]

1 0

Re: (ITS#7594) incomplete MDB subdb cursor cleanup
by hyc＠symas.com 05 Jun '13

05 Jun '13

h.b.furuseth(a)usit.uio.no wrote: > Howard Chu writes: >> h.b.furuseth(a)usit.uio.no wrote: >>> If a cursor is at a clean subDB page, and its current item is deleted >>> by another cursor, then MDB_GET_CURRENT returns the deleted item. >> >> Fixed now in mdb.master. The subcursor on the clean page will be invalidated >> when the page is touched. > > MDB_NEXT/MDB_PREV crash on assert(mc->mc_flags & C_INITIALIZED) > since commit e31c7d3b31d8d5073195e31b283e8ccb46bd13cf, with the > patch below to the test program. OK, I've reverted that commit. > mdb.master output with patched test program: > > With clean page: > Name: Key -> Data (mv_data[mv_len]): > m2: a[2] -> x[2] > mc/del: a[2] -> [0] > a.out: mdb.c:4386: mdb_cursor_next: Assertion `mc->mc_flags & 0x01' failed. No longer asserts. Also, [0] was the wrong result here. Also fixed. > Branch mdb/its7594 output: > > With clean page: > Name: Key -> Data (mv_data[mv_len]): > m2: a[2] -> x[2] > mc/del: a[2] -> [0] > its7594a.c:48: mdb_cursor_get(m2, &key, &data, MDB_NEXT): MDB_BAD_CURSOR: Cursor is unusable > > That assert is OK since it's the test program asserting success. > > --- its7594.c > +++ its7594a.c > @@ -28,4 +28,6 @@ > E(mdb_cursor_put(mc, STR2VAL("a"), STR2VAL("x"), 0)); > E(mdb_cursor_put(mc, STR2VAL("a"), STR2VAL("y"), 0)); > + E(mdb_cursor_put(mc, STR2VAL("b"), STR2VAL("z"), 0)); > + E(mdb_cursor_put(mc, STR2VAL("c"), STR2VAL("w"), 0)); > > if (argc < 2) { > @@ -42,8 +44,8 @@ > > E(mdb_cursor_del(mc, 0)); > - E(mdb_cursor_get(m2, &key, &data, MDB_GET_CURRENT)); > - SHOW("m2/del"); /* Should output the same as... */ > - E(mdb_cursor_get(mc, &key, &data, MDB_GET_CURRENT)); > - SHOW("mc/del"); /* ...this: "a[2] -> [0]". */ > + E(mdb_cursor_get(mc, &key, &data, MDB_NEXT)); > + SHOW("mc/del"); /* Outputs "a[2] -> [0]"... */ > + E(mdb_cursor_get(m2, &key, &data, MDB_NEXT)); > + SHOW("m2/del"); /* ...and this should output the same. */ > > mdb_txn_abort(txn); > -- -- 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#7616) syncrepl enhancement: defer requests when refreshing
by hyc＠symas.com 05 Jun '13

05 Jun '13

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. Agreed. > Just a question: Is this database-specific? Maybe only one of several DBs is > in this initial syncrepl phase and access to others should simply work. Overlays are db-specific. -- -- 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#7616) syncrepl enhancement: defer requests when refreshing
by michael＠stroeder.com 05 Jun '13

05 Jun '13

This is a cryptographically signed message in MIME format. --------------ms020809020606000104080607 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > I was considering returning LDAP_BUSY for this case, but it may make mo= re=20 > sense to return a REFERRAL to the provider instead. (Although again, if= we=20 > have two MMR servers pointed at each other starting at the same time, t= hey=20 > would just refer to each other and clients would get nowhere until one = of them=20 > finishes its refresh.) IMO referrals are harmful. Just returning LDAP_BUSY seems best to me because if reliable HA is reall= y important for a deployment you have decent load-balancers in front of you= r LDAP server which should do a proper health-check. Just a question: Is this database-specific? Maybe only one of several DBs= is in this initial syncrepl phase and access to others should simply work. Ciao, Michael. --------------ms020809020606000104080607 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 KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjA1MTgxNDAzWjAj BgkqhkiG9w0BCQQxFgQUiEZEhMlpWaio/7q/OgE6XehCSTswbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEA0dEsxfOK4N2Ee5bXv8bgeDj+DFV5pK4X YH8lJkCSkq9qberav4nqRGq7Ka50HZuIzMmWj2t6JR4Y/gIJfCZpSJ6fGtEMKXmuFmT9Kj8l IwlvnmoVyMnrQYVLXz/pnl1AG7vj0n00eYIe2ZlYYT2mVDT9RwBXe5T1UZoOvRmm4fy6AgSU wlNIuyClUgk/5z4jsYb8bf+abz2MWKwNA3Pv3mwB/pTUMdB90WmgfnKI1u0G5aBIsidLd7Ec aVMirzK3Ur7fNSj59/lQdnZixG2p37F+1ZkFXwtAFub5d01osWoCVePJJF16DUzJVgzZBv3Q wtcP0eJdkAwf3tBY4mkfJgAAAAAAAA== --------------ms020809020606000104080607--

1 0

Re: (ITS#7616) syncrepl enhancement: defer requests when refreshing
by hyc＠symas.com 05 Jun '13

05 Jun '13

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: 2.4.35 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (78.155.233.73) > Submitted by: hyc > > > We've discussed this on -devel a few times in the past. Sometimes it would be > desirable to prevent a consumer from answering client requests if it has just > started up and needs to perform an lengthy refresh. > > In prior discussions, there was a concern that in an MMR situation, two servers > coming up at the same time would deadlock waiting for each other. We can avoid > this problem by allowing any search request with a Sync control to proceed as > normal. Or, any search request with a Sync control and a non-empty, valid > cookie. > > Implementation can be done using an overlay hook. Note that syncrepl already > installs an overlay hook now for delta-mmr, this would just expand the scope of > that internal overlay. 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.) -- -- 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#7616) syncrepl enhancement: defer requests when refreshing
by hyc＠OpenLDAP.org 05 Jun '13

05 Jun '13

Full_Name: Howard Chu Version: 2.4.35 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc We've discussed this on -devel a few times in the past. Sometimes it would be desirable to prevent a consumer from answering client requests if it has just started up and needs to perform an lengthy refresh. In prior discussions, there was a concern that in an MMR situation, two servers coming up at the same time would deadlock waiting for each other. We can avoid this problem by allowing any search request with a Sync control to proceed as normal. Or, any search request with a Sync control and a non-empty, valid cookie. Implementation can be done using an overlay hook. Note that syncrepl already installs an overlay hook now for delta-mmr, this would just expand the scope of that internal overlay.

1 0

Re: (ITS#7614) Markup error in slapd.conf.5
by hyc＠symas.com 04 Jun '13

04 Jun '13

Eric S. Raymond wrote: > You have drastically misunderstood what you saw. This isn't an error > in doclifter, it's a result of a basic ontological mismatch between > the source and target markups that doclifter tries to bridge across. > > There are no line breaks in DocBook's XML, structure-oriented world. > The closest thing to one ia special-purpose <sbr/> tag that is only valid > inside command synoposes. Thus there is no "line break" equivalent > that .br can be mapped to. Nor should there be; that is fundamentally > a presentation-level concept. > > Thus, one of either ignoring the .br or interpreting it as a paragraph > boundary is exactly what doclifter *should* be doing. This is not a > bug, it is correct behavior because those are the only alternatives > XML-DocBook supports. This is absolutely ludicrous. This is like saying "my language processor doesn't support the Addition operator, it only supports multiplcation or division. So when you write 'x+y' in your input a result of either 'x*y' or 'x/y' is *exactly* what it should be doing." The fact that your document language or tool only supports two alternatives doesn't make either one of them correct. If you hadn't caused me to waste this much time on this issue already it would be laughable. -- -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2013