openldap-bugs January 2025

openldap-bugs@openldap.org

1 participants
132 discussions

[Issue 10203] New: no pkgconfig file included for liblmdb
by openldap-its＠openldap.org 30 Jun '26

30 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10203 Issue ID: 10203 Summary: no pkgconfig file included for liblmdb Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: otto(a)drijf.net Target Milestone: --- liblmdb does not ship with a pkgconfig file. More and more build systems rely on presense of a pkgconfig file, so it would be nice if liblmdb installed oneone. An example: prefix=/usr/local exec_prefix=${prefix} libdir=${prefix}/lib includedir=${prefix}/include Name: lmdb Description: Lightning memory-mapped database: key-value data store URL: https://www.symas.com/symas-embedded-database-lmdb Version: 0.9.32 Libs: -L${libdir} -llmdb Cflags: -I${includedir} Thanks. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10244] New: Fix pointer type
by openldap-its＠openldap.org 30 Jun '26

30 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10244 Issue ID: 10244 Summary: Fix pointer type Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: zanaviska(a)tutanota.com Target Milestone: --- Created attachment 1026 --> https://bugs.openldap.org/attachment.cgi?id=1026&action=edit passed temprorary variable Hi I am trying to add MINGW support for another project, But each time I get an error ``` mdb.c:3921:76: error: passing argument 3 of 'GetOverlappedResult' from incompatible pointer type [-Wincompatible-pointer-types] note: expected 'LPDWORD' {aka 'long unsigned int *'} but argument is of type 'ssize_t *' {aka 'long long int *'} ``` So I came up with a fix for your software, with I attach in attachment -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9291] New: Detection of corrupted database files
by openldap-its＠openldap.org 30 Jun '26

30 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=9291 Issue ID: 9291 Summary: Detection of corrupted database files Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: markus(a)objectbox.io Target Milestone: --- Let's assume we have to deal with a corrupted database for whatever reason (e.g. broken hardware or file system). Current behavior seems to be mostly undefined, which is understandable as it's not known what is broken (e.g. there are no checksums). For example, I'm seeing a SIGBUS in mdb_page_touch because the cursor's top page (mp) is pointing to invalid memory (0x7f99cf004000) during a commit: mdb_page_touch mdb.c:2772 mdb_page_search mdb.c:6595 mdb_freelist_save mdb.c:3575 mdb_txn_commit mdb.c:4060 Cursor data at that point: mc_snum = 1, mc_top = 0; myki[0] = 0 A SIGBUS is troublesome as it crashes the process, and I wonder if there are other ways to detect such inconsistencies. If that be possible there could be user-specific handling in place. E.g. a user might start a new database file. This issue was reported by our users, which also provided DB files: https://github.com/objectbox/objectbox-java/issues/859 I did not find a lot of consistency checks besides MDB_PAGE_NOTFOUND and MDB_CORRUPTED. Also, I think there's no current way to thoroughly check a DB file (e.g. like fsck for the DB file)? My first idea other than checksums was to walk through the branch pages from the root and check if the referenced pages are within reasonable bounds. Also check the page content (e.g. nodes, flags). Additionally (optionally?), it should be possible to check that the key values are actually sorted. So, it boils down to 3 points in summary: 1.) If there no way to check the DB file for consistency yet(?), which approach do you think would make sense? There might be two modes; one for a through check through all data, and a quick check that does not take long and could be e.g. done when opening the DB. Goal is to avoid process crashes and let users handle the situation. 2.) In general, is it possible to add more consistency checks in regular DB operations? 3.) Could the the particular situation (for which I provided the stack trace) detected (e.g. is myki[0] = 0 legal here?) I'd be happy to provide a patch if you provide some direction where you want to take that. -- You are receiving this mail because: You are on the CC list for the issue.

1 28

[Issue 9539] New: ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(env, 0)
by openldap-its＠openldap.org 30 Jun '26

30 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=9539 Issue ID: 9539 Summary: ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(env, 0) Product: LMDB Version: 0.9.28 Hardware: x86_64 OS: Windows Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: igfoo(a)github.com Target Milestone: --- On Windows, with the attached program and the commands below, I am getting ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(env, 0) on the latest 0.9.28 release. The program works as expected on mdb.master. git clone https://github.com/LMDB/lmdb.git cd lmdb git reset --hard LMDB_0.9.28 cd .. call "c:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvars64.bat" cl -Femain.exe -Ilmdb/libraries/liblmdb main.c lmdb/libraries/liblmdb/mdb.c lmdb/libraries/liblmdb/midl.c Advapi32.lib cl -Feloop.exe -Ilmdb/libraries/liblmdb loop.c lmdb/libraries/liblmdb/mdb.c lmdb/libraries/liblmdb/midl.c Advapi32.lib .\main.exe Example output: Loop 300000 400000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 500000 600000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 200000 300000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 400000 500000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 600000 700000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 100000 200000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 700000 800000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 900000 1000000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 800000 900000 starting. Loop 800000 900000 done. Non-zero 0 exit code 1. Non-zero 1 exit code 1. Non-zero 2 exit code 1. Non-zero 3 exit code 1. Non-zero 4 exit code 1. Non-zero 5 exit code 1. Non-zero 6 exit code 1. Non-zero 8 exit code 1. All done. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10274] New: Replication issue on MMR configuration
by openldap-its＠openldap.org 24 Jun '26

24 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10274 Issue ID: 10274 Summary: Replication issue on MMR configuration Product: OpenLDAP Version: 2.5.14 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: falgon.comp(a)gmail.com Target Milestone: --- Created attachment 1036 --> https://bugs.openldap.org/attachment.cgi?id=1036&action=edit In this attachment you will find 2 openldap configurations for 2 instances + slamd conf exemple + 5 screenshots to show the issue and one text file to explain what you see Hello we are openning this issue further to the initial post in technical : https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… Issue : We are working on a project and we've come across an issue with the replication after performance testing : *Configuration :* RHEL 8.6 OpenLDAP 2.5.14 *MMR-delta *configuration on multiple servers attached 300,000 users configured and used for tests *olcLastBind: TRUE* Use of SLAMD (performance shooting) *Problem description:* We are currently running performance and resilience tests on our infrastructure using the SLAMD tool configured to perform BINDs and MODs on a defined range of accounts. We use a load balancer (VIP) to poll all of our servers equally. (but it is possible to do performance tests directly on each of the directories) With our current infrastructure we're able to perform approximately 300 MOD/BIND/s. Beyond that, we start to generate delays and can randomly come across one issue. However, when we run performance tests that exceed our write capacity, our replication between servers can randomly create an incident with directories being unable to catch up with their replication delay. The directories update their contextCSNs, but extremely slowly (like freezing). From then on, it's impossible for the directories to catch again. (even with no incoming traffic) A restart of the instance is required to perform a full refresh and solve the incident. We have enabled synchronization logs and have no error or refresh logs to indicate a problem ( we can provide you with logs if necessary). We suspect a write collision or a replication conflict but this is never write in our sync logs. We've run a lot of tests. For example, when we run a performance test on a single live server, we don't reproduce the problem. Anothers examples: if we define different accounts ranges for each server with SALMD, we don't reproduce the problem either. If we use only one account for the range, we don't reproduce the problem either. ______________________________________________________________________ I have add some screenshots on attachement to show you the issue and all the explanations. ______________________________________________________________________ *Symptoms :* One or more directories can no longer be replicated normally after performance testing ends. No apparent error logs. Need a restart of instances to solve the problem. *How to reproduce the problem:* Have at least two servers in MMR mode Set LastBind to TRUE Perform a SLAMD shot from a LoadBalancer in bandwidth mode OR start multiple SLAMD test on same time for each server with the same account range. Exceed the maximum write capacity of the servers. *SLAMD configuration :* authrate.sh --hostname ${HOSTNAME} --port ${PORTSSL} \ --useSSL --trustStorePath ${CACERTJKS} \ --trustStorePassword ${CACERTJKSPW} --bindDN "${BINDDN}" \ --bindPassword ${BINDPW} --baseDN "${BASEDN}" \ --filter "(uid=[${RANGE}])" --credentials ${USERPW} \ --warmUpIntervals ${WARMUP} \ --numThreads ${NTHREADS} ${ARGS} -- You are receiving this mail because: You are on the CC list for the issue.

1 23

[Issue 10236] New: fragmentation makes mdb_page_alloc slow
by openldap-its＠openldap.org 24 Jun '26

24 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10236 Issue ID: 10236 Summary: fragmentation makes mdb_page_alloc slow Product: LMDB Version: 0.9.31 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: aalekseyev(a)janestreet.com Target Milestone: --- Created attachment 1022 --> https://bugs.openldap.org/attachment.cgi?id=1022&action=edit patch is relative to LMDB_0.9.31 It's a known problem that mdb_page_alloc can be slow when the free list is large and fragmented. [1] [2] [3] I'm not sure it's known *how* slow it can be. In our workload we saw a fragmented freelist leading to a pathological O(n^2) behavior. To handle a multi-page allocation we iterate loading chunks of the free list one by one, and at every iteration we do O(n) work to check if the allocation can succeed. Even small-ish allocations (tens of pages) are repeatedly hitting this edge case, with free list growing to ~1000000, and the outer loop taking ~2000 iterations (10^9 worth of work in total, just to allocate a few pages). Even though I'm sure there are ways to avoid hitting this pathological scenario so much (avoid values larger than 4k, or fix whatever causes fragmentation), it seems unacceptable to have a performance cliff this bad. I made a patch to make the allocation take ~O(n*log(n)), by loading and merging multiple chunks at once instead of doing it one-by-one. I'd appreciate it if someone could review the patch (attached), improve it, and/or come up with an alternative fix. The code in `midl.c` is kinda meme-y, including a contribution from GPT-4o, but it performs well enough to speed up our pathological workload by ~20x (which is still ~3x away from the non-fragmented case). Anyway, the main thing that warrants scrutiny is the change in `mdb.c`: I understand very little about lmdb internals and I worry that loading multiple pages at once instead of one-by-one might break something. [1] issue #8664 [2] https://lists.openldap.org/hyperkitty/list/openldap-bugs@openldap.org/threa… [3] https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 9640] New: ACL privilege for MOD_INCREMENT
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=9640 Issue ID: 9640 Summary: ACL privilege for MOD_INCREMENT Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- I'm using LDAP write operations with MOD_INCREMENT with pre-read-control for uidNumber/gidNumber generation. I'd like to limit write access to an Integer attribute "nextID" to MOD_INCREMENT, ideally even restricting the de-/increment value. (Uniqueness is achieved with slapo-unique anyway but still I'd like to avoid users messing with this attribute). IMHO the ideal solution would be a new privilege "i". Example for limiting write access to increment by one and grant read access for using read control: access to attrs=nextID val=1 by group=... =ri Example for decrementing by two without read: access to attrs=nextID val=-2 by group=... =i -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9739] New: Undefined reference to ber_sockbuf_io_udp in 2.6.0
by openldap-its＠openldap.org 03 Jun '26

03 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=9739 Issue ID: 9739 Summary: Undefined reference to ber_sockbuf_io_udp in 2.6.0 Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: simon.pichugin(a)gmail.com Target Milestone: --- While I was trying to build OpenLDAP 2.6 on Fedora Rawhide I've got the error message: /usr/bin/ld: ./.libs/libldap.so: undefined reference to `ber_sockbuf_io_udp' I've checked commits from https://bugs.openldap.org/show_bug.cgi?id=9673 and found that 'ber_sockbuf_io_udp' was not added to https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblber/… I've asked on the project's mailing list and got a reply: "That symbol only exists if OpenLDAP is built with LDAP_CONNECTIONLESS defined, which is not a supported feature. Feel free to file a bug report at https://bugs.openldap.org/" https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… Hence, creating the bug. -- You are receiving this mail because: You are on the CC list for the issue.

1 20

[Issue 9716] New: Fix default guide versions for head and 2.6
by openldap-its＠openldap.org 26 May '26

26 May '26

https://bugs.openldap.org/show_bug.cgi?id=9716 Issue ID: 9716 Summary: Fix default guide versions for head and 2.6 Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The preamble file needs to be fixed in openldap head and the 2.6 release branch to be correct. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9796] New: Deprecate GnuTLS support
by openldap-its＠openldap.org 20 May '26

20 May '26

https://bugs.openldap.org/show_bug.cgi?id=9796 Issue ID: 9796 Summary: Deprecate GnuTLS support Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Support for GnuTLS was added specifically for the Debian (and thus Ubuntu) due to the license objections at the time that the Debian project had for the OpenSSL license. Since that time, Debian has reclassified OpenSSL as a core library and the OpenSSL project has resolved the original complaint by licensing OpenSSL 3 and later under the Apache License v2. Thus there is no longer a reason to maintain support for GnuTLS and given the long standing concerns over the security and quality of the GnuTLS bridge in addition to the extra cost of maintaining that code, it should be marked as deprecated and removed in a future release. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

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 January 2025