openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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

16 Jun '13

I wrote: >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. Found by test043 + assert(the patches were equivalent). -- Hallvard

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs