openldap-bugs

openldap-bugs@openldap.org

1 participants
21518 discussions

[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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs