- openldap-bugs - openldap.org

[Issue 9397] New: LMDB: A second process opening a file with MDB_WRITEMAP can cause the first to SIGBUS
by openldap-its＠openldap.org 22 Apr '26

22 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=9397 Issue ID: 9397 Summary: LMDB: A second process opening a file with MDB_WRITEMAP can cause the first to SIGBUS Product: LMDB Version: 0.9.26 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: github(a)nicwatson.org Target Milestone: --- Created attachment 780 --> https://bugs.openldap.org/attachment.cgi?id=780&action=edit Full reproduction of SIGBUS MDB_WRITEMAP issue (works on Linux only) The fundamental problem is that a ftruncate() on Linux that makes a file smaller will cause accesses past the new end of the file to SIGBUS (see the mmap man page). The sequence that causes a SIGBUS involves two processes. 1. The first process opens a new LMDB file with MDB_WRITEMAP. 2. The second process opens the same LMDB file with MDB_WRITEMAP and with an explicit map_size smaller than the first process's map size. * This causes an ftruncate that makes the underlying file *smaller*. 3. (Optional) The second process closes the environment and exits. 4. The first process opens a write transaction and writes a bunch of data. 5. The first process commits the transaction. This causes a memory read from the mapped memory that's now past the end of the file. On Linux, this triggers a SIGBUS. Attached is code that fully reproduces the problem on Linux. The most straightforward solution is to allow ftruncate to *reduce* the file size if it is the only reader. Another possibility is check the file size and ftruncate if necessary every time a write transaction is opened. A third possibility is to catch the SIGBUS signal. Repro note: I used clone() to create the subprocess to most straightforwardly demonstrate that the problem is not due to inherited file descriptors. The problem still manifests when the processes are completely independent. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 8582] LMDB lockfile/mutex arch dependency
by openldap-its＠openldap.org 22 Apr '26

22 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8582 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |SUSPENDED Status|IN_PROGRESS |RESOLVED --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- Doesn't look like glibc will ever be able to fix this. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8620] GCC error undeclared PTHREAD_MUTEX_ROBUST
by openldap-its＠openldap.org 22 Apr '26

22 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8620 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- Builds fine on my Windows10 box with msys2 / mingw64 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Bug 9207] New: Remove Moznss compatibility layer
by openldap-its＠openldap.org 22 Apr '26

22 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=9207 Bug ID: 9207 Summary: Remove Moznss compatibility layer Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For the 2.5 release, remove the MozNSS compatibility layer. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Issue 8503] Provide proper soname to liblmdb.so.1
by openldap-its＠openldap.org 22 Apr '26

22 Apr '26

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

22 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8165 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gahr(a)gahr.ch --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- *** Issue 8503 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8452] LMDB: mdb_env_copyfd2 can deadlock due to missing mdb_env_cthr_toggle check
by openldap-its＠openldap.org 22 Apr '26

22 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8452 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 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

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

22 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8209 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lmb(a)cloudflare.com --- Comment #9 from Howard Chu <hyc(a)openldap.org> --- *** Issue 8452 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8431] LMDB: Access newly opened database from another transaction
by openldap-its＠openldap.org 22 Apr '26

22 Apr '26

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

1 0

[Issue 8406] LMDB: Assertion 'mc->mc_flags & C_INITIALIZED' with MDB_NEXT after mdb_cursor_del
by openldap-its＠openldap.org 22 Apr '26

22 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8406 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Howard Chu <hyc(a)openldap.org> --- *** This issue has been marked as a duplicate of issue 10396 *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10396] New: LMDB: another issue with sorted duplicate DBs and cursor delete
by openldap-its＠openldap.org 22 Apr '26

22 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10396 Issue ID: 10396 Summary: LMDB: another issue with sorted duplicate DBs and cursor delete Product: LMDB Version: 0.9.19 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: --- In mdb_cursor_del0, in the second "Adjust other cursors" section (after mdb_rebalance was called), in these lines if (m3->mc_xcursor && !(m3->mc_flags & C_EOF)) { MDB_node *node = NODEPTR(m3->mc_pg[m3->mc_top], m3->mc_ki[m3->mc_top]); The node being referenced should be using mc->mc_top, not m3->mc_top. Most of the time these will be identical, but sometimes due to rebalancing, the mc cursor may be popped below its stack top when calling here. This bug was introduced for ITS#8406 in commit 37081325f7356587c5e6ce4c1f36c3b303fa718c on 2016-04-18. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

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

22 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8174 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1 --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- Initial fix in mdb.master3 0280f0310eebeec49869e98f4a56cec88c4b362f Returns MDB_DBIS_BUSY error if there are other DBIs open when attempting to drop the main DBI. Otherwise zeroes out both FREE_DBI and MAIN_DBI and blocks the txn from further use. Doesn't zero out other metapage though. Old readers can continue until the next write txn begins, after which they're likely to crash. Blocking new writers while old readers remain seems unreasonable but it may be the only safe option. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8034] lmdb-0.9.14 | Undefined symbols for architecture ppc: "_posix_memalign" referenced from _mdb_env_copyfd2 | ld: symbol(s) not found for architecture ppc
by openldap-its＠openldap.org 22 Apr '26

22 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8034 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #6 from Howard Chu <hyc(a)openldap.org> --- Any recent platform's libc should have memalign or posix_memalign. -- 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 22 Apr '26

22 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=7794 --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- (In reply to Howard Chu from comment #3) > In mdb.master3 c20187b4eeda18b4e2c818f713f586d97201bf74 Correction, commit is 43670420426754bb16f4ac68798e9b58d3bff7e9 -- 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 22 Apr '26

22 Apr '26

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

1 0

[Issue 10406] New: Write regression since 0.9.19
by openldap-its＠openldap.org 21 Apr '26

21 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10406 Issue ID: 10406 Summary: Write regression since 0.9.19 Product: LMDB Version: 0.9.33 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: ben.alex(a)acegi.com.au Target Milestone: --- I maintain LmdbJava, a Java wrapper for LMDB. We have an extensive benchmark suite covering read, cursor, and write pathways, with isolated testing of LMDB versions from 0.9.17 through 0.9.33. Results: https://lmdb-benchmark.lmdbjava.org/ ============================================== SUMMARY ============================================== Read performance: 0.9.33 consistently outperforms 0.9.17 across all read benchmarks. Write performance: Consistent regression since 0.9.19: ---------------------------------- Tag ms/op vs 0.9.17 ---------------------------------- LMDB_0.9.17 75.790 baseline LMDB_0.9.18 74.909 -1.2% LMDB_0.9.19 81.404 +7.4% LMDB_0.9.20 83.459 +10.1% LMDB_0.9.21 83.237 +9.8% LMDB_0.9.22 83.027 +9.5% LMDB_0.9.23 82.870 +9.3% LMDB_0.9.24 82.952 +9.4% LMDB_0.9.27 82.989 +9.5% LMDB_0.9.28 83.025 +9.5% LMDB_0.9.29 83.063 +9.6% LMDB_0.9.30 83.237 +9.8% LMDB_0.9.31 88.419 +16.7% LMDB_0.9.33 83.304 +9.9% Excluding 0.9.31 as an outlier, write performance degraded by approximately 9% from 0.9.20 and has remained at that level through 0.9.33. ============================================== BENCHMARK DETAILS ============================================== The write benchmark sequentially inserts 1,000,000 entries (100-byte values, 4-byte integer keys) into a database opened with MDB_INTEGERKEY, using a single cursor with MDB_APPEND flag. The benchmark includes 2 warmup iterations and 3 measurement iterations of 120 seconds each. ============================================== ANALYSIS ============================================== Reviewing the commit history, the regressions appear linked to correctness fixes: - 0.9.19: ITS#8406 (xcursor fixup after cursor_del) - 0.9.20: ITS#8557 (cursor_last and C_EOF handling) Both issues added cursor state management overhead in write-heavy code paths. ============================================== REQUEST ============================================== Could you please reproduce this regression using a native C benchmark to confirm it's not JNI-specific? If confirmed, this may be a necessary performance/correctness tradeoff given that most LMDB workloads are read-heavy. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10229] New: ldap_result, when invoked with MSG_RECEIVED and a timeout value set to 0 (polling), does not return all available messages until it is called again
by openldap-its＠openldap.org 21 Apr '26

21 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10229 Issue ID: 10229 Summary: ldap_result, when invoked with MSG_RECEIVED and a timeout value set to 0 (polling), does not return all available messages until it is called again Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- The issue is noticeable when ldap_result is used by the proxy back-ends. It has not affected back-meta behavior, because when a first call is unsuccessful, it retries with a small timeout. back-asyncmeta will also usually call it twice on the same connection from different threads, although this is not a desired behavior. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9888] New: When using cn=config replication, schema updates can corrupt the index database(s)
by openldap-its＠openldap.org 21 Apr '26

21 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=9888 Issue ID: 9888 Summary: When using cn=config replication, schema updates can corrupt the index database(s) Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Today I pushed a schema update out to the config node that holds schema that is replicated to the providers and consumers. Post schema update, 2/11 servers crashed in the mdb online indexing function. I fixed this by slapcat the db and slapadd the db. This is important because it was later revealed that on the 9/11 servers that did not crash or have their database reloaded, ldapsearch would return the wrong attribute names for some attribute:value pairs in the database, which caused mayhem in downstream systems and caused replication issues between the nodes. The 2 nodes that were reloaded immediately after the schema change had the only "good" copies of the database left. To give an example, say an entry was something like: dn: uid=joe,ou=people,dc=example,dc=com uid: joe sn: smith cn: joe smith givenName: joe After the change, the broken servers could return something like: dn: uid=joe,ou=people,dc=example,dc=com uid: joe posixGroup: smith cn: joe smith givenName joe It's not clear how deeply this bug ran in the database. It for sure affected 2 attributes used by the person objectClass. Both of the "replacement" attributes were not valid attributes for the person objectClasses in use. Maybe related to the changes in ITS#9858? -- You are receiving this mail because: You are on the CC list for the issue.

1 20

[Issue 8905] Client side debug log should include timestamps
by openldap-its＠openldap.org 21 Apr '26

21 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8905 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|IN_PROGRESS |RESOLVED Assignee|bugs(a)openldap.org |hyc(a)openldap.org --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • bc6cfca1 by Howard Chu at 2026-04-10T21:48:39+00:00 ITS#8905 libldap: add timestamp and threadID to debug messages • 37d677fb by Howard Chu at 2026-04-10T21:48:39+00:00 ITS#8905 clients: fixup connect fail message -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8064] SIGSEGV in monitor-shutdown code
by openldap-its＠openldap.org 21 Apr '26

21 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8064 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |2.6.14 Status|UNCONFIRMED |RESOLVED Resolution|--- |TEST --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • caab8146 by Ondřej Kuzník at 2026-04-10T03:15:42+00:00 ITS#8064 Fix back-ldap monitor deregistration RE26: • 0b835a92 by Ondřej Kuzník at 2026-04-21T15:57:02+00:00 ITS#8064 Fix back-ldap monitor deregistration -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8064] SIGSEGV in monitor-shutdown code
by openldap-its＠openldap.org 21 Apr '26

21 Apr '26

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

1 0

[Issue 10487] New: LDAPCon 2026
by openldap-its＠openldap.org 21 Apr '26

21 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10487 Issue ID: 10487 Summary: LDAPCon 2026 Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- LDAPCon is being organised[0] and would be nice to have it mentioned on the OpenLDAP website. Anywhere I guess [0]. https://ldapcon.org/2026/ -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 4574] require none doesn't work
by openldap-its＠openldap.org 21 Apr '26

21 Apr '26

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

1 0

[Issue 10438] New: Potential Dereference of NULL in ber_bvreplace_x
by openldap-its＠openldap.org 19 Apr '26

19 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10438 Issue ID: 10438 Summary: Potential Dereference of NULL in ber_bvreplace_x Product: OpenLDAP Version: 2.6.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: mishtitov(a)gmail.com Target Milestone: --- Return value of a function `ber_memrealloc_x` is dereferenced at [memory.c:711](https://git.openldap.org/openldap/openldap/-/blob/master/libr… withouth checking for NULL, but it is usually checked for this function. Notice that `ber_memrealloc_x()` might return NULL when `realloc()` fails. PLease consider adding a NULL check. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

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

16 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8394 --- Comment #4 from bdallen(a)nps.edu <bdallen(a)nps.edu> --- 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.") On 4/15/26 09:36, openldap-its(a)openldap.org wrote: > NPS WARNING: *external sender* verify before acting. > > > https://bugs.openldap.org/show_bug.cgi?id=8394 > > Howard Chu <hyc(a)openldap.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |RESOLVED > Resolution|--- |SUSPENDED > > --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- > No test case provided > > -- > 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs