openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#8054) Operation duration logging
by clem.oudot＠gmail.com 24 Feb '15

24 Feb '15

2015-02-11 18:33 GMT+01:00 <h.b.furuseth(a)usit.uio.no>: > On 11. feb. 2015 12:38, Michael Str=C3=B6der wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> Cool feture, but please use fewer characteres in the already >>> bloated log. How about "time=3D<integer>us" or even omit the "us"? >> >> +1 >> >> But 'time' sounds a bit general. >> How about 'tdu' or even 'td' as abbreviation for "time duration"? > > I don't think so. You can't see from that what it means unless you > already know, so you have to look it up just to see if you're > interested. 'time' you can decide to look up if you are interested. > Seems other LDAP servers have choosen 'etime' (see http://ludopoitou.com/2015/02/24/about-auditing-ldap-operations/). Why not try to use the same word? Cl=C3=A9ment OUDOT.

1 0

Re: (ITS#8062) Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next()
by hyc＠symas.com 23 Feb '15

23 Feb '15

g(a)wenarab.com wrote: > Full_Name: Gawen Arab > Version: 0.9.14 > OS: OSX > URL: http://gawen.me/pub/lmdb_crash/gawen-150223.tar.xz > Submission from: (NULL) (77.151.59.7) > > > Hello, > > I'm currently developing a virtual filesystem whose metadata are stored in a > LMDB 0.9.14 database. This software can currently run over Android, iOS, Linux, > OSX and Windows. > > This software is currently used by 50 users and I received 11 crash reports of > SIGSEV raised in LMDB. All reports come from OSX computers. Thanks for the report. Unfortunately, it appears the DB was constructed incorrectly at some time in the past, so even updating to later revisions of the code won't avoid the crash. It's more important now to find the sequence of steps that recreates the invalid DB in the first place, or verify that the same sequence doesn't crash using the 0.9.15 release candidate. > > mdb.c:5382: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() > > This comes from this assertion > https://gitorious.org/mdb/mdb/source/2f587ae081d076e3707360c5db086520c219d3… > . > > This happens when the software iterates over keys in the database, the same way > mdb_dump does, calling in loop mdb_cursor_get(..., MDB_NEXT). > > I managed to get back the LMDB db folder from one user which runs on OSX > 64bits. > I performed a mdb_dump of it with my Linux 64bits. mdb_dump crashes the same > way. I tried with the lastest mdb_dump from the mdb.master branch (commit > 3368d1f5e243225cba4d730fba19ff600798ebe3), but I have the same assertion. > > mdb.c:5599: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() > > I attached to this issue the faulty database 'db/'. > > The output of mdb_dump on my machine is attached to this issue named as the > file > 'mdb_dump.log'. I runned back mdb_dump with MDB_DEBUG defined to 2 and > mdb_debug > true. I attached the output of this new dump as the file 'mdb_dump.debug.log'. > The interesting part: > > mdb_cursor_next:5574 cursor_next: top page is 1946 in cursor 0x1897350 > mdb_cursor_next:5591 ==> cursor points to page 1946 with 50 keys, key index 48 > b5f1ff0700000000 > 0700000000000000bc10000000000000000e000000000000860d000000000000e308000000000000ee07000000000000a5070000000000000307000000000000 > mdb_cursor_next:5574 cursor_next: top page is 1946 in cursor 0x1897350 > mdb_cursor_next:5591 ==> cursor points to page 1946 with 50 keys, key index 49 > b6f1ff0700000000 > 0700000000000000820e000000000000310e000000000000770d000000000000660c000000000000cb0a0000000000002a080000000000000008000000000000 > mdb_cursor_next:5574 cursor_next: top page is 1946 in cursor 0x1897350 > mdb_cursor_next:5579 =====> move to next sibling page mdb_cursor_pop:5095 > popped > page 1946 off db 1 cursor 0x1897350 mdb_cursor_sibling:5503 parent page is page > 4643, index 16 mdb_cursor_sibling:5521 just moving to right index key 17 > mdb_cursor_push:5104 pushing page 704 on db 1 cursor 0x1897350 > mdb_cursor_next:5585 next page is 704, key index 0 mdb_cursor_next:5591 ==> > cursor points to page 704 with 7 keys, key index 0 mdb.c:5599: Assertion > 'IS_LEAF(mp)' failed in mdb_cursor_next() > %%0 > I do not know much about internal LMDB design for now, so I'm struggling to > understand the debug lines... > > Unfortunately, I do not know how to reproduce this bug, but it is a recurring > one. > > Maybe the following information can help you, > > - My software opens the database in MDB_NOSYNC mode, and performs a > mdb_env_sync(env, 1) every second or less. A mdb_env_sync can happen at the > same time of any other operation (i.e. mdb_txn_commit). I didn't put any lock > mechanism. Could this expln n such situation ? > > - mapsize is currently 512MiB. Previous versions of the software set to smaller > values (the database had not been rebuilt since). > > I'd be happy to provide more information if you need. > > Thank you for your support and this amazing IP. > > Regards > > > -- -- 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#8062) Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next()
by g＠wenarab.com 23 Feb '15

23 Feb '15

Full_Name: Gawen Arab Version: 0.9.14 OS: OSX URL: http://gawen.me/pub/lmdb_crash/gawen-150223.tar.xz Submission from: (NULL) (77.151.59.7) Hello, I'm currently developing a virtual filesystem whose metadata are stored in a LMDB 0.9.14 database. This software can currently run over Android, iOS, Linux, OSX and Windows. This software is currently used by 50 users and I received 11 crash reports of SIGSEV raised in LMDB. All reports come from OSX computers. mdb.c:5382: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() This comes from this assertion https://gitorious.org/mdb/mdb/source/2f587ae081d076e3707360c5db086520c219d3… . This happens when the software iterates over keys in the database, the same way mdb_dump does, calling in loop mdb_cursor_get(..., MDB_NEXT). I managed to get back the LMDB db folder from one user which runs on OSX 64bits. I performed a mdb_dump of it with my Linux 64bits. mdb_dump crashes the same way. I tried with the lastest mdb_dump from the mdb.master branch (commit 3368d1f5e243225cba4d730fba19ff600798ebe3), but I have the same assertion. mdb.c:5599: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() I attached to this issue the faulty database 'db/'. The output of mdb_dump on my machine is attached to this issue named as the file 'mdb_dump.log'. I runned back mdb_dump with MDB_DEBUG defined to 2 and mdb_debug true. I attached the output of this new dump as the file 'mdb_dump.debug.log'. The interesting part: mdb_cursor_next:5574 cursor_next: top page is 1946 in cursor 0x1897350 mdb_cursor_next:5591 ==> cursor points to page 1946 with 50 keys, key index 48 b5f1ff0700000000 0700000000000000bc10000000000000000e000000000000860d000000000000e308000000000000ee07000000000000a5070000000000000307000000000000 mdb_cursor_next:5574 cursor_next: top page is 1946 in cursor 0x1897350 mdb_cursor_next:5591 ==> cursor points to page 1946 with 50 keys, key index 49 b6f1ff0700000000 0700000000000000820e000000000000310e000000000000770d000000000000660c000000000000cb0a0000000000002a080000000000000008000000000000 mdb_cursor_next:5574 cursor_next: top page is 1946 in cursor 0x1897350 mdb_cursor_next:5579 =====> move to next sibling page mdb_cursor_pop:5095 popped page 1946 off db 1 cursor 0x1897350 mdb_cursor_sibling:5503 parent page is page 4643, index 16 mdb_cursor_sibling:5521 just moving to right index key 17 mdb_cursor_push:5104 pushing page 704 on db 1 cursor 0x1897350 mdb_cursor_next:5585 next page is 704, key index 0 mdb_cursor_next:5591 ==> cursor points to page 704 with 7 keys, key index 0 mdb.c:5599: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() %%0 I do not know much about internal LMDB design for now, so I'm struggling to understand the debug lines... Unfortunately, I do not know how to reproduce this bug, but it is a recurring one. Maybe the following information can help you, - My software opens the database in MDB_NOSYNC mode, and performs a mdb_env_sync(env, 1) every second or less. A mdb_env_sync can happen at the same time of any other operation (i.e. mdb_txn_commit). I didn't put any lock mechanism. Could this expln n such situation ? - mapsize is currently 512MiB. Previous versions of the software set to smaller values (the database had not been rebuilt since). I'd be happy to provide more information if you need. Thank you for your support and this amazing IP. Regards

1 0

Re: (ITS#8044) openldap 2.4.39-8.el6: issue causing server unavailability
by Diana.Scannicchio＠cern.ch 23 Feb '15

23 Feb '15

I checked and the appropriate credentials are used, nothing in the configur= ation changed between this version (2.4.39-8) and the previous one(s). These are the corresponding lines of the slapd.conf on the consumer: overlay chain chain-rebind-as-user FALSE chain-uri "ldap://ldap_provider:389" chain-rebind-as-user TRUE chain-idassert-bind bindmethod=3D"simple" binddn=3D"cn=3DManager,ou=3Datlas,o=3Dcern,c=3Dc= h" credentials=3D"ldap_manager_pw" mode=3D"self" #chain-tls start chain-return-error TRUE Unless you spot something wrong in the configuration attached to the initia= l mail, there should be something else different between this non-working v= ersion and the previous ones, Thank you and best regards, Diana On 17 Feb 2015, at 12:55, hyc(a)symas.com wrote: > Diana.Scannicchio(a)cern.ch wrote: >> Is there anybody that could help on this issue?=3D20 >> this version of openldap is not usable, so I would like to understand wh= ich=3D >> is the problem and if can be fixed. >> Thank you and best regards, >=20 > The error message you're referring to was added in the patch for this ITS >=20 > http://www.openldap.org/its/index.cgi/Software%20Bugs?id=3D6851;selectid= =3D6851 >=20 > Check that you've configured appropriate credentials if you're using idas= sert on the target URI. >>=20 >> Diana >>=20 >>=20 >> On 02 Feb 2015, at 20:56, diana.scannicchio(a)cern.ch wrote: >>=20 >>> Should not, I did not enable it in the slapd.conf. >>> =3D20 >>> Diana >>> =3D20 >>> On 02 Feb 2015, at 20:34, <michael(a)stroeder.com> <michael(a)stroeder.com>= w=3D >> ro=3D3D >>> te: >>> =3D20 >>>> Is SSL/TLS part of the game? >>>> =3D3D20 >>>> Ciao, Michael. >>>> =3D3D20 >>>> =3D3D20 >>>> =3D3D20 >>>> =3D3D20 >>> =3D20 >>> - >>> Diana Scannicchio >>> University of California, Irvine >>> ATLAS TDAQ SysAdmin group >>> Office: +41 22 76 75240 >>> OnCall: 164851 >>> =3D20 >>> =3D20 >>> =3D20 >>> =3D20 >>> =3D20 >>> =3D20 >>> =3D20 >>> =3D20 >>> =3D20 >>=20 >> - >> Diana Scannicchio >> University of California, Irvine >> ATLAS TDAQ SysAdmin group >> Office: +41 22 76 75240 >> OnCall: 164851 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 > --=20 > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ >=20 >=20 >=20 - Diana Scannicchio University of California, Irvine ATLAS TDAQ SysAdmin group Office: +41 22 76 75240 OnCall: 164851

1 0

Re: (ITS#8027) ldapsearch -E deref=member: crashes slapd
by Howard Chu 23 Feb '15

23 Feb '15

Of course not. But slapo-deref is not installed or enabled by default. And since it is undocumented, no one would enable it by accident - most don't even know that it exists.

1 0

Re: (ITS#7796) LDAP_DEBUG_TRACE for "not indexed" log messages
by michael＠stroeder.com 22 Feb '15

22 Feb '15

Could you please add this patch to RE24? The amount of unneeded log messages in my setup with lots of ACLs using non-indexed filters is huge and I hate to maintain local build patches. Ciao, Michael.

1 0

(ITS#8061
by frederic.jacquot＠insa-lyon.fr 18 Feb '15

18 Feb '15

I compiled a new instance of OpenLDAP from the git Master and the bug seems to be fixed. After parsing the git commits, I found a link back to a bug report : http://www.openldap.org/its/index.cgi/Software%20Bugs?id=7975;selectid=7975 It's similar to mine (but didn't come up in my searches, sorry) so my bug report can be closed. Frederic Jacquot INSA Lyon

1 0

(ITS#8061) Base object returned when searching with scope: singleLevel (1) when using mdb backend and paged results
by frederic.jacquot＠insa-lyon.fr 18 Feb '15

18 Feb '15

Full_Name: Frederic Jacquot Version: 2.4.40 OS: Ubuntu 14.04.1 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.214.252.20) Hi, I think I discovered a bug with OpenLDAP 2.4.40, using an mdb backend. If you do a simple search request with no pagination and a SingleLevel (1) scope, everything is ok. But if you enable pagination for the same search, the base will also be returned in the search results. This breaks RFC 4511, paragraph 4.5.1.2 (SearchRequest.scope) : "singleLevel: The scope is constrained to the immediate subordinates of the entry named by baseObject." To reproduce the problem, I compiled a fresh OpenLDAP 2.4.40 with --enable-mdb. I then created a root entry : dn: dc=my-domain,dc=com objectClass: dcObject objectClass: organization dc: my-domain o : my-domain You can now compare search results. This is for a simple search : ldapsearch -s one -h localhost -b "dc=my-domain,dc=com" -w secret -D "cn=Manager,dc=my-domain,dc=com" # extended LDIF # # LDAPv3 # base <dc=my-domain,dc=com> with scope oneLevel # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 0 Success Which is ok. This is the same query with paged results enabled : ldapsearch -s one -h 134.214.182.252 -b "dc=my-domain,dc=com" -w secret -D "cn=Manager,dc=my-domain,dc=com" -E pr=100 # extended LDIF # # LDAPv3 # base <dc=my-domain,dc=com> with scope oneLevel # filter: (objectclass=*) # requesting: ALL # with pagedResults control: size=100 # # my-domain.com dn: dc=my-domain,dc=com objectClass: dcObject objectClass: organization dc: my-domain o: my-domain # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.319 false MAUCAQAEAA== pagedresults: cookie= # numResponses: 2 # numEntries: 1 The base object is returned, but shouldn't be. This behaviour shows an endless recursive directory hierarchy in some LDAP browsers (sometimes crashing them). It can also create endless loops in some applications querying the LDAP server (Canon Uniflow in my case). Regards, Frederic Jacquot INSA Lyon

1 0

(ITS#8060) mdb_from_db (bdb import)
by graehl＠gmail.com 17 Feb '15

17 Feb '15

Full_Name: Jonathan Graehl Version: n/a OS: n/a URL: ftp://ftp.openldap.org/incoming/0001-mdb_from_db-new-options-bugfix.patch Submission from: (NULL) (104.174.227.200) (see 0001-mdb_from_db-new-options-bugfix.patch) mdb_from_db utility for direct import from Berkeley DB to mdb Apparently this can only be distributed in binary form using older berkeley db versions, but building the utility from source for bulk import should be fine.

1 0

Re: (ITS#8044) openldap 2.4.39-8.el6: issue causing server unavailability
by hyc＠symas.com 17 Feb '15

17 Feb '15

Diana.Scannicchio(a)cern.ch wrote: > Is there anybody that could help on this issue?=20 > this version of openldap is not usable, so I would like to understand which= > is the problem and if can be fixed. > Thank you and best regards, The error message you're referring to was added in the patch for this ITS http://www.openldap.org/its/index.cgi/Software%20Bugs?id=6851;selectid=6851 Check that you've configured appropriate credentials if you're using idassert on the target URI. > > Diana > > > On 02 Feb 2015, at 20:56, diana.scannicchio(a)cern.ch wrote: > >> Should not, I did not enable it in the slapd.conf. >> =20 >> Diana >> =20 >> On 02 Feb 2015, at 20:34, <michael(a)stroeder.com> <michael(a)stroeder.com> w= > ro=3D >> te: >> =20 >>> Is SSL/TLS part of the game? >>> =3D20 >>> Ciao, Michael. >>> =3D20 >>> =3D20 >>> =3D20 >>> =3D20 >> =20 >> - >> Diana Scannicchio >> University of California, Irvine >> ATLAS TDAQ SysAdmin group >> Office: +41 22 76 75240 >> OnCall: 164851 >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 > > - > Diana Scannicchio > University of California, Irvine > ATLAS TDAQ SysAdmin group > Office: +41 22 76 75240 > OnCall: 164851 > > > > > > > > > > -- -- 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