openldap-bugs

openldap-bugs@openldap.org

1 participants
21518 discussions

[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

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