- openldap-bugs - openldap.org

[Issue 8590] LMDB: Suppress SIGPIPE in mdb_env_copythr on OS X
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=8590 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED Resolution|TEST |FIXED -- 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 07 Aug '26

07 Aug '26

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

1 0

[Issue 9388] New: mdb_stat for DupSort DBI shows incorrect data
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9388 Issue ID: 9388 Summary: mdb_stat for DupSort DBI shows incorrect data Product: LMDB Version: 0.9.26 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: AskAlexSharov(a)gmail.com Target Milestone: --- It doesn't include pages pages used for values. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10557] slapo-chain installs an attacker-authored referral DN into a privileged operation on the trusted server
by openldap-its＠openldap.org 06 Aug '26

06 Aug '26

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

1 0

[Issue 10555] New: When configuring from static libcrypto.a and libssl.a, it errors: can't find openssl. To fix openssl static linking, just add -lpthread to the linker.
by openldap-its＠openldap.org 04 Aug '26

04 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10555 Issue ID: 10555 Summary: When configuring from static libcrypto.a and libssl.a, it errors: can't find openssl. To fix openssl static linking, just add -lpthread to the linker. Product: OpenLDAP Version: 2.6.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: bee(a)mailsac.com Target Milestone: --- I am a newbie. Took 2 days to talk with ChatGPT and Gemini to analyze, configure, and config.log files. When configuring from static libcrypto.a and libssl.a, it errors: can't find openssl. To fix openssl static linking, just add -lpthread to the linker. ./configure \ --prefix=$HOME \ --enable-static \ --disable-shared \ --disable-debug \ --disable-dynamic \ --disable-syslog \ --disable-local \ --disable-slapd \ --enable-ipv6 \ --with-tls=openssl \ --without-cyrus-sasl \ --without-systemd \ --without-fetch \ --without-threads \ --without-yielding-select \ --without-mp \ --without-odbc \ --without-argon2 \ LIBS="-lpthread" # add -lpthread to fix openssl static linking -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10552] New: LMDB database getting corrupted
by openldap-its＠openldap.org 03 Aug '26

03 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10552 Issue ID: 10552 Summary: LMDB database getting corrupted Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: donxenapo(a)gmail.com Target Milestone: --- We have deployed LMDB version 1.0.0 and we're getting corruption-type errors from some users. We don't have the exact number of affected users yet, but apparently deleting the database and recreating it seems to work around the issue. The error seems to happen either during a get or a put request, and once the database is corrupted, it will keep resulting in the same error for that user until the database is purged/recreated. Here are some examples of errors that we're getting: During Put: LMDB Put Failed Error: MDB_PROBLEM: Unexpected problem - txn should abort LMDB Put Failed Error: MDB_CORRUPTED: Located page was wrong type LMDB Put Failed Error: MDB_PAGE_NOTFOUND: Requested page not found During Get: LMDB Get Failed Error: MDB_PAGE_NOTFOUND: Requested page not found LMDB Get Failed Error: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid Sometimes it crashes during Put in memcpy, instead of returning an error. Call stack: memcpy(void) mdb_cursor_get mdb_txn_begin We're still in the process of collecting corrupted databases from our users, so we don't have any corruption examples yet. -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 8112] man pages suggest using deprecated fuctions
by openldap-its＠openldap.org 31 Jul '26

31 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=8112 --- Comment #6 from Howard Chu <hyc(a)openldap.org> --- (In reply to Quanah Gibson-Mount from comment #4) > Need to cross reference if they are deprecated in the LDAP v3 RFC, and > whether or not the alternatives are usable. (In reply to Quanah Gibson-Mount from comment #5) > See c7338f5cdd for history of this. The last API draft is dated 17 November 2000, while the above referenced commit is from 2006. These functions were not deprecated in the last draft, but it looks like they were intended to be, by 2006. Nothing in the current source tree uses ldap_explode_rdn (other than the libldap/dntest program). I think we should note they're deprecated in the manpage, and #ifdef them appropriately now. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10547] New: PLeas change company name and url under Support
by openldap-its＠openldap.org 21 Jul '26

21 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10547 Issue ID: 10547 Summary: PLeas change company name and url under Support Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: info(a)allskills-training.com Target Milestone: --- Hallo, we are listed as Support/Training Center under: https://www.openldap.org/support/ We are named formerly (old name): SMLAN Software & Management Training New Company Name (changed): allskills Training Link to our Website - OpenLDAP Training: https://www.allskills-training.com/seminarthemen/alle/ldap-directory-servic… Pleas can you change our Company name and Website-URL. Thanks for your help and greetings from germany Guenter -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10544] New: slapd-bind parses the -B search URL but neither uses nor frees it
by openldap-its＠openldap.org 21 Jul '26

21 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10544 Issue ID: 10544 Summary: slapd-bind parses the -B search URL but neither uses nor frees it Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: 1489378385(a)qq.com Target Milestone: --- URL: https://github.com/openldap/openldap/blob/8afcbe9e04f1a40f03cea51c57418b05f… Description: Source revision: 8afcbe9e04f1a40f03cea51c57418b05f86e8f44 Affected file: tests/progs/slapd-bind.c Affected lines: 98, 116-143, and 182-190 Source-level observation: When -B search=<LDAP URL> is supplied, ldap_url_parse() allocates an LDAPURLDesc and stores it in extra_ludp. After parsing, extra_ludp is not referenced again. In particular, the calls to do_base() and do_bind() pass an action type of -1 and an action pointer of NULL instead of passing TESTER_SEARCH and extra_ludp. The descriptor is also not released before exit(EXIT_SUCCESS). Steps to verify: 1. Build slapd-bind with AddressSanitizer or LeakSanitizer. 2. Run slapd-bind with the required connection arguments and a valid option such as: -B 'search=ldap:///dc=example,dc=com??sub?(objectClass=*)' 3. Allow the tester to complete normally. 4. Check whether the requested search action is performed. 5. Inspect the sanitizer report for the LDAPURLDesc allocated by ldap_url_parse(). Actual result: The URL is successfully parsed, but the resulting descriptor is neither used by the bind operation nor released before the process exits. Expected result: The parsed search action should be passed to the relevant test operation and the LDAPURLDesc should be released after the outer test loop completes. Impact: The -B search option appears to have no effect and leaves one LDAPURLDesc allocated until process termination. Validation status: Confirmed by source review at the revision above. Runtime behavior and sanitizer validation are pending. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10358] New: syncrepl can revert an entry's CSN
by openldap-its＠openldap.org 20 Jul '26

20 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10358 Issue ID: 10358 Summary: syncrepl can revert an entry's CSN Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Created attachment 1080 --> https://bugs.openldap.org/attachment.cgi?id=1080&action=edit Debug log of an instance of this happening There is a sequence of operations which can force a MPR node to apply changes out of order (essentially reverting an operation). Currently investigating which part of the code that should have prevented this has let it slip. A sample log showing how this happened is attached. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10537] New: Short writes not handled, causing error on commit
by openldap-its＠openldap.org 14 Jul '26

14 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10537 Issue ID: 10537 Summary: Short writes not handled, causing error on commit Product: LMDB Version: 0.9.35 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: github(a)nicwatson.org Target Milestone: --- The default max value length in LMDB is MAXDATASIZE == 4GiB - 1. The maximum single write/pwrite on Linux is 0x7ffff000 (2GiB - 4096) (see https://man7.org/linux/man-pages/man2/write.2.html). Writes larger than that return EIO. When an attempt is to commit a transaction with a value with length larger than 0x7ffff000 and less than 4 GiB, the commit fails with rc=5. The current code bails on EIO when it needs to loop and continue to write. Here's a reproducer: --- #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/stat.h> #include "lmdb.h" #define CHK(expr) do { int rc_ = (expr); if (rc_) { \ fprintf(stderr, "%s:%d: %s: %s\n", __FILE__, __LINE__, #expr, \ mdb_strerror(rc_)); return 2; } } while (0) int main(int argc, char **argv) { const char *dir = argc > 1 ? argv[1] : "./lw-repro-db"; /* 2.25 GiB: one overflow page whose single write exceeds the ~2 GiB * per-call limit (0x7ffff000). */ const size_t VALSIZE = (size_t)0x90000000UL; MDB_env *env; MDB_txn *txn; MDB_dbi dbi; MDB_val key, val, got; char *buf; int rc; mkdir(dir, 0755); buf = (char *)malloc(VALSIZE); if (!buf) { fprintf(stderr, "malloc(%zu) failed\n", VALSIZE); return 2; } memset(buf, 'x', VALSIZE); memcpy(buf, "HEAD", 4); memcpy(buf + VALSIZE - 4, "TAIL", 4); CHK(mdb_env_create(&env)); CHK(mdb_env_set_mapsize(env, VALSIZE + (512UL << 20))); CHK(mdb_env_open(env, dir, 0, 0664)); CHK(mdb_txn_begin(env, NULL, 0, &txn)); CHK(mdb_dbi_open(txn, NULL, 0, &dbi)); key.mv_data = (void *)"big"; key.mv_size = 3; val.mv_data = buf; val.mv_size = VALSIZE; CHK(mdb_put(txn, dbi, &key, &val, 0)); rc = mdb_txn_commit(txn); if (rc) { fprintf(stderr, "BUG REPRODUCED: mdb_txn_commit failed: %s (rc=%d)\n", mdb_strerror(rc), rc); mdb_env_close(env); free(buf); return 1; } /* Verify the value round-trips without truncation. */ CHK(mdb_txn_begin(env, NULL, MDB_RDONLY, &txn)); CHK(mdb_get(txn, dbi, &key, &got)); if (got.mv_size != VALSIZE || memcmp(got.mv_data, "HEAD", 4) != 0 || memcmp((char *)got.mv_data + VALSIZE - 4, "TAIL", 4) != 0) { fprintf(stderr, "BUG: value corrupt/truncated: got %zu of %zu bytes\n", got.mv_size, VALSIZE); mdb_txn_abort(txn); mdb_env_close(env); free(buf); return 1; } mdb_txn_abort(txn); mdb_env_close(env); free(buf); printf("OK: committed and read back %zu-byte value intact\n", VALSIZE); return 0; } -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 6104] race condition with cancel operation
by openldap-its＠openldap.org 14 Jul '26

14 Jul '26

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

1 0

[Issue 10054] New: Value size limited to 2,147,479,552 bytes
by openldap-its＠openldap.org 12 Jul '26

12 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10054 Issue ID: 10054 Summary: Value size limited to 2,147,479,552 bytes Product: LMDB Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: louis(a)meilisearch.com Target Milestone: --- Hello, According to the documentation[0], a database that is not using `MDB_DUPSORT` can store values up to `0xffffffff` bytes (around 4GB). In practice, under Linux, the actual limit is `0x7ffff000` though (2^31 - 4096, so around 2GB). This is due to the write loop in `mdb_page_flush`. The `wsize` value determining how many bytes will be written can be as big as `4096*dp->mp_pages`[1], and the number of overflow pages grows with the size of the value put inside the DB. The `wsize` is not split in smaller chunks in the case where there are many overflow pages to write, and as a result the call to `pwrite`[2] does not perform a full write, but only a "short" write of 2147479552 bytes (the maximum allowed on a call to `pwrite` on Linux[3]). This would be OK if the short write condition was handled by looping and performing another `pwrite` with the rest of the data, but instead `EIO` is returned[4]. There seems to be a related, but different issue on macOS when trying to `pwrite` more the 2^31 bytes, that was already reported[5]. This issue was reported to me by a Meilisearch user because it causes their database indexing to fail[6]. I had to investigate a bit because their setup was peculiar (high number of documents in their database) and the `EIO` error code is not very descriptive of the underlying issue. I join a C reproducer of the issue that attempts to add a 2147479553 bytes value to the DB and fails with `EIO` (decreasing `nb_items` to a smaller value such as `2107479552` does succeed)[7]. Thank you for making LMDB! Louis Dureuil. [0]: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/lmdb.h#LL284… [1]: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#LL3770… [2]: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#L3820 [3]: https://stackoverflow.com/questions/70368651/why-cant-linux-write-more-than… [4]: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#L3840 [5]: https://bugs.openldap.org/show_bug.cgi?id=9736 [6]: https://github.com/meilisearch/meilisearch/issues/3654 [7]: https://github.com/dureuill/lmdb_3654/tree/main -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 8174] mdb_drop(,MAIN_DBI,) leaks pages of named DBs
by openldap-its＠openldap.org 09 Jul '26

09 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=8174 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=10536 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8174] mdb_drop(,MAIN_DBI,) leaks pages of named DBs
by openldap-its＠openldap.org 09 Jul '26

09 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=8174 --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- (In reply to Vladimir Cunat from comment #4) > FYI, blocking the transaction after mdb_drop isn't great. Some projects got > caught by that: postfix, knot-dns, knot-resolver (I didn't search > specifically, so maybe more). > > Personally I find it useful to clear the whole DB and fill new contents, all > within a single RW transaction (so that noone sees the WIP state during that > rewrite). But I guess everyone will have to try to find some workarounds > now... This particular behavior probably should be reverted, will look at it for v1.0.1. Affected applications should stick to LMDB v0.9 in the meantime. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8174] mdb_drop(,MAIN_DBI,) leaks pages of named DBs
by openldap-its＠openldap.org 08 Jul '26

08 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=8174 --- Comment #4 from Vladimir Cunat <vladimir.cunat(a)nic.cz> --- FYI, blocking the transaction after mdb_drop isn't great. Some projects got caught by that: postfix, knot-dns, knot-resolver (I didn't search specifically, so maybe more). Personally I find it useful to clear the whole DB and fill new contents, all within a single RW transaction (so that noone sees the WIP state during that rewrite). But I guess everyone will have to try to find some workarounds now... -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Bug 9223] New: Add support for incremental backup
by openldap-its＠openldap.org 30 Jun '26

30 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=9223 Bug ID: 9223 Summary: Add support for incremental backup Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For LMDB 1.0, add support for incremental backups -- You are receiving this mail because: You are on the CC list for the bug.

1 6

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

30 Jun '26

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

1 0

[Issue 10518] New: Every write transaction leaks a mutex on Windows
by openldap-its＠openldap.org 30 Jun '26

30 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10518 Issue ID: 10518 Summary: Every write transaction leaks a mutex on Windows Product: LMDB Version: unspecified Hardware: x86_64 OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: bhargavabhat(a)gmail.com Target Milestone: --- Created attachment 1152 --> https://bugs.openldap.org/attachment.cgi?id=1152&action=edit Create and use the mutex for the duration of the env I see that on master3 branch, every write transaction leaks a mutex. LMDB creates a new mutex on every non-read-only transaction in `mdb_txn_renew0`. In `mdb_txn_end`, when the write transaction finishes, it sets `mode` to 0 and unlocks it. ``` if (!txn->mt_parent) { env->me_txn = NULL; mode = 0; if (env->me_txns) UNLOCK_MUTEX(env->me_wmutex); } ``` Later, it does this. ``` if (mode & MDB_END_FREE) { if (!F_ISSET(txn->mt_flags, MDB_TXN_RDONLY)) pthread_mutex_destroy(&txn->mt_child_mutex); // never reached free(txn); } ``` So we just don't close the mutex. It's probably not a big deal on non-Windows platforms, but on Windows, the number of handles owned by the process keeps increasing which limits the total number of write transactions we can do in the lifetime of the process. I didn't really understand why we need to create a mutex on every non-read-only transaction. Can we just tie the lifetime of the mutex to the environment instead of the transaction? I'm attaching a patch which tries to fix it. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 8174] mdb_drop(,MAIN_DBI,) leaks pages of named DBs
by openldap-its＠openldap.org 30 Jun '26

30 Jun '26

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

1 0

[Issue 8988] Undefined Behavior in slapadd
by openldap-its＠openldap.org 30 Jun '26

30 Jun '26

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

1 0

[Issue 8324] LMDB - grow file incrementally on Windows
by openldap-its＠openldap.org 30 Jun '26

30 Jun '26

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

1 0

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

30 Jun '26

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

1 0

[Issue 8209] Broken MDB_CP_COMPACT threading
by openldap-its＠openldap.org 30 Jun '26

30 Jun '26

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

1 0

[Issue 8704] LMDB add option to use prev meta page
by openldap-its＠openldap.org 30 Jun '26

30 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=8704 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED -- 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