- openldap-bugs - openldap.org

[Issue 7794] RFE: Versioned LMDB shared library
by openldap-its＠openldap.org 06 May '26

06 May '26

https://bugs.openldap.org/show_bug.cgi?id=7794 --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- mdb.master3: • 43670420 by Howard Chu at 2026-04-22T11:26:00+01:00 ITS#8165 LMDB: add soname, lib version • 0734803d by Howard Chu at 2026-04-22T12:45:11+01:00 ITS#8165 more for prev commit -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8165] Add proper versioning to liblmdb
by openldap-its＠openldap.org 06 May '26

06 May '26

https://bugs.openldap.org/show_bug.cgi?id=8165 --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- mdb.master3: • 43670420 by Howard Chu at 2026-04-22T11:26:00+01:00 ITS#8165 LMDB: add soname, lib version • 0734803d by Howard Chu at 2026-04-22T12:45:11+01:00 ITS#8165 more for prev commit -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10275] New: mdb_load could use a parameter to pass batch size
by openldap-its＠openldap.org 06 May '26

06 May '26

https://bugs.openldap.org/show_bug.cgi?id=10275 Issue ID: 10275 Summary: mdb_load could use a parameter to pass batch size Product: LMDB Version: 0.9.21 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: tools Assignee: bugs(a)openldap.org Reporter: gkwicker(a)amazon.com Target Milestone: --- Created attachment 1037 --> https://bugs.openldap.org/attachment.cgi?id=1037&action=edit Patch to mdb_load.c in version 0.9.21 mdb_load is very slow when ingesting a large db. The attached patch (0.9.21 but will apply to other versions with modification) allows the user to pass a batch size to be used instead of the default value of 100. Changing the batch size to a larger value improves ingestion speed. I, Gary Wicker, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- You are receiving this mail because: You are on the CC list for the issue.

1 23

[Issue 6462] DNS SRV records: ldaps ???
by openldap-its＠openldap.org 06 May '26

06 May '26

https://bugs.openldap.org/show_bug.cgi?id=6462 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |TEST --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • ed30d827 by Ondřej Kuzník at 2026-04-16T02:13:15+00:00 ITS#6462 libldap: Add ldap_domain2hostlist_proto • 3ebfd3e8 by Ondřej Kuzník at 2026-04-16T02:13:15+00:00 ITS#6462 clients: Enable DNS SRV resolution for ldaps connections • 69c2a54b by Ondřej Kuzník at 2026-04-16T02:13:15+00:00 ITS#6462 slapd-dnssrv: Enable DNS SRV resolution for ldaps -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8739] Better check for fsync on FreeBSD
by openldap-its＠openldap.org 06 May '26

06 May '26

https://bugs.openldap.org/show_bug.cgi?id=8739 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- mdb.RE/0.9: • 856c1fa8 by Howard Chu at 2026-04-15T20:04:30+01:00 ITS#8739 lmdb: No fdatasync on FreeBSD 11.0 and older mdb.master: • f759f0fc by Howard Chu at 2026-04-15T20:03:57+01:00 ITS#8739 lmdb: No fdatasync on FreeBSD 11.0 and older mdb.master3: • b2cfdd23 by Howard Chu at 2026-04-15T20:03:06+01:00 ITS#8739 lmdb: No fdatasync on FreeBSD 11.0 and older -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8824] openldap-2.4.46/libraries/liblmdb/mdb_dump.c:136]: (style) Suspicious condition
by openldap-its＠openldap.org 06 May '26

06 May '26

https://bugs.openldap.org/show_bug.cgi?id=8824 --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- mdb.RE/0.9: • 790035a2 by Howard Chu at 2026-04-15T18:18:39+01:00 ITS#8824 mdb_dump: cleanup check for MDB_SUCCESS mdb.master: • 331ba439 by Howard Chu at 2026-04-15T18:17:55+01:00 ITS#8824 mdb_dump: cleanup check for MDB_SUCCESS mdb.master3: • 5b3df476 by Howard Chu at 2026-04-15T18:18:44+01:00 ITS#8824 mdb_dump: cleanup check for MDB_SUCCESS -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8386] Small LMDB Documentation patch
by openldap-its＠openldap.org 06 May '26

06 May '26

https://bugs.openldap.org/show_bug.cgi?id=8386 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- mdb/RE0.9: • 9a647381 by Philipp Storz at 2026-04-15T17:32:58+01:00 ITS#8386 lmdb: be a bit more precise that mdb_get retrieves data in intro.doc mdb.master: • 7b5ffe1b by Philipp Storz at 2026-04-15T17:32:14+01:00 ITS#8386 lmdb: be a bit more precise that mdb_get retrieves data in intro.doc mdb.master3: • 06680017 by Philipp Storz at 2026-04-15T17:33:05+01:00 ITS#8386 lmdb: be a bit more precise that mdb_get retrieves data in intro.doc -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9011] add mdb_txn_flags()
by openldap-its＠openldap.org 04 May '26

04 May '26

https://bugs.openldap.org/show_bug.cgi?id=9011 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- Added to git mdb.master3, mdb.RE/1.0 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9011] add mdb_txn_flags()
by openldap-its＠openldap.org 03 May '26

03 May '26

https://bugs.openldap.org/show_bug.cgi?id=9011 --- Comment #4 from code(a)doriantaylor.com --- I was trying to determine why I got a notification for this bug, and I see now that it was because I filed a later one which was marked duplicate. Indeed, my remarks on issue 9188 constitute why a language binding would need to know if a transaction was read-only. In the Ruby bindings for LMDB which I now maintain, it's easy to find situations like db.transaction(true, &proc) # `true` enables read-only ...where `proc` itself does another transaction. I have semi-fixed this so read-only transactions "nest" by making the call a no-op if a transaction is already active, but it's still possible for read-write transactions to find their way inside read-only ones. So being able to create a `txn.readonly?` predicate would be useful for programmers downstream to better orient themselves. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8394] LMDB fails GCC5 without -fno-strict-aliasing
by openldap-its＠openldap.org 29 Apr '26

29 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8394 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|SUSPENDED |WORKSFORME -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8394] LMDB fails GCC5 without -fno-strict-aliasing
by openldap-its＠openldap.org 28 Apr '26

28 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8394 --- Comment #8 from bdallen(a)nps.edu <bdallen(a)nps.edu> --- Hi Howard, Please forgive me. Yes, I started this ten years ago on another project which was resolved. When I saw your new post https://bugs.openldap.org/show_bug.cgi?id=8394#c3 I assumed they were related. They are not. Good to hear you are still supporting LMDB. It worked very well for me. Cheers, -Bruce On 4/28/26 10:03, openldap-its(a)openldap.org wrote: > NPS WARNING: *external sender* verify before acting. > > > https://bugs.openldap.org/show_bug.cgi?id=8394 > > --- Comment #7 from Howard Chu <hyc(a)openldap.org> --- > (In reply to bdallen(a)nps.edu from comment #6) >> Hi Howard, >> >> I did not submit issue 8394. I suspect somebody in Pico Technical >> Support Team submitted this in my name in response to SUPPORT-63913 >> Crashing bug in pypicosdk that I submitted to support(a)picotech.com. I >> responded to you incorrectly believing I was working with Pico Technical >> Support. >> >> Meanwhile, I can offer some information: >> 1) You cannot reproduce this bug without having a PicoScope connected to >> a USB port and without "sudo apt install picoscope" per >> https://www.picotech.com/downloads/linux and without "pip install >> pypicosdk". >> 2) I would suspect the core dump reported is the result of object >> mismanagement in Python bindings in pypicosdk except that someone in >> Pico Technical Support has stated the fault is line 6590 of mdb.c. >> >> Please let me know if I can help. >> >> Regards, >> -Bruce > Thanks for the information. That initial report is from 10 years ago, and LMDB > v0.9.18 is long since obsolete. > > We're about to release v1.0.0. It would probably be worth seeing if you can > reproduce the problem with that release candidate. > https://git.openldap.org/openldap/openldap/-/tree/mdb.RE/1.0?ref_type=heads > > For what it's worth, using clang-20's -fsanitize=type sanitizer, it shows some > potential problems in v0.9.18 but it only gives false positives with the 1.0 > branch. > > -- > You are receiving this mail because: > You reported the issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8394] LMDB fails GCC5 without -fno-strict-aliasing
by openldap-its＠openldap.org 28 Apr '26

28 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8394 --- Comment #7 from Howard Chu <hyc(a)openldap.org> --- (In reply to bdallen(a)nps.edu from comment #6) > Hi Howard, > > I did not submit issue 8394. I suspect somebody in Pico Technical > Support Team submitted this in my name in response to SUPPORT-63913 > Crashing bug in pypicosdk that I submitted to support(a)picotech.com. I > responded to you incorrectly believing I was working with Pico Technical > Support. > > Meanwhile, I can offer some information: > 1) You cannot reproduce this bug without having a PicoScope connected to > a USB port and without "sudo apt install picoscope" per > https://www.picotech.com/downloads/linux and without "pip install > pypicosdk". > 2) I would suspect the core dump reported is the result of object > mismanagement in Python bindings in pypicosdk except that someone in > Pico Technical Support has stated the fault is line 6590 of mdb.c. > > Please let me know if I can help. > > Regards, > -Bruce Thanks for the information. That initial report is from 10 years ago, and LMDB v0.9.18 is long since obsolete. We're about to release v1.0.0. It would probably be worth seeing if you can reproduce the problem with that release candidate. https://git.openldap.org/openldap/openldap/-/tree/mdb.RE/1.0?ref_type=heads For what it's worth, using clang-20's -fsanitize=type sanitizer, it shows some potential problems in v0.9.18 but it only gives false positives with the 1.0 branch. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8394] LMDB fails GCC5 without -fno-strict-aliasing
by openldap-its＠openldap.org 28 Apr '26

28 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8394 --- Comment #6 from bdallen(a)nps.edu <bdallen(a)nps.edu> --- Hi Howard, I did not submit issue 8394. I suspect somebody in Pico Technical Support Team submitted this in my name in response to SUPPORT-63913 Crashing bug in pypicosdk that I submitted to support(a)picotech.com. I responded to you incorrectly believing I was working with Pico Technical Support. Meanwhile, I can offer some information: 1) You cannot reproduce this bug without having a PicoScope connected to a USB port and without "sudo apt install picoscope" per https://www.picotech.com/downloads/linux and without "pip install pypicosdk". 2) I would suspect the core dump reported is the result of object mismanagement in Python bindings in pypicosdk except that someone in Pico Technical Support has stated the fault is line 6590 of mdb.c. Please let me know if I can help. Regards, -Bruce -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8394] LMDB fails GCC5 without -fno-strict-aliasing
by openldap-its＠openldap.org 28 Apr '26

28 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8394 --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- (In reply to bdallen(a)nps.edu from comment #4) > Here is the code I used which generates the core dump in round 2. It > should complete 10 rounds then say "Done.": > > import pypicosdk as psdk > > def test(n): > print(n, "checkpoint.a") > scope = psdk.psospa() > print(n, "checkpoint.b") > scope.open_unit() > print(n, "checkpoint.c") > scope.close_unit() > print(n, "checkpoint.d") > > if __name__ == "__main__": > for i in range(1, 11): > test(i) > print("Done.") > > I have no idea how to install pypicosdk. You're going to have to provide sufficient info for someone to actually reproduce the software you're running. What I see here https://github.com/picotech/pyPicoSDK " Go to PicoTech downloads picotech.com/downloads Find your PicoScope in the list and click through Download and install PicoSDK for your operating system " Since I have no PicoScope I have no idea what to install. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8335] MDB_MULTIPLE issues
by openldap-its＠openldap.org 27 Apr '26

27 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8335 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |TEST --- Comment #8 from Howard Chu <hyc(a)openldap.org> --- Fixed in git -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8335] MDB_MULTIPLE issues
by openldap-its＠openldap.org 27 Apr '26

27 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8335 --- Comment #7 from Howard Chu <hyc(a)openldap.org> --- Bryan Matsuo's post, for reference https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8502] mdb_cursor_count() == EINVAL for empty DB
by openldap-its＠openldap.org 27 Apr '26

27 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8502 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- Nothing worth changing here. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8916] MDB_VL32 in readonly causes MDB_CORRUPTED
by openldap-its＠openldap.org 27 Apr '26

27 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8916 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- The problem is that Windows doesn't let you use a readonly mapping that extends beyond the length of a file. This is noted in commit 5eb25c5cb9122fcc016e770bcc1f033e3a9d2a0f and 9d75a82ae10fdcee80b8b8e82c6ef9b6ab83dc47. Since the env is readonly we aren't expecting the file to grow. There's no provision for detecting that the underlying file is changing, in a readonly env. This is just a limitation of Windows so there's no workaround. Don't mix readonly envs with readwrite envs. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7772] liblmdb sub-page growth when adding existing data
by openldap-its＠openldap.org 27 Apr '26

27 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=7772 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|UNCONFIRMED |RESOLVED --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- fixed in git mdb.master3, mdb.master, mdb.RE/0.9 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7974] LDBM's "laggard reader" flaw still present, in continue of ITS#7904
by openldap-its＠openldap.org 26 Apr '26

26 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=7974 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #8 from Howard Chu <hyc(a)openldap.org> --- Fixing this implicitly inside LMDB is the wrong place. The calling app has to make the decision whether they can cope with breaking an atomic read txn into multiple pieces or not. Most applications that take a read txn expect it to stay atomic for the entire duration of their operation. Likewise, the calling apps are the only ones that can decide whether it's safe to kill any of their processes. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9360] New: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid
by openldap-its＠openldap.org 26 Apr '26

26 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=9360 Issue ID: 9360 Summary: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: spam(a)markandruth.co.uk Target Milestone: --- I have 2 python scripts writing to a database (lmdb 0.9.26, py-lmdb 0.98) and 5-10 lua processes (with lightningmdb module which uses lmdb 0.9.22) which are long-running serving queries from the database. The database seems fine, not corrupted, and the python writes still working all the time. But periodically (perhaps 10-20% of the time), in a way I am unable to reliably reproduce, when the lua starts up every time a query is issued txn dbi_open returns "MDB_BAD_TXN: Transaction must abort, has a child, or is invalid". A direct restart of the processes does not fix this issue, however stopping lua+python and then starting again after a 5-20s wait usually fixes the issue. This has been reproduced over multiple servers but I'm at a loss as to how to debug this any further? -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 8748] New feature for LMDB
by openldap-its＠openldap.org 26 Apr '26

26 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8748 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX Severity|normal |enhancement --- Comment #7 from Howard Chu <hyc(a)openldap.org> --- No substantial benefit - the caller should only be attempting to write because they have data that they need to persist. There is nothing useful they can do in the meantime if the txn_begin returns "this would block". -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8250] Allowing transaction to be created in the reset state
by openldap-its＠openldap.org 26 Apr '26

26 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8250 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9011] add mdb_txn_flags()
by openldap-its＠openldap.org 25 Apr '26

25 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=9011 --- Comment #3 from christopher(a)gmerlin.de <christopher(a)gmerlin.de> --- I don't remember the exact reason why I needed this function. But I can offer general remarks. OCaml is a strictly statically typed language. The lmdb binding attaches phantom types to the lmdb data types: a rw/ro type variable to transactions and a dup/nodup type variable to databases. This allows catching some errors like writes with a read-only transaction at compile time. A possible use of mdb_txn_flags() could be to check an _runtime_ that those invariants are not broken when a raw transaction handle (without phantom types) is imported into the typed binding. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8250] Allowing transaction to be created in the reset state
by openldap-its＠openldap.org 24 Apr '26

24 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8250 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |--- Status|RESOLVED |UNCONFIRMED --- Comment #6 from Howard Chu <hyc(a)openldap.org> --- (In reply to Howard Chu from comment #5) > Added to mdb.master3 4cd8e451679511c8fbeff68f8a97cbe7b1268b48 > > Please test. Then again, will probably revert this. It adds several lines of code to a core function, all to avoid 2 lines of code in the caller. It doesn't make sense to do this. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs