openldap-bugs

openldap-bugs@openldap.org

1 participants
21518 discussions

[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

[Issue 10540] New: Clarify "Symas Dual-Use License"
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10540 Issue ID: 10540 Summary: Clarify "Symas Dual-Use License" 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: keno(a)alumni.harvard.edu Target Milestone: --- Greetings from the Julia project. We recently grew an LMDB dependency (https://github.com/JuliaLang/julia/pull/61527), so I am trying to make sure we have the licensing information correct. In particular, I am wondering about the "Symas Dual-Use License" which is referenced in these files: - crypto.c - cryptoc.c - module.c - mtest_enc{,2,3,4}.c - mtest_remap.c The license header says that a copy of the license is included in the LICENSE file, but this does not appear to be the case. I understand that there was previously an effort to dual license LMDB that did not end up happening (https://github.com/monero-project/meta/issues/85#issuecomment-361925678). Could you clarify if these license headers are a vestigal artifact of that process or if they are currently applicable and if the latter, could the appropriate license text be added to LICENSE? Thanks! Keno -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10108] New: "mdb_dump -a" does not dump the main database
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10108 Issue ID: 10108 Summary: "mdb_dump -a" does not dump the main database Product: LMDB Version: 0.9.29 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: tuukka.pensala(a)gmail.com Target Milestone: --- In mdb_dump.c we have these instructions: /* -a: dump main DB and all subDBs * -s: dump only the named subDB * -n: use NOSUBDIR flag on env_open * -p: use printable characters * -f: write to file instead of stdout * -V: print version and exit * (default) dump only the main DB */ However, contrary to the description, the option -a does not dump the main DB. With argument -a "dumpit(..)" is called for the named databases, but not for the unnamed one. With the current behavior, if the data store contains subDBs and has user-added data in the main DB, there seems to be no way to dump all of it at once using mdb_dump. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10454] New: O_DSYNC is busted on macos
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10454 Issue ID: 10454 Summary: O_DSYNC is busted on macos Product: LMDB Version: unspecified Hardware: All OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: pyry.kovanen(a)gmail.com Target Milestone: --- LMDB relies on O_DSYNC for writing the meta page, unfortunately it doesn't work on macos. Previous discovery by the tigerbeetle guys: https://github.com/tigerbeetle/viewstamped-replication-made-famous#leaderbo…, some more context at https://x.com/jorandirkgreef/status/1532314169604726784. I discovered this during benchmarking and was wondering why lmdb writes were twice as fast as macos as on linux. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10504] New: Linker warning on newer build tools
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10504 Issue ID: 10504 Summary: Linker warning on newer build tools Product: LMDB Version: unspecified Hardware: All OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Newer linker complains ld: warning: symbols in __TEXT,text_env (/Users/selsta/dev/monero/build/Darwin/master/release/external/db_drivers/liblmdb/liblmdb.a[2](mdb.c.o)) have unwind information, but it's not a code section (missing 'regular,pure_instructions' section flag) When built with > clang --version Apple clang version 21.0.0 (clang-2100.1.1.101) Target: arm64-apple-darwin25.5.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin > ld -v @(#)PROGRAM:ld PROJECT:ld-1267 BUILD 17:51:50 Apr 22 2026 configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em armv8m.main armv8.1m.main will use ld-classic for: armv6 armv7 armv7s i386 armv6m armv7k armv7m armv7em LTO support using: LLVM version 21.0.0 (static support for 30, runtime is 30) TAPI support using: Apple TAPI version 21.0.0 (tapi-2100.0.2.6) As reported on https://github.com/monero-project/monero/pull/10585 Adding the missing flags silences the warning. Works fine on older toolchains as well. Apple docs are a bit ambiguous about whether "pure_instructions" is required or valid on static builds. https://developer.apple.com/library/archive/documentation/DeveloperTools/Re… -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10522] New: Heap-buffer-overflow in mdb_cursor_last
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10522 Issue ID: 10522 Summary: Heap-buffer-overflow in mdb_cursor_last Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: renault.cle(a)gmail.com Target Milestone: --- Created attachment 1155 --> https://bugs.openldap.org/attachment.cgi?id=1155&action=edit Reproducer for a heap-buffer-overflow Hello, I was fuzzing a bit LMDB on my personnal time and found memory issue. I attached the reproducer. It is only reproducible when compiled with ASan/UBSan (-fsanitize=address,undefined) on macOS and you can get a segfault on Linux (6.1.0-44-amd64, Debian 6.1.164-1). The issue appears in the mdb_cursor_last function line 8257 on commit 7bcb4d05da7cf1546133baf51178e5e1b53cdd53 from branch mdb.RE/1.0. Thank you for your help, Have a nice day PS: I cannot specify the right version in the version list. PS2: I get a 401 Authorization Required when I try to connect through GitHub from Arc Browser. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

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