- openldap-bugs - openldap.org

[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

[Issue 8803] [PATCH] Add -L option for using external locking
by openldap-its＠openldap.org 24 Apr '26

24 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8803 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Severity|normal |enhancement Status|UNCONFIRMED |RESOLVED --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- Added to mdb.master3 in 7a1f36d51a27a8b638e470551cff99302cfa5048 -- 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 ---------------------------------------------------------------------------- Severity|normal |enhancement -- 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 ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |TEST --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- Added to mdb.master3 4cd8e451679511c8fbeff68f8a97cbe7b1268b48 Please test. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8361] mdb_strerror() issues
by openldap-its＠openldap.org 24 Apr '26

24 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8361 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Bug 9208] New: LMDB feature request: variant of mdb_env_copy{,fd2} that takes transaction as parameter
by openldap-its＠openldap.org 24 Apr '26

24 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=9208 Bug ID: 9208 Summary: LMDB feature request: variant of mdb_env_copy{,fd2} that takes transaction as parameter Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: github(a)nicwatson.org Target Milestone: --- The mdb_env_copy* functions create a read transaction themselves to run the backup on. New variants of these functions (one for mdb_env_copy2 and one for mdb_env_copyfd2) would have a transaction parameter. This transaction would be used instead of creating a new transaction. Application code could use these new functions to synchronize consistent live backups across multiple LMDB instances (potentially across multiple hosts). -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Issue 8361] mdb_strerror() issues
by openldap-its＠openldap.org 24 Apr '26

24 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8361 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- Unix case is a non-issue. libc only does the `sprintf(buf, "Error %d", err)` fallback for error codes it doesn't recognize. These only occur when an old libc is running on a newer kernel version (that happens to define new errno values). So in practice it only happens with extremely old statically linked binaries running on a much newer system. The Windows situation is a bit cleaner now that we're not using as many libc error codes. (ITS#8192). In most cases none of that will matter. Also most error messages are short, generally shorter than one 80 column line. Not worth worrying about. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8192] liblmdb confuses Windows error code with errno values
by openldap-its＠openldap.org 24 Apr '26

24 Apr '26

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

1 0

[Issue 8475] Feature request: MDB low durability transactions
by openldap-its＠openldap.org 23 Apr '26

23 Apr '26

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

1 0

[Issue 10034] New: Assertion 'i < NUMKEYS(mp)' failed in mdb_page_search_root()"
by openldap-its＠openldap.org 23 Apr '26

23 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10034 Issue ID: 10034 Summary: Assertion 'i < NUMKEYS(mp)' failed in mdb_page_search_root()" Product: LMDB Version: 0.9.23 Hardware: Other OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: 763280032(a)qq.com Target Milestone: --- We found that when lmdb is opened after OS startup and data is written to it, lmdb will trigger abort probabilistically(Restart the OS 600 times will trigger once); We want to know what situation triggers this issue(Assertion 'i < NUMKEYS(mp)' failed in mdb_page_search_root()); we want to know if there is a problem with our usage; Please Help Us (gdb) x/8s 0x8baee988 0x8baee988: "8\373Բ\b\371Բmdb.c:5542: Assertion 'i < NUMKEYS(mp)' failed in mdb_page_search_root()" -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 8813] MDB_VL32 causes MDB_TXN_FULL
by openldap-its＠openldap.org 23 Apr '26

23 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8813 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FEEDBACK --- Comment #7 from Howard Chu <hyc(a)openldap.org> --- (In reply to markus(a)greenrobot.de from comment #5) > On 24.10.19 03:49, Howard Chu wrote: > > You're free to define MDB_TRPAGE_MAX to a larger value. It just means > > you increase the chance of overrunning the 2GB available address space. > > There's no magic, you can't fit every 64bit database workload into only > > a 32bit address space. When your transactions are too large, the normal > > thing to do is commit more often so they don't grow so large. > > I think you meant MDB_TRPAGE_SIZE? At least that seemed to work, while > MDB_TRPAGE_MAX ended up in another MDB_TXN_FULL (tl[0].mid < > MDB_TRPAGE_SIZE check failed). > > Doubling MDB_TRPAGE_SIZE also doubled the threshold of the object count > where it starts failing: using 8192 it was able to remove 4M entries > while the limit with 4096 was 2M entries. > > MDB_TRPAGE_SIZE is only used to malloc txn->mt_rpages (and some checks), > as far as I can tell. > > To make a reasonable decision here, could you please confirm: > > 1. txn->mt_rpages is RAM only and has no impact on mmaped sections > (and/or file format). > > 2. RAM consumption is defined by number of transactions only: per > transaction MDB_TRPAGE_SIZE bytes is allocated. Other than that it does > not increase memory consumption. > > 3. There is no other disadvantage other than higher memory consumption > per transaction as written in the previous point. > > > In that case, I think I'll go with 16K (or even 32K). Does not seem too > much for an transaction, given that it quadruples the amount of data > allowed to be processed. 32 bit devices are not servers, so I do not > expect a high number of concurrent transactions anyway. > > Thanks! > > Markus Sorry for going quiet. Yes, to all 3 of your points, it only affects in-memory bookkeeping and has no effect on the file. The only consequence of increasing these constants is potentially higher memory consumption. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8579] LMDB: me_fd should be O_CLOEXEC on POSIX systems
by openldap-its＠openldap.org 23 Apr '26

23 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8579 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Target Milestone|--- |1.0.0 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- I see no reason not to do this. Some of the caveats about fork/exec are still overstated. LMDB uses fcntl() locks, not flock(), so some of the concerns about flock() semantics are irrelevant. There is nothing useful an exec'd process can do with the me_fd, so yes, let's close it. Fixed in mdb.master3 cf52db2bee52796bb4140b32679f4723a0d7d44f -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8691] slapd crashes during shutdown
by openldap-its＠openldap.org 23 Apr '26

23 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8691 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Howard Chu <hyc(a)openldap.org> --- Unable to reproduce this any more. "--without-threads" is no longer a supported configuration. OpenLDAP 2.6 has no trouble starting/stopping on Windows. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6198] Authorization for extensions
by openldap-its＠openldap.org 23 Apr '26

23 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=6198 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=10497 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8537] liblmdb errors with data=NULL and non-matching SET_KEY
by openldap-its＠openldap.org 23 Apr '26

23 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8537 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- Didn't see any crash in current mdb.master3, 9aa3ac00567db8d5222abea46325a8b882937350 I see EINVAL on case 9 with the test program, trying to use MDB_GET_CURRENT after and MDB_SET_KEY that returned MDB_NOTFOUND. This appears to be correct behavior, since the cursor isn't pointing at anything when MDB_NOTFOUND is returned. On the reported commit ID, the test program asserts on case 0, but that doesn't appear to be relevant any more. -- 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 23 Apr '26

23 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=9011 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- Why does a wrapper or binding care whether a txn is read-only or read-write? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8275] [PATCH 1/2] Add mdb_dbi_name() function to get database name from a handle
by openldap-its＠openldap.org 23 Apr '26

23 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8275 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #1 from Howard Chu <hyc(a)openldap.org> --- I don't see why this is necessary or useful. The caller supplied the name in the first place, why do they need to ask for it back? -- 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 22 Apr '26

22 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8502 --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- (In reply to Hallvard Furuseth from comment #0) > Full_Name: Hallvard B Furuseth > Version: mdb.master, 26e226b2a8cdba4208eabca394537900c4eda3b3 > OS: > URL: > Submission from: (NULL) (81.191.45.31) > Submitted by: hallvard > > > mdb_cursor_count() has code to return MDB_NOTFOUND if !mc_snum, > but it comes after if (! ... C_INITIALIZED) return EINVAL. It sounds like the NOTFOUND test should just be deleted then, because it's always unreachable. When a DB is emptied, all cursors on it are de-initialized since there is nothing for the cursors to point to. In an uninitialized cursor, none of the other state is meaningful, so mc->mc_snum is irrelevant. Changing the order of the tests would mean you get MDB_NOTFOUND even on a cursor on a non-empty DB, if it has never been used yet. Is that actually a more sensible result in that case? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8455] LMDB: mdb_env_copyfd1 leaks memory and pthread state if mdb_txn_begin fails
by openldap-its＠openldap.org 22 Apr '26

22 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8455 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Howard Chu <hyc(a)openldap.org> --- *** This issue has been marked as a duplicate of issue 8209 *** -- 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