openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#7609) back-meta enhancement: filter patterns for target selection
by hyc＠OpenLDAP.org 26 May '13

26 May '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 Since a lot of applications perform DN lookups using a search filter, it would be useful to allow specifying a regex pattern match on filters to select a target. This would avoid broadcasting a suffix-level search to all targets unnecessarily. The intended use case is for a system where the DIT is sharded across multiple servers, and entries are distributed across each target using some regular pattern. (e.g., uid=a.* on target1, uid=b.* on target2, etc...)

1 0

Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by ck＠cksoft.de 26 May '13

26 May '13

Hi, Summary: it seems having a modifiersdn outside of cn=config in cn=config breaks replication once slapd is restarted. I have a more elaborate test setup with four servers. Two masters ldaptest1, ldaptest2 using syncrepl in mirrormode . Two slaves ldaptest3, ldaptest4 that use syncrepl to slave from the masters. The masters and the slaves also replicate cn=config between themselves. Replication config is as follows: on ldaptest1 and ldaptest2: dn: cn=config ... olcServerID: 1 ldap://ldaptest1.cksoft.de olcServerID: 2 ldap://ldaptest2.cksoft.de olcServerID: 3 ldap://ldaptest3.cksoft.de olcServerID: 4 ldap://ldaptest4.cksoft.de dn: olcDatabase={1}mdb,cn=config ... olcSyncrepl: rid=001 provider=ldap://ldaptest1.cksoft.de bindmethod=simple binddn="cn=replica,ou=system,dc=test" credentials="secret" keepalive=0:0:0 starttls=yes tls_cert="/usr/local/etc/openldap/certs/server.cert" tls_key="/usr/local/etc/openldap/certs/server.key" tls_cacert="/usr/local/etc/openldap/certs/cksoftware-gmbh-ca-2011-2031.cert" tls_reqcert=demand tls_crlcheck=none filter="(objectclass=*)" searchbase="dc=test" scope=sub type=refreshAndPersist retry="60 10 300 +" olcSyncrepl: rid=002 provider=ldap://ldaptest2.cksoft.de bindmethod=simple binddn="cn=replica,ou=system,dc=test" credentials="secret" keepalive=0:0:0 starttls=yes tls_cert="/usr/local/etc/openldap/certs/server.cert" tls_key="/usr/local/etc/openldap/certs/server.key" tls_cacert="/usr/local/etc/openldap/certs/cksoftware-gmbh-ca-2011-2031.cert" tls_reqcert=demand tls_crlcheck=none filter="(objectclass=*)" searchbase="dc=test" scope=sub type=refreshAndPersist retry="60 10 300 +" olcMirrorMode: TRUE on ldaptest3 and ldaptest4: dn: cn=config ... olcServerID: 1 ldap://ldaptest1.cksoft.de olcServerID: 2 ldap://ldaptest2.cksoft.de olcServerID: 3 ldap://ldaptest3.cksoft.de olcServerID: 4 ldap://ldaptest4.cksoft.de dn: olcDatabase={1}mdb,cn=config ... olcSyncrepl: rid=001 provider=ldap://ldaptest1.cksoft.de bindmethod=simple binddn="cn=replica,ou=system,dc=test" credentials="secret" keepalive=0:0:0 starttls=yes tls_cert="/usr/local/etc/openldap/certs/server.cert" tls_key="/usr/local/etc/openldap/certs/server.key" tls_cacert="/usr/local/etc/openldap/certs/cksoftware-gmbh-ca-2011-2031.cert" tls_reqcert=demand tls_crlcheck=none filter="(objectclass=*)" searchbase="dc=test" scope=sub type=refreshAndPersist retry="60 10 300 +" olcSyncrepl: rid=002 provider=ldap://ldaptest2.cksoft.de bindmethod=simple binddn="cn=replica,ou=system,dc=test" credentials="secret" keepalive=0:0:0 starttls=yes tls_cert="/usr/local/etc/openldap/certs/server.cert" tls_key="/usr/local/etc/openldap/certs/server.key" tls_cacert="/usr/local/etc/openldap/certs/cksoftware-gmbh-ca-2011-2031.cert" tls_reqcert=demand tls_crlcheck=none filter="(objectclass=*)" searchbase="dc=test" scope=sub type=refreshAndPersist retry="60 10 300 +" olcMirrorMode: FALSE Once I modify something trivial like olcLogLevel on the slaves using my personal dn, cn=config will have following operational attributes: # config dn: cn=config structuralObjectClass: olcGlobal entryUUID: dc78e00a-461a-1032-9454-cd151c72b364 creatorsName: cn=config createTimestamp: 20130430194949Z entryCSN: 20130526075059.867187Z#000000#004#000000 modifiersName: uid=ckratzer,ou=people,dc=test modifyTimestamp: 20130526075059Z contextCSN: 20130526074631.636527Z#000000#003#000000 contextCSN: 20130526075059.867187Z#000000#004#000000 entryDN: cn=config subschemaSubentry: cn=Subschema I then restart slapd on the first slave ldaptest3 and leave it running on ldaptest4. A change replicated from the masters will appear on ldaptest4 just fine. The restarted master on ldaptest3 fails to apply the change May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_message_to_entry: rid=001 DN: cn=test,dc=test, UUID: 3e48a550-4dd1-1032-9f9f-47169a206073 May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=001 inserted UUID 3e48a550-4dd1-1032-9f9f-47169a206073 May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=001 be_search (0) May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=001 cn=test,dc=test May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=001 entry unchanged, ignored (cn=test,dc=test,) May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_updateCookie: rid=001 be_modify failed (17) May 26 10:06:13 ldaptest3 slapd[2410]: do_syncrepl: rid=001 rc 17 retrying May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_message_to_entry: rid=002 DN: cn=test,dc=test, UUID: 3e48a550-4dd1-1032-9f9f-47169a206073 May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=002 inserted UUID 3e48a550-4dd1-1032-9f9f-47169a206073 May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=002 be_search (0) May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=002 cn=test,dc=test, May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=002 entry unchanged, ignored (cn=test,dc=test,) May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_updateCookie: rid=002 be_modify failed (17) May 26 10:06:13 ldaptest3 slapd[2410]: do_syncrepl: rid=002 rc 17 retrying I currently have customer data in above test setup so I had to do some obfuscation in above samples and logs. If required I can setup maximally stripped down case that illustrates the problem. Would it be possible to mask modifiersName inside cn=config to either a fixed value just append something like cn=proxied,cn=config to dns outside of cn=config. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

1 0

Re: (ITS#7607) Assertion triggers during many sequential transaction commits
by hyc＠symas.com 24 May '13

24 May '13

Howard Chu wrote: > éÌØÑ ìÕËØÑÎÏ× wrote: >> What can i do to help investigating this issue? >> I'm not very familliar with lmdb sources so any suggestions on where to look >> would be appreciated! > > I've installed a Win7 x64 VM here and compiled with gcc 4.8.0 and it works fine. > I've also installed Visual Studio 2012 Express and compiled with that, it's also working fine. Doesn't seem like there's an OpenLDAP bug here, must be a problem with your machine. >> ó Õ×ÁÖÅÎÉÅÍ, éÌØÑ >> >> >> 2013/5/24 Howard Chu <hyc(a)symas.com <mailto:hyc@symas.com>> >> >> ilya.lukyanov(a)gmail.com <mailto:ilya.lukyanov@gmail.com> wrote: >> >> Full_Name: Ilya Lukyanov >> Version: 2.4.35 >> OS: Windows 7 x64 >> URL: ftp://ftp.openldap.org/__incoming/ <ftp://ftp.openldap.org/incoming/> >> Submission from: (NULL) (95.25.254.250) >> >> >> I've built lmdb from source distribution of OpenLDAP 2.4.35 under >> Windows 7 x64 >> under Visual Studio 2012. All tests included into source distribution pass >> successfully. >> >> Then i'm executing my own test with code as follows: >> https://gist.github.com/__ilyalukyanov/5644971 >> <https://gist.github.com/ilyalukyanov/5644971> >> And i'm allways get an asserion when executing near 32500-th >> mdb_txn_commit >> (line 2231 - assert(oldpg_txnid <= env->me_pglast);) >> I think this is a bug because if consider the scenario with separate >> usage of >> LightningDB under high write-load scenario, 32k commits is not enough. >> >> >> Your test runs fine on my Linux box. I don't currently have a Windows 7 >> x64 test machine, won't be able to investigate this any time soon. -- -- 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#7606) reference through null pointer and memory leak
by quanah＠zimbra.com 24 May '13

24 May '13

--On Friday, May 24, 2013 9:06 PM +0000 jdhgit(a)yahoo.com wrote: Please don't send garbage to the ITS. I advise finding an email client that can actually generate proper email. --Quanah > --1665047788-1800616979-1369429529=:40525 > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: quoted-printable > > Configuration:=0A=0A=A0 CFLAGS=3D"-g -O0" ./configure > --exec-prefix=3D/usr = --prefix=3D/ --enable-overlays=3Dyes > --enable-slapd --enable-debug=0A=0ASta= rt server: =0A=0A=A0 valgrind > --leak-check=3Dfull openldap/servers/slapd/sl= apd=0A=0APerform search > with sorted, paged results. Repeating the command w= ill cause the leaked > memory to grow. I'm using:=0A=0A=A0 ldapsearch -H ldap= ://10.10.9.85 -x > -b ou=3Dpeople,dc=3Dexample,dc=3Dcom -s one -E'!sss=3Dsn:2= .5.13.3' > -E'!pr=3D10/prompt'=0A=0AAt the prompt, type ctrl-C.=0A=0AKill the= > slapd process. The output of valgrind shows the > following:=0A=0A=3D=3D486= =3D=3D =0A=3D=3D486=3D=3D HEAP > SUMMARY:=0A=3D=3D486=3D=3D=A0=A0=A0=A0 in us= e at exit: 95,262 bytes in > 1,984 blocks=0A=3D=3D486=3D=3D=A0=A0 total heap = usage: 34,975 allocs, > 32,991 frees, 22,150,370 bytes allocated=0A=3D=3D486= =3D=3D > =0A=3D=3D486=3D=3D 394 (16 direct, 378 indirect) bytes in 1 blocks a= re > definitely lost in loss record 7 of 10=0A=3D=3D486=3D=3D=A0=A0=A0 at 0x4= > 027282: malloc (vg_replace_malloc.c:270)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x82= 228BF: ber_memalloc_x (memory.c:228)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x822290= C: ber_memalloc (memory.c:244)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x81EAC29: tav= l_insert (tavl.c:94)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x81C7FE9: sssvlv_op_res= ponse (sssvlv.c:760)=0A=3D=3D486=3D=3D=A0=A0=A0 > by 0x8084184: slap_response= _play > (result.c:491)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80859AE: slap_send_sea= > rch_entry (result.c:995)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x810BDD6: > bdb_searc= h (search.c:1014)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80F11DB: > overlay_op_walk = (backover.c:671)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x80F138B: over_op_func (bac= kover.c:723)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x80F1443: over_op_search (backo= ver.c:750)=0A=3D=3D486=3D=3D=A0=A0=A0 > by 0x80748AE: fe_op_search (search.c:= 402)=0A=3D=3D486=3D=3D > =0A=3D=3D486=3D=3D 94,753 (16 direct, 94,737 indirec= t) bytes in 1 > blocks are definitely lost in loss record 10 of 10=0A=3D=3D48= > 6=3D=3D=A0=A0=A0 at 0x4027282: malloc > (vg_replace_malloc.c:270)=0A=3D=3D486= =3D=3D=A0=A0=A0 by 0x82228BF: > ber_memalloc_x (memory.c:228)=0A=3D=3D486=3D= =3D=A0=A0=A0 by 0x822290C: > ber_memalloc (memory.c:244)=0A=3D=3D486=3D=3D=A0= =A0=A0 by 0x81EAB3A: > tavl_insert (tavl.c:69)=0A=3D=3D486=3D=3D=A0=A0=A0 by = 0x81C7FE9: > sssvlv_op_response (sssvlv.c:760)=0A=3D=3D486=3D=3D=A0=A0=A0 by = > 0x8084184: slap_response_play (result.c:491)=0A=3D=3D486=3D=3D=A0=A0=A0 > by = 0x80859AE: slap_send_search_entry > (result.c:995)=0A=3D=3D486=3D=3D=A0=A0=A0= by 0x810BDD6: bdb_search > (search.c:1014)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x8= 0F11DB: > overlay_op_walk (backover.c:671)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80= > F138B: over_op_func (backover.c:723)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x80F144= 3: over_op_search (backover.c:750)=0A=3D=3D486=3D=3D=A0=A0=A0 > by 0x80748AE:= fe_op_search (search.c:402)=0A=3D=3D486=3D=3D > =0A=3D=3D486=3D=3D LEAK SUMM= ARY:=0A=3D=3D486=3D=3D=A0=A0=A0 definitely > lost: 32 bytes in 2 blocks=0A=3D= =3D486=3D=3D=A0=A0=A0 indirectly lost: > 95,115 bytes in 1,976 blocks=0A=3D= =3D486=3D=3D=A0=A0=A0=A0=A0 possibly > lost: 0 bytes in 0 blocks=0A=3D=3D486= =3D=3D=A0=A0=A0 still reachable: > 115 bytes in 6 blocks=0A=3D=3D486=3D=3D=A0= =A0=A0=A0=A0=A0=A0=A0 > suppressed: 0 bytes in 0 blocks=0A=3D=3D486=3D=3D Rea= chable blocks > (those to which a pointer was found) are not shown.=0A=3D=3D4= 86=3D=3D > To see them, rerun with: --leak-check=3Dfull --show-reachable=3Dye= > s=0A=3D=3D486=3D=3D =0A=3D=3D486=3D=3D For counts of detected and > suppresse= d errors, rerun with: -v=0A=3D=3D486=3D=3D ERROR SUMMARY: 2 > errors from 2 c= ontexts (suppressed: 71 from 13) > --1665047788-1800616979-1369429529=:40525 > Content-Type: text/html; charset=iso-8859-1 > Content-Transfer-Encoding: quoted-printable > > <html><body><div style=3D"color:#000; background-color:#fff; > font-family:ti= mes new roman, new york, times, > serif;font-size:12pt">Configuration: <br= >>   CFLAGS=3D"-g -O0" ./configure --exec-prefix=3D/usr --prefix=3D/ >> --e= > nable-overlays=3Dyes --enable-slapd --enable-debug Start server: > <br= >>   valgrind --leak-check=3Dfull >> openldap/servers/slapd/slapd <b= > r>Perform search with sorted, paged results. Repeating the command will > cau= se the leaked memory to grow. I'm using:   ldapsearch -H > ldap:/= /10.10.9.85 -x -b ou=3Dpeople,dc=3Dexample,dc=3Dcom -s one > -E'!sss=3Dsn:2.5= .13.3' -E'!pr=3D10/prompt' At the prompt, type > ctrl-C. Kill t= he slapd process. The output of valgrind shows the > following: =3D=3D= 486=3D=3D =3D=3D486=3D=3D HEAP > SUMMARY: =3D=3D486=3D=3D  &= nbsp;  in use at exit: > 95,262 bytes in 1,984 blocks =3D=3D486=3D=3D=    total heap > usage: 34,975 allocs, 32,991 frees, 22,150,370 byte= s > allocated =3D=3D486=3D=3D =3D=3D486=3D=3D 394 (16 > direct, 378 indirect) bytes in 1 blocks are definitely lost in loss > record= 7 of 10 =3D=3D486=3D=3D    at 0x4027282: > malloc (vg_repl= ace_malloc.c:270) =3D=3D486=3D=3D    > by 0x82228BF: ber_me= malloc_x > (memory.c:228) =3D=3D486=3D=3D    by 0x822290C: = > ber_memalloc (memory.c:244) =3D=3D486=3D=3D    by > 0x81EAC= 29: tavl_insert (tavl.c:94) =3D=3D486=3D=3D    > by 0x81C7F= E9: sssvlv_op_response > (sssvlv.c:760) =3D=3D486=3D=3D    = by 0x8084184: > slap_response_play (result.c:491) =3D=3D486=3D=3D &nb= sp;  > by 0x80859AE: slap_send_search_entry (result.c:995) =3D=3D486= > =3D=3D    by 0x810BDD6: bdb_search > (search.c:1014) =3D=3D= 486=3D=3D    by 0x80F11DB: > overlay_op_walk (backover.c:671)<= br>=3D=3D486=3D=3D    > by 0x80F138B: over_op_func (backover.c= > :723) =3D=3D486=3D=3D    by 0x80F1443: over_op_search > (ba= ckover.c:750) =3D=3D486=3D=3D    by 0x80748AE: > fe_op_sear= ch > (search.c:402) =3D=3D486=3D=3D =3D=3D486=3D=3D 94,753 (16 direct, > 9= 4,737 indirect) bytes in 1 blocks are definitely lost in loss record > 10 of = 10 =3D=3D486=3D=3D    at 0x4027282: malloc > (vg_replace_ma= lloc.c:270) =3D=3D486=3D=3D    by > 0x82228BF: ber_memalloc= _x > (memory.c:228) =3D=3D486=3D=3D    by 0x822290C: ber_me= > malloc (memory.c:244) =3D=3D486=3D=3D    by 0x81EAB3A: > ta= vl_insert (tavl.c:69) =3D=3D486=3D=3D    by > 0x81C7FE9: ss= svlv_op_response > (sssvlv.c:760) =3D=3D486=3D=3D    by 0x8= 084184: > slap_response_play (result.c:491) =3D=3D486=3D=3D  &nb= sp; > by 0x80859AE: slap_send_search_entry (result.c:995) =3D=3D486=3D=3D&= > nbsp;   by 0x810BDD6: bdb_search > (search.c:1014) =3D=3D486=3D= =3D    by 0x80F11DB: > overlay_op_walk (backover.c:671) =3D= =3D486=3D=3D    > by 0x80F138B: over_op_func (backover.c:723)<= > br>=3D=3D486=3D=3D    by 0x80F1443: over_op_search > (backover.c:750) =3D=3D486=3D=3D    by 0x80748AE: > fe_op_= search (search.c:402) =3D=3D486=3D=3D =3D=3D486=3D=3D LEAK > SUMMARY:<= br>=3D=3D486=3D=3D    definitely lost: 32 bytes > in 2 blocks<= br>=3D=3D486=3D=3D    indirectly lost: > 95,115 bytes in 1,976= > blocks =3D=3D486=3D=3D      possibly lost: 0 > b= ytes in 0 blocks =3D=3D486=3D=3D    still reachable: > 115 = bytes in 6 > blocks =3D=3D486=3D=3D      &nb= > sp;  suppressed: 0 bytes in 0 blocks =3D=3D486=3D=3D Reachable > bloc= ks (those to which a pointer was found) are not > shown. =3D=3D486=3D=3D T= o see them, rerun with: --leak-check=3Dfull > --show-reachable=3Dyes =3D= =3D486=3D=3D =3D=3D486=3D=3D For > counts of detected and suppressed erro= rs, rerun with: > -v =3D=3D486=3D=3D ERROR SUMMARY: 2 errors from 2 contex= ts > (suppressed: 71 from 13) <div style=3D"font-family: times new= > roman, new york, times, serif; font-size: 12pt;"><div > style=3D"font-family= : times new roman, new york, > times, serif; font-size: 12pt;"> </div> </div> </div></body></html> > --1665047788-1800616979-1369429529=:40525-- > > -- 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#7606) reference through null pointer and memory leak
by jdhgit＠yahoo.com 24 May '13

24 May '13

--1665047788-1800616979-1369429529=:40525 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Configuration:=0A=0A=A0 CFLAGS=3D"-g -O0" ./configure --exec-prefix=3D/usr = --prefix=3D/ --enable-overlays=3Dyes --enable-slapd --enable-debug=0A=0ASta= rt server: =0A=0A=A0 valgrind --leak-check=3Dfull openldap/servers/slapd/sl= apd=0A=0APerform search with sorted, paged results. Repeating the command w= ill cause the leaked memory to grow. I'm using:=0A=0A=A0 ldapsearch -H ldap= ://10.10.9.85 -x -b ou=3Dpeople,dc=3Dexample,dc=3Dcom -s one -E'!sss=3Dsn:2= .5.13.3' -E'!pr=3D10/prompt'=0A=0AAt the prompt, type ctrl-C.=0A=0AKill the= slapd process. The output of valgrind shows the following:=0A=0A=3D=3D486= =3D=3D =0A=3D=3D486=3D=3D HEAP SUMMARY:=0A=3D=3D486=3D=3D=A0=A0=A0=A0 in us= e at exit: 95,262 bytes in 1,984 blocks=0A=3D=3D486=3D=3D=A0=A0 total heap = usage: 34,975 allocs, 32,991 frees, 22,150,370 bytes allocated=0A=3D=3D486= =3D=3D =0A=3D=3D486=3D=3D 394 (16 direct, 378 indirect) bytes in 1 blocks a= re definitely lost in loss record 7 of 10=0A=3D=3D486=3D=3D=A0=A0=A0 at 0x4= 027282: malloc (vg_replace_malloc.c:270)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x82= 228BF: ber_memalloc_x (memory.c:228)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x822290= C: ber_memalloc (memory.c:244)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x81EAC29: tav= l_insert (tavl.c:94)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x81C7FE9: sssvlv_op_res= ponse (sssvlv.c:760)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x8084184: slap_response= _play (result.c:491)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80859AE: slap_send_sea= rch_entry (result.c:995)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x810BDD6: bdb_searc= h (search.c:1014)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80F11DB: overlay_op_walk = (backover.c:671)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80F138B: over_op_func (bac= kover.c:723)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80F1443: over_op_search (backo= ver.c:750)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80748AE: fe_op_search (search.c:= 402)=0A=3D=3D486=3D=3D =0A=3D=3D486=3D=3D 94,753 (16 direct, 94,737 indirec= t) bytes in 1 blocks are definitely lost in loss record 10 of 10=0A=3D=3D48= 6=3D=3D=A0=A0=A0 at 0x4027282: malloc (vg_replace_malloc.c:270)=0A=3D=3D486= =3D=3D=A0=A0=A0 by 0x82228BF: ber_memalloc_x (memory.c:228)=0A=3D=3D486=3D= =3D=A0=A0=A0 by 0x822290C: ber_memalloc (memory.c:244)=0A=3D=3D486=3D=3D=A0= =A0=A0 by 0x81EAB3A: tavl_insert (tavl.c:69)=0A=3D=3D486=3D=3D=A0=A0=A0 by = 0x81C7FE9: sssvlv_op_response (sssvlv.c:760)=0A=3D=3D486=3D=3D=A0=A0=A0 by = 0x8084184: slap_response_play (result.c:491)=0A=3D=3D486=3D=3D=A0=A0=A0 by = 0x80859AE: slap_send_search_entry (result.c:995)=0A=3D=3D486=3D=3D=A0=A0=A0= by 0x810BDD6: bdb_search (search.c:1014)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x8= 0F11DB: overlay_op_walk (backover.c:671)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80= F138B: over_op_func (backover.c:723)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80F144= 3: over_op_search (backover.c:750)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80748AE:= fe_op_search (search.c:402)=0A=3D=3D486=3D=3D =0A=3D=3D486=3D=3D LEAK SUMM= ARY:=0A=3D=3D486=3D=3D=A0=A0=A0 definitely lost: 32 bytes in 2 blocks=0A=3D= =3D486=3D=3D=A0=A0=A0 indirectly lost: 95,115 bytes in 1,976 blocks=0A=3D= =3D486=3D=3D=A0=A0=A0=A0=A0 possibly lost: 0 bytes in 0 blocks=0A=3D=3D486= =3D=3D=A0=A0=A0 still reachable: 115 bytes in 6 blocks=0A=3D=3D486=3D=3D=A0= =A0=A0=A0=A0=A0=A0=A0 suppressed: 0 bytes in 0 blocks=0A=3D=3D486=3D=3D Rea= chable blocks (those to which a pointer was found) are not shown.=0A=3D=3D4= 86=3D=3D To see them, rerun with: --leak-check=3Dfull --show-reachable=3Dye= s=0A=3D=3D486=3D=3D =0A=3D=3D486=3D=3D For counts of detected and suppresse= d errors, rerun with: -v=0A=3D=3D486=3D=3D ERROR SUMMARY: 2 errors from 2 c= ontexts (suppressed: 71 from 13) --1665047788-1800616979-1369429529=:40525 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:ti= mes new roman, new york, times, serif;font-size:12pt">Configuration: <br= >  CFLAGS=3D"-g -O0" ./configure --exec-prefix=3D/usr --prefix=3D/ --e= nable-overlays=3Dyes --enable-slapd --enable-debug Start server: <br= >   valgrind --leak-check=3Dfull openldap/servers/slapd/slapd <b= r>Perform search with sorted, paged results. Repeating the command will cau= se the leaked memory to grow. I'm using:   ldapsearch -H ldap:/= /10.10.9.85 -x -b ou=3Dpeople,dc=3Dexample,dc=3Dcom -s one -E'!sss=3Dsn:2.5= .13.3' -E'!pr=3D10/prompt' At the prompt, type ctrl-C. Kill t= he slapd process. The output of valgrind shows the following: =3D=3D= 486=3D=3D =3D=3D486=3D=3D HEAP SUMMARY: =3D=3D486=3D=3D  &= nbsp;  in use at exit: 95,262 bytes in 1,984 blocks =3D=3D486=3D=3D=    total heap usage: 34,975 allocs, 32,991 frees, 22,150,370 byte= s allocated =3D=3D486=3D=3D =3D=3D486=3D=3D 394 (16 direct, 378 indirect) bytes in 1 blocks are definitely lost in loss record= 7 of 10 =3D=3D486=3D=3D    at 0x4027282: malloc (vg_repl= ace_malloc.c:270) =3D=3D486=3D=3D    by 0x82228BF: ber_me= malloc_x (memory.c:228) =3D=3D486=3D=3D    by 0x822290C: = ber_memalloc (memory.c:244) =3D=3D486=3D=3D    by 0x81EAC= 29: tavl_insert (tavl.c:94) =3D=3D486=3D=3D    by 0x81C7F= E9: sssvlv_op_response (sssvlv.c:760) =3D=3D486=3D=3D    = by 0x8084184: slap_response_play (result.c:491) =3D=3D486=3D=3D &nb= sp;  by 0x80859AE: slap_send_search_entry (result.c:995) =3D=3D486= =3D=3D    by 0x810BDD6: bdb_search (search.c:1014) =3D=3D= 486=3D=3D    by 0x80F11DB: overlay_op_walk (backover.c:671)<= br>=3D=3D486=3D=3D    by 0x80F138B: over_op_func (backover.c= :723) =3D=3D486=3D=3D    by 0x80F1443: over_op_search (ba= ckover.c:750) =3D=3D486=3D=3D    by 0x80748AE: fe_op_sear= ch (search.c:402) =3D=3D486=3D=3D =3D=3D486=3D=3D 94,753 (16 direct, 9= 4,737 indirect) bytes in 1 blocks are definitely lost in loss record 10 of = 10 =3D=3D486=3D=3D    at 0x4027282: malloc (vg_replace_ma= lloc.c:270) =3D=3D486=3D=3D    by 0x82228BF: ber_memalloc= _x (memory.c:228) =3D=3D486=3D=3D    by 0x822290C: ber_me= malloc (memory.c:244) =3D=3D486=3D=3D    by 0x81EAB3A: ta= vl_insert (tavl.c:69) =3D=3D486=3D=3D    by 0x81C7FE9: ss= svlv_op_response (sssvlv.c:760) =3D=3D486=3D=3D    by 0x8= 084184: slap_response_play (result.c:491) =3D=3D486=3D=3D  &nb= sp; by 0x80859AE: slap_send_search_entry (result.c:995) =3D=3D486=3D=3D&= nbsp;   by 0x810BDD6: bdb_search (search.c:1014) =3D=3D486=3D= =3D    by 0x80F11DB: overlay_op_walk (backover.c:671) =3D= =3D486=3D=3D    by 0x80F138B: over_op_func (backover.c:723)<= br>=3D=3D486=3D=3D    by 0x80F1443: over_op_search (backover.c:750) =3D=3D486=3D=3D    by 0x80748AE: fe_op_= search (search.c:402) =3D=3D486=3D=3D =3D=3D486=3D=3D LEAK SUMMARY:<= br>=3D=3D486=3D=3D    definitely lost: 32 bytes in 2 blocks<= br>=3D=3D486=3D=3D    indirectly lost: 95,115 bytes in 1,976= blocks =3D=3D486=3D=3D      possibly lost: 0 b= ytes in 0 blocks =3D=3D486=3D=3D    still reachable: 115 = bytes in 6 blocks =3D=3D486=3D=3D      &nb= sp;  suppressed: 0 bytes in 0 blocks =3D=3D486=3D=3D Reachable bloc= ks (those to which a pointer was found) are not shown. =3D=3D486=3D=3D T= o see them, rerun with: --leak-check=3Dfull --show-reachable=3Dyes =3D= =3D486=3D=3D =3D=3D486=3D=3D For counts of detected and suppressed erro= rs, rerun with: -v =3D=3D486=3D=3D ERROR SUMMARY: 2 errors from 2 contex= ts (suppressed: 71 from 13) <div style=3D"font-family: times new= roman, new york, times, serif; font-size: 12pt;"><div style=3D"font-family= : times new roman, new york, times, serif; font-size: 12pt;"> </div> </div> </div></body></html> --1665047788-1800616979-1369429529=:40525--

1 0

Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by pierangelo.masarati＠polimi.it 24 May '13

24 May '13

On 05/24/2013 09:41 PM, ck(a)cksoft.de wrote: > Full_Name: Christian Kratzer > Version: 2.4.35 > OS: CentOS 6.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (37.80.52.67) > > > Hi, > > I have setup an acl to allow write access to cn=config for users in the main > directory. > > This is mainly to have a clean audit trail of config changes using auditlog so > changes can be tracked back to who did them. > > We also backup config with slapcat -n0 and data with slapcat. > > When restoring configs and data I ran into two spefific problems when cn=config > entries have a modifiersdn outside of cn=config as in: > > dn: cn=config > objectClass: olcGlobal > ... > modifiersName: cn=Alice,ou=People,dc=test > modifyTimestamp: 20130524161850Z > > This is on openldap-2.4.35 on centos-6.4. > > I have built a simple test case to illustrate the problem. Should be easily > reproducible using after editing a few paths in below configs. > > We setup a new openldap server by using slapadd -n0 of below config and slapadd > of below data in test.ldif. > > http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/config.ldif > http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/test.ldif > > After starting slapd I modify the configuration as cn=Alice,ou=People,dc=test > using below scripts > > http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/olcLoglevel.sh > http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/olcLoglevel.ldif > > I then extract following two backups from cn=config using slapcat -n0 and > dc=test using slapcat > > http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/slapcat-cn=conf… > http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/slapcat-dc=test… > > First problem: An attempt to to restore slapcat-dc=test.ldif after deleting data > using "rm -f /var/lib/ldap/*" fails as follows: > > [root@test-centos64 openldap]# slapadd -v -F slapd.d -l slapcat-dc\=test.ldif > 519f93a8 PROXIED attributeDescription "OU" inserted. > 519f93a8 PROXIED attributeDescription "DC" inserted. > 519f93a8 => mdb_tool_entry_put: id2entry_add failed: err=17 > 519f93a8 => mdb_tool_entry_put: txn_aborted! File exists (17) > slapadd: could not add entry dn="dc=test" (line=1): txn_aborted! File exists This is a chicken and egg problem. OU is not built-in, so it cannot be used until it is configured. Configuration data must only use schema items whose definition is already loaded. I don't see a clear way out of this issue, so I'd pass the ball to Howard. My (humble) suggestion is: delegate modifications to identities whose DN is made of hardcoded attribute types: CN, UID (you can find what attribute types are hardcoded in schema_prep.c). p. > (17) > _#### 24.55% eta none elapsed none spd 2.0 > M/s > Closing DB... > [root@test-centos64 openldap]# > > I can successfully import the data if I edit cn=config.ldif and manuelly fix the > modifiersName to cn=config and reimport configuration using slapadd -n0. > > This also kills our disaster recovery scenario of deleting data and letting > syncrepl handle the recovery. > > Second problem: Recovery of the configuration fails as after "rm -fr slapd.d" > > [root@test-centos64 openldap]# slapadd -v -n0 -F slapd.d -l > slapcat-cn\=config.ldif > 519f95c2 str2entry: invalid value for attributeType modifiersName #0 (syntax > 1.3.6.1.4.1.1466.115.121.1.12) > slapadd: could not parse entry (line=1) > _# 5.39% eta none elapsed none spd 3.2 > M/s > Closing DB... > [root@test-centos64 openldap]# > > Again I am able to work around the problem by fixing the modifiersdn of the > cn=config dump before slapadding with slapadd -n0. > > Any chance of getting above use cases working ? I would like to provide the > customer in question with a straight forward recovery process for both data and > cn=config. > > They would like to avoid using the cn=config rootDN for regular administration > in order to have a clean audit trail of changes using auditlog on cn=config. > > Greetings > Christian > > > > > -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by ck＠cksoft.de 24 May '13

24 May '13

Full_Name: Christian Kratzer Version: 2.4.35 OS: CentOS 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.80.52.67) Hi, I have setup an acl to allow write access to cn=config for users in the main directory. This is mainly to have a clean audit trail of config changes using auditlog so changes can be tracked back to who did them. We also backup config with slapcat -n0 and data with slapcat. When restoring configs and data I ran into two spefific problems when cn=config entries have a modifiersdn outside of cn=config as in: dn: cn=config objectClass: olcGlobal ... modifiersName: cn=Alice,ou=People,dc=test modifyTimestamp: 20130524161850Z This is on openldap-2.4.35 on centos-6.4. I have built a simple test case to illustrate the problem. Should be easily reproducible using after editing a few paths in below configs. We setup a new openldap server by using slapadd -n0 of below config and slapadd of below data in test.ldif. http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/config.ldif http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/test.ldif After starting slapd I modify the configuration as cn=Alice,ou=People,dc=test using below scripts http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/olcLoglevel.sh http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/olcLoglevel.ldif I then extract following two backups from cn=config using slapcat -n0 and dc=test using slapcat http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/slapcat-cn=conf… http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/slapcat-dc=test… First problem: An attempt to to restore slapcat-dc=test.ldif after deleting data using "rm -f /var/lib/ldap/*" fails as follows: [root@test-centos64 openldap]# slapadd -v -F slapd.d -l slapcat-dc\=test.ldif 519f93a8 PROXIED attributeDescription "OU" inserted. 519f93a8 PROXIED attributeDescription "DC" inserted. 519f93a8 => mdb_tool_entry_put: id2entry_add failed: err=17 519f93a8 => mdb_tool_entry_put: txn_aborted! File exists (17) slapadd: could not add entry dn="dc=test" (line=1): txn_aborted! File exists (17) _#### 24.55% eta none elapsed none spd 2.0 M/s Closing DB... [root@test-centos64 openldap]# I can successfully import the data if I edit cn=config.ldif and manuelly fix the modifiersName to cn=config and reimport configuration using slapadd -n0. This also kills our disaster recovery scenario of deleting data and letting syncrepl handle the recovery. Second problem: Recovery of the configuration fails as after "rm -fr slapd.d" [root@test-centos64 openldap]# slapadd -v -n0 -F slapd.d -l slapcat-cn\=config.ldif 519f95c2 str2entry: invalid value for attributeType modifiersName #0 (syntax 1.3.6.1.4.1.1466.115.121.1.12) slapadd: could not parse entry (line=1) _# 5.39% eta none elapsed none spd 3.2 M/s Closing DB... [root@test-centos64 openldap]# Again I am able to work around the problem by fixing the modifiersdn of the cn=config dump before slapadding with slapadd -n0. Any chance of getting above use cases working ? I would like to provide the customer in question with a straight forward recovery process for both data and cn=config. They would like to avoid using the cn=config rootDN for regular administration in order to have a clean audit trail of changes using auditlog on cn=config. Greetings Christian

1 0

Re: (ITS#7607) Assertion triggers during many sequential transaction commits
by hyc＠symas.com 24 May '13

24 May '13

ilya.lukyanov(a)gmail.com wrote: > Full_Name: Ilya Lukyanov > Version: 2.4.35 > OS: Windows 7 x64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.25.254.250) > > > I've built lmdb from source distribution of OpenLDAP 2.4.35 under Windows 7 x64 > under Visual Studio 2012. All tests included into source distribution pass > successfully. > > Then i'm executing my own test with code as follows: > https://gist.github.com/ilyalukyanov/5644971 > And i'm allways get an asserion when executing near 32500-th mdb_txn_commit > (line 2231 - assert(oldpg_txnid <= env->me_pglast);) > I think this is a bug because if consider the scenario with separate usage of > LightningDB under high write-load scenario, 32k commits is not enough. Your test runs fine on my Linux box. I don't currently have a Windows 7 x64 test machine, won't be able to investigate this any time soon. -- -- 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#7607) Assertion triggers during many sequential transaction commits
by ilya.lukyanov＠gmail.com 24 May '13

24 May '13

Full_Name: Ilya Lukyanov Version: 2.4.35 OS: Windows 7 x64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.25.254.250) I've built lmdb from source distribution of OpenLDAP 2.4.35 under Windows 7 x64 under Visual Studio 2012. All tests included into source distribution pass successfully. Then i'm executing my own test with code as follows: https://gist.github.com/ilyalukyanov/5644971 And i'm allways get an asserion when executing near 32500-th mdb_txn_commit (line 2231 - assert(oldpg_txnid <= env->me_pglast);) I think this is a bug because if consider the scenario with separate usage of LightningDB under high write-load scenario, 32k commits is not enough.

1 0

Re: reference through null pointer and memory leak (related to ITS#7588)
by hyc＠symas.com 24 May '13

24 May '13

jdhgit(a)yahoo.com wrote: > Full_Name: John Hardin > Version: master > OS: Centos 6.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (50.23.115.111) > > > The commit for ITS#7588 causes a crash if next_node is NULL: > > /* Set the first entry to send for the next page */ > so->so_tree = next_node; > + next_node->avl_left = NULL; > > next_node will be NULL if all entries have been sent, or if slapd_shutdown is > true. Thanks for pointing this out, will fix it shortly. > Another issue related to ITS#7588 is a memory leak when a sorted search with > paged results is aborted. This may be because so->so_tree is not the root of the > tree when free_sort_op() calls tavl_free(). Not being root of the tree is irrelevant. The tree is threaded, and every remaining node is connected by its preceding node's right child pointer. The tavl_free() function recurses over all of the right and left children, so this should not be a problem. Can you post a test case that demonstrates the leak? -- -- 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

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