openldap-bugs

openldap-bugs@openldap.org

1 participants
21513 discussions

[Issue 10541] New: syncrepl regression with older format of entryCSN
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10541 Issue ID: 10541 Summary: syncrepl regression with older format of entryCSN Product: OpenLDAP Version: 2.6.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: benp(a)reed.edu Target Milestone: --- We recently upgraded from openldap 2.6.10 to 2.6.13 (using debian packages from symas.com). Subsequent to the upgrade we noticed that syncrepl was sometimes failing to replicate changes to entries. It appears that the behavior is triggered when modifying an entry with an older style entryCSN (eg "entryCSN: 20210115230536Z#000001#00#000000" vs the current style "entryCSN: 20260715174316.844052Z#000000#001#000000"). The updated entry on the provider slapd gets a new entryCSN that uses the new format, but the consumer slapds don't process the changes made to the entry, and log a failed assertion (122) error like this: Jul 8 10:39:28 slapd-c daemon.info slapd[129831]: 6a3f4436.0d08671e 0x7f6d411fc6c0 syncrepl_entry: rid=011 be_modify uid=example-user,ou=People,dc=foo,dc=bar (122) Deleting the problematic entry on the provider and then recreating it tends to resolve the issue for us, presumably because the new entry has the normal non-obsolete contextCSN attribute. Our current production DB has ~22k entries, ~4k of which have older style contextCSNs, so we'd love to avoid having to delete and recreate those ~4k entries if we don't have to. We have entryCSNs in at least 3 different formats: entryCSN: 2003081423:11:31Z#0x000d#0#0000 entryCSN: 20230410142047Z#000000#00#000000 entryCSN: 20260313112653.221151Z#000000#001#000000 Our current configuration does not use accesslog, so replication is simple syncrepl (vs delta-syncrepl). It was suggested on the openldap-technical list that we consider filing an ITS about this issue. Please let me know what additional supporting information would be helpful. I'm not totally certain how to distill are slapd.d style config to something concise enough for the bug tracker. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10475] slapo-constraint URI mode fails to escape assertion values in internal catalog filters, enabling wildcard/filter-metachar allowlist bypass
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

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

1 0

[Issue 10539] New: LMDB 1.0.0 fails to compile on Windows
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10539 Issue ID: 10539 Summary: LMDB 1.0.0 fails to compile on Windows Product: LMDB Version: 1.0.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Various errors around use of LARGE_INTEGER -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10538] New: On Windows, a large value write can get silently lost
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10538 Issue ID: 10538 Summary: On Windows, a large value write can get silently lost Product: LMDB Version: 0.9.35 Hardware: x86_64 OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: github(a)nicwatson.org Target Milestone: --- On Windows, mdb_page_flush() writes each overflow page with a single WriteFile() whose write bytes is a 32-bit DWORD. A value whose overflow extent (psize * mp_pages) reaches 2**32 has its length truncated. An extent of exactly 2**32 truncates to 0, so WriteFile() writes nothing and the value is silently lost. The commit still "succeeds" (a 0-byte WriteFile returns TRUE), so the bug shows up as a value that reads back as zeroes instead of its contents. Here's a reproducer. This only works on Windows 64-bit. --- #include <stdio.h> #include <stdlib.h> #include <string.h> #include <direct.h> #define MKDIR(d) _mkdir(d) #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"; const size_t VALSIZE = (size_t)0xFFFFF000UL; MDB_env *env; MDB_txn *txn; MDB_dbi dbi; MDB_val key, val, got; unsigned char *p; char *buf; MKDIR(dir); 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 + (256UL << 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)); CHK(mdb_txn_commit(txn)); /* the overflow-page WriteFile happens here */ free(buf); CHK(mdb_txn_begin(env, NULL, MDB_RDONLY, &txn)); CHK(mdb_get(txn, dbi, &key, &got)); p = (unsigned char *)got.mv_data; if (got.mv_size != VALSIZE || memcmp(p, "HEAD", 4) != 0 || memcmp(p + VALSIZE - 4, "TAIL", 4) != 0) { fprintf(stderr, "BUG REPRODUCED: value truncated/lost: size=%zu " "head=%02x%02x%02x%02x tail=%02x%02x%02x%02x\n", got.mv_size, p[0], p[1], p[2], p[3], p[VALSIZE - 4], p[VALSIZE - 3], p[VALSIZE - 2], p[VALSIZE - 1]); mdb_txn_abort(txn); mdb_env_close(env); return 1; } mdb_txn_abort(txn); mdb_env_close(env); 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 9

[Issue 10534] New: mdb_env_get_maxkeysize(): requires an _env_open()ed handle
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10534 Issue ID: 10534 Summary: mdb_env_get_maxkeysize(): requires an _env_open()ed handle Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: steffen(a)sdaoden.eu Target Milestone: --- Created attachment 1174 --> https://bugs.openldap.org/attachment.cgi?id=1174&action=edit git-enabled patch Super minor, but my LMDB implementation for the bogofilter program was buggy because of this. They had to fix it accordingly after almost 8 years, when updating to LMDB 1.0. Suggested fix would be something like - * @param[in] env An environment handle returned by #mdb_env_create() + * @param[in] env An environment handle that is #mdb_env_open() Thanks! And ciao. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10536] New: Re-fix ITS#8174 mdb_drop(MAIN_DBI)
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10536 Issue ID: 10536 Summary: Re-fix ITS#8174 mdb_drop(MAIN_DBI) Product: LMDB Version: 1.0.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- The patch breaks mdb_drop() usability. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10529] New: assertion failure
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10529 Issue ID: 10529 Summary: assertion failure Product: LMDB Version: 1.0.0 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: christopher(a)gmerlin.de Target Milestone: --- When testing the OCaml bindings with lmdb 1.0 I encountered this assertion failure: at src/mdb.c:7588: Assertion 'root > 1' failed in mdb_page_search()") It was triggered by: - start transaction - add new key-value - commit transaction - rollback transaction - start read only transaction - try to get any key -> assertion failure On another note I notice that this fails with MDB_CANT_ROLLBACK: - start transaction - commit ¡EMPTY! transaction - rollback transaction -> MDB_CANT_ROLLBACK Of course this is a nonsensical transaction. But nevertheless maybe this case should be mentioned in the documentation, too. -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 10551] New: mdb_put() returns MDB_PAGE_FULL depending on key-length parity and insertion order
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10551 Issue ID: 10551 Summary: mdb_put() returns MDB_PAGE_FULL depending on key-length parity and insertion order Product: LMDB Version: 1.0.0 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: adam.req(a)gmx.de Target Milestone: --- Created attachment 1175 --> https://bugs.openldap.org/attachment.cgi?id=1175&action=edit insertion order ## Background I am currently getting familiar with LMDB and encountered the following reproducible behavior. ## Tested versions * OpenLDAP LMDB (`master`) * LMDB (`mdb.RE/1.0`) hint: 0.9.x was okay ## Description A new LMDB environment is created, followed by the creation of two DBIs. The attached key/value pairs are inserted using `mdb_put()` as follows (only the first dbi was used here): Key: excl. comma, including the terminating null character (`'\0'`) Value: raw byte sequence (number of bytes exactly as shown in the attachment) Example: GX\c, 100 -> means 4+1(zero)=5 bytes for key, and 100 bytes for value The final call to `mdb_put()` fails with: MDB_PAGE_FULL: Internal error - page has no more space ## Reproduction The failure is reproducible using the attached key/value sequence in "insertion order" file. The error does not occur if either of the following changes is made (just tested): * All keys are forced to have the same byte-length parity by appending an additional `0x00` byte where necessary (all keys become either even- or odd-sized). * The last two insertions are swapped. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10553] New: Fix types to allow compilation on windows
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10553 Issue ID: 10553 Summary: Fix types to allow compilation on windows Product: LMDB Version: 1.0.0 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: christopher(a)gmerlin.de Target Milestone: --- Created attachment 1178 --> https://bugs.openldap.org/attachment.cgi?id=1178&action=edit Patch including ac041af3d Compilation on windows fails because of pointer type errors. Commit ac041af3dd044d433e73432839cc323bffa357f3 does not fix all of those compilation failures: * NtMapViewOfSection() expects void * in its 3rd argument. * 7th expects SIZE_T *, but in mdb_env_copyfd0() a DWORD * is passed. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10542] New: On Windows, allow using previous write behavior
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10542 Issue ID: 10542 Summary: On Windows, allow using previous write behavior Product: LMDB Version: 1.0.0 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- ITS#9017 changed write behavior in Windows to use WRITE_THROUGH writes and eliminate use of FlushFileBuffers(). Supposedly this yields faster write performance because flushes are very slow. However, other users report this approach is actually much slower than LMDB 0.9. Add a compile-time flag to revert to the original write behavior. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

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