openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#8265) RFE: resultCode counters in cn=monitor
by michael＠stroeder.com 06 Oct '15

06 Oct '15

Full_Name: Michael Str.der Version: HEAD OS: URL: Submission from: (NULL) (84.181.161.13) It would be handy especially for security monitoring if one could observe counters for several result codes in cn=monitor. E.g. correlating the number of bind requests with 49 counter is much easier and gives better performance than extracting log lines (if those are available at all). Maybe a tree like this: cn=monitor cn=Results monitoredResultCode=0 monitoredInfo: <counter> monitoredResultCode=49 monitoredInfo: <counter> This should probably configurable because there are so many also custom result code: database monitor monitor_resultcodes 0,49

1 0

Re: (ITS#8264) LMDB mdb_del in a cursor causes data loss in certain situations
by hyc＠symas.com 06 Oct '15

06 Oct '15

hyc(a)symas.com wrote: > Unable to reproduce. Ah, the error went away if you reran with an existing DB. After deleting the DB the problem showed up. Fixed now in mdb.master. -- -- 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#8264) LMDB mdb_del in a cursor causes data loss in certain situations
by hyc＠symas.com 05 Oct '15

05 Oct '15

malyn(a)strangeGizmo.com wrote: > Full_Name: Michael Alyn Miller > Version: LMDB 0.9.14, Git head > OS: Windows 8.1 x64, NixOS 14.12 x64 > URL: ftp://ftp.openldap.org/incoming/michael-alyn-miller-151005.c > Submission from: (NULL) (96.251.78.237) > > > I have a helper library that sits on top of LMDB and testing some of the > abstractions in that library has exposed a bug in LMDB related to deleting items > while inside of a cursor. I have reduced the repro down to a test case that > operates directly against LMDB. > > The test in question adds three groups of keys to the database (each with a > different prefix) and then deletes the third group of keys. The deletion is > done by scanning all of the keys with that prefix using a cursor. > mdb_cursor_del works correctly and deletes only the targeted keys, whereas > mdb_del causes nine extra keys (not in that group/prefix) to be deleted. > I have tested this code against LMDB 0.9.14 and Git head 8b46dcc. Please let me > know if you need any additional information. Thank you for your time! Unable to reproduce. violino:~/OD/mdb/libraries/liblmdb> gcc -g -c michael-alyn-miller-151005.c violino:~/OD/mdb/libraries/liblmdb> gcc -o mic michael-alyn-miller-151005.o -pthread liblmdb.a violino:~/OD/mdb/libraries/liblmdb> ./mic Num items after deletion using mdb_cursor_del: 44 (correct) Num items after deletion using mdb_del: 44 (correct) violino:~/OD/mdb/libraries/liblmdb> git log commit 8b46dcc26d1e9897ab1da3a4a164cad4a4479a52 Author: Howard Chu <hyc(a)openldap.org> Date: Sun Oct 4 01:56:25 2015 +0100 ITS#8258 fix rebalance/split The tree height can also increase during rebalance, not just shrink. This can happen if update_key needs to split a parent branch page. -- -- 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#8264) LMDB mdb_del in a cursor causes data loss in certain situations
by malyn＠strangeGizmo.com 05 Oct '15

05 Oct '15

Full_Name: Michael Alyn Miller Version: LMDB 0.9.14, Git head OS: Windows 8.1 x64, NixOS 14.12 x64 URL: ftp://ftp.openldap.org/incoming/michael-alyn-miller-151005.c Submission from: (NULL) (96.251.78.237) I have a helper library that sits on top of LMDB and testing some of the abstractions in that library has exposed a bug in LMDB related to deleting items while inside of a cursor. I have reduced the repro down to a test case that operates directly against LMDB. The test in question adds three groups of keys to the database (each with a different prefix) and then deletes the third group of keys. The deletion is done by scanning all of the keys with that prefix using a cursor. mdb_cursor_del works correctly and deletes only the targeted keys, whereas mdb_del causes nine extra keys (not in that group/prefix) to be deleted. Note that most of my test runs (with different test data) do not exhibit this behavior: the targeted keys, and only the targeted keys, are deleted as expected. Something about these specific keys and values triggers the bug. I assume that other keys will also trigger the bug, but these are the ones that I have converted into an LMDB-based test. The referenced test runs twice: once with mdb_cursor_del and once with mdb_del. You can mdb_dump the data before and after each deletion to see the extra keys that are being removed. The incorrectly deleted keys are all consecutive and begin with 02000000000000003a; the nine keys after and including 02...3aa4... are the ones that are incorrectly deleted. Only keys beginning with 03000000000000003a should have been deleted (so it is interesting to note that the nine keys immediately preceding the targeted keys were the ones that were incorrectly deleted). Is it valid to delete keys with mdb_del while inside of a cursor? If not, then ignore this bug report and I will modify my helper library. That said, I do expose more than just delete to my callers during cursor scans (they can mdb_put new items during a scan), which is why my library uses mdb_del and not mdb_cursor_del in this scenario. I have tested this code against LMDB 0.9.14 and Git head 8b46dcc. Please let me know if you need any additional information. Thank you for your time!

1 0

(ITS#8263) Broken cursor tracking in mdb_cursor_put()
by h.b.furuseth＠usit.uio.no 04 Oct '15

04 Oct '15

Full_Name: Hallvard B Furuseth Version: mdb.master, 8b46dcc26d1e9897ab1da3a4a164cad4a4479a52 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-151005.c Submission from: (NULL) (81.191.45.5) Submitted by: hallvard The test program catches several cursor tracking bugs. $ ./a.out 250 mn_flags = 0 mn_flags = 4 mn_flags = 4 a.c:36: run: Assertion `d1.mv_size == ksz && d1.mv_data == d2.mv_data' failed. Aborted $ ./a.out 500 mn_flags = 0 mn_flags = 4 mn_flags = 6 a.c:36: run: Assertion `d1.mv_size == ksz && d1.mv_data == d2.mv_data' failed. Aborted $ ./a.out 1000 mn_flags = 0 mn_flags = 6 a.c:34: mdb_cursor_get(c1, &k1, &d1, MDB_GET_CURRENT): Invalid argument Aborted It works when the DUPSORT sub-DB is created immediately: $ ./a.out 1500 mn_flags = 6 <repeated 22 times>

1 0

Re: (ITS#8258) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by hyc＠symas.com 03 Oct '15

03 Oct '15

hyc(a)symas.com wrote: > steven.lang(a)hgst.com wrote: >> Full_Name: Steven Lang >> Version: LMDB 0.9.16 >> OS: Ubuntu 14.04 >> URL: ftp://ftp.openldap.org/incoming/steven-lang-150929.c >> Submission from: (NULL) (199.255.44.5) >> >> >> While doing some testing using randomized key and data lengths and random puts >> and deletes, I found a situation in which mdb_cursor_del(...) followed by >> mdb_cursor_get(..., MDB_NEXT) causes an error: >> >> mdb.c:5726: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() >> Aborted >> Attached is a program which fills a DB, then deletes keys until it asserts. > > Thanks for the report. Our alternate approach to solve #8221 was to check the > page fill factor including the (usually omitted) key #0 size; we didn't go > that way because it was slightly more processing. But given this bug, it seems > that's the only way to go. > Fixed now in git, thanks. -- -- 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#8260) Test "test062-config-delete" occasionally runs intosegmentation fault
by hyc＠symas.com 02 Oct '15

02 Oct '15

hguo(a)suse.com wrote: > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. Only plaintext emails should be used here. > > ---1609925821-2101104869-1443783301=:2873 > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 8BIT > > Hello Michael. > > The bug can be triggered not only on master, but on the released versions 2.4.41 and 2.4.42 as well. test062 is not included in OpenLDAP 2.4. Running it against 2.4 is invalid. This is a dup of ITS#7639. Closing this ITS. > Regards, > Howard > > On Thu, 1 Oct 2015, Michael StrÃ¶der wrote: > >> Howard, >> >> hguo(a)suse.com wrote: >>> The test case "test062-config-delete" occasionally runs into segfault when >>> running with BDB backend. The chance of segfault happening is about once every >>> 200 runs. >>> >>> The version of OpenLDAP is post-2.4.42 master checked out at revision >>> 94d6581b50fa2d877cf4a1e20ca6766454094ef8, simply compiled with make. >> >> To me this revision seems to be from master branch. Are you sure you want to >> test that? Or are you rather looking for testing OPENLDAP_REL_ENG_2_4 branch? >> >> Also note that back-bdb is highly deprecated and IIRC building it will be >> disabled in OpenLDAP 2.5 (which is AFAIK what master branch is heading to). >> >> Ciao, Michael. >> . >> > ---1609925821-2101104869-1443783301=:2873-- > > > > -- -- 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#8260) Test "test062-config-delete" occasionally runs intosegmentation fault
by leo＠yuriev.ru 02 Oct '15

02 Oct '15

This issue fixed in ReOpenLDAP. https://github.com/ReOpen/ReOpenLDAP/issues/45 2015-10-02 13:55 GMT+03:00 <hguo(a)suse.com>: > This message is in MIME format. The first part should be readable text= , > while the remaining parts are likely unreadable without MIME-aware tool= s. > > ---1609925821-2101104869-1443783301=3D:2873 > Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed > Content-Transfer-Encoding: 8BIT > > Hello Michael. > > The bug can be triggered not only on master, but on the released versions= 2.4.41 and 2.4.42 as well. > > Regards, > Howard > > On Thu, 1 Oct 2015, Michael Str=C3=B6der wrote: > >> Howard, >> >> hguo(a)suse.com wrote: >>> The test case "test062-config-delete" occasionally runs into segfault w= hen >>> running with BDB backend. The chance of segfault happening is about onc= e every >>> 200 runs. >>> >>> The version of OpenLDAP is post-2.4.42 master checked out at revision >>> 94d6581b50fa2d877cf4a1e20ca6766454094ef8, simply compiled with make. >> >> To me this revision seems to be from master branch. Are you sure you wan= t to >> test that? Or are you rather looking for testing OPENLDAP_REL_ENG_2_4 br= anch? >> >> Also note that back-bdb is highly deprecated and IIRC building it will b= e >> disabled in OpenLDAP 2.5 (which is AFAIK what master branch is heading t= o). >> >> Ciao, Michael. >> . >> > ---1609925821-2101104869-1443783301=3D:2873-- > > >

1 0

Re: (ITS#8260) Test "test062-config-delete" occasionally runs intosegmentation fault
by hguo＠suse.com 02 Oct '15

02 Oct '15

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609925821-2101104869-1443783301=:2873 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Hello Michael. The bug can be triggered not only on master, but on the released versions 2.4.41 and 2.4.42 as well. Regards, Howard On Thu, 1 Oct 2015, Michael Ströder wrote: > Howard, > > hguo(a)suse.com wrote: >> The test case "test062-config-delete" occasionally runs into segfault when >> running with BDB backend. The chance of segfault happening is about once every >> 200 runs. >> >> The version of OpenLDAP is post-2.4.42 master checked out at revision >> 94d6581b50fa2d877cf4a1e20ca6766454094ef8, simply compiled with make. > > To me this revision seems to be from master branch. Are you sure you want to > test that? Or are you rather looking for testing OPENLDAP_REL_ENG_2_4 branch? > > Also note that back-bdb is highly deprecated and IIRC building it will be > disabled in OpenLDAP 2.5 (which is AFAIK what master branch is heading to). > > Ciao, Michael. > . > ---1609925821-2101104869-1443783301=:2873--

1 0

(ITS#8262) libldap API enhancement
by hyc＠openldap.org 01 Oct '15

01 Oct '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.211.141.184) Submitted by: hyc libldap has always (since initial commit) had an ldap_build_search_request() function which constructs the ber of the request message. This ber can then be sent to a server using ldap_send_initial_request(). Corresponding build* functions are missing for all of the other request types. There doesn't appear to be a good reason for this inconsistency, and it would be useful to be able to handle all request types the same way. In particular, it's useful for a caller to know the messageID of the new request before attempting to send it over the wire. This would make a number of issues in back-ldap/back-meta easier to deal with.

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