openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

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

17 Jun '13

Howard Chu writes: > The flag is being propagated when the page grows and turns into a real page. > Fixed by this simple patch. > (...) > mp->mp_flags = fp->mp_flags | P_DIRTY; > + mp->mp_flags &= ~(P_SUBP|P_FAKE); > mp->mp_pad = fp->mp_pad; This fixes test043, but breaks test046-dds: ldapexop exits with 49 (invalidCredentials) for "Refreshing the meeting as $BJORNSDN...". It passes without the patch. This is RE24 (4dc62839c2324b46bfd6) or RE24 + mdb.master (60086c1bc77fafecef27). Ignoring 2nd patch, it did did not fix test043: ldapadd fails (32) when populating provider. -- Hallvard

1 0

Re: (ITS#7626) [Patch] Fix config_build_schema_inc
by jsynacek＠redhat.com 17 Jun '13

17 Jun '13

On 06/17/2013 02:41 PM, Howard Chu wrote: > jsynacek(a)redhat.com wrote: >> Full_Name: Jan Synacek >> Version: master >> OS: Linux - Fedora 18 >> URL: >> http://jsynacek.fedorapeople.org/openldap/0001-Fix-config_build_schema_inc.… >> Submission from: (NULL) (209.132.186.34) >> >> >> When converting a slapd.conf into the DIT configuration, slaptest incorrectly >> handles 'include' directives containing a custom file instead of a schema file. >> >> Example: >> custom.file: >> include /etc/ldap/schema/cosine.ldif >> >> slapd.conf >> ... >> include /path/to/custom.file >> ... >> >> Slaptest does not properly include cosine.ldif into the new configuration. > > Your example is invalid since slapd.conf format doesn't support including LDIF > files. > Sorry, I meant "schema" instead of "ldif". s/cosine.ldif/cosine.schema

1 0

Re: (ITS#7626) [Patch] Fix config_build_schema_inc
by hyc＠symas.com 17 Jun '13

17 Jun '13

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: Linux - Fedora 18 > URL: http://jsynacek.fedorapeople.org/openldap/0001-Fix-config_build_schema_inc.… > Submission from: (NULL) (209.132.186.34) > > > When converting a slapd.conf into the DIT configuration, slaptest incorrectly > handles 'include' directives containing a custom file instead of a schema file. > > Example: > custom.file: > include /etc/ldap/schema/cosine.ldif > > slapd.conf > ... > include /path/to/custom.file > ... > > Slaptest does not properly include cosine.ldif into the new configuration. Your example is invalid since slapd.conf format doesn't support including LDIF files. -- -- 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#7626) [Patch] Fix config_build_schema_inc
by jsynacek＠redhat.com 17 Jun '13

17 Jun '13

Full_Name: Jan Synacek Version: master OS: Linux - Fedora 18 URL: http://jsynacek.fedorapeople.org/openldap/0001-Fix-config_build_schema_inc.… Submission from: (NULL) (209.132.186.34) When converting a slapd.conf into the DIT configuration, slaptest incorrectly handles 'include' directives containing a custom file instead of a schema file. Example: custom.file: include /etc/ldap/schema/cosine.ldif slapd.conf ... include /path/to/custom.file ... Slaptest does not properly include cosine.ldif into the new configuration.

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

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

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