- openldap-bugs - openldap.org

[Issue 8179] LMDB: Feature Request: mdb_env_check_mapsize(env)
by openldap-its＠openldap.org 15 Apr '26

15 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8179 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- Rejecting this because it encourages the wrong style of usage. The intended way to use LMDB is to simply set the mapsize to the maximum amount of (allowed|available) storage, once, at creation time and never touch it again. It's a simple matter to automate checking the amount of free disk space and just using that as the mapsize. Growing the map incrementally is wrong-headed and wasteful. We've accommodated it only under duress thus far. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8060] mdb_from_db (bdb import)
by openldap-its＠openldap.org 15 Apr '26

15 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8060 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |SUSPENDED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- Suspending until IPR notice is provided. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7853] Improve safety of mdb_env_close
by openldap-its＠openldap.org 15 Apr '26

15 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=7853 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #6 from Howard Chu <hyc(a)openldap.org> --- It's already documented "don't do that". There are no clean / portable solutions. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7364] mdb: clean up POSIX semaphores on environment close.
by openldap-its＠openldap.org 15 Apr '26

15 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=7364 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #18 from Howard Chu <hyc(a)openldap.org> --- Closing as fixed now; the *BSD platforms that used to require POSIX semaphores now support process-shared mutexes so nobody needs this support any more. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10180] New: mdb.c:2185: Assertion 'rc == 0' failed in mdb_page_dirty()
by openldap-its＠openldap.org 15 Apr '26

15 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10180 Issue ID: 10180 Summary: mdb.c:2185: Assertion 'rc == 0' failed in mdb_page_dirty() Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: dominik(a)greysector.net Target Milestone: --- I'm experiencing a SIGABRT-induced crash in nheko, which uses lmdb for its database (~/.local/share/nheko/nheko/#hash#/{data,lock}.mdb). The assertion triggering the SIGABRT seems to be happening here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblmdb/… The crash happens on every nheko startup since yesterday, so I assume something added to the database is triggering it. Full backtrace from gdb: ... (gdb) run Starting program: /usr/bin/nheko [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7ffff04006c0 (LWP 8281)] [New Thread 0x7fffefa006c0 (LWP 8282)] [New Thread 0x7fffee2006c0 (LWP 8283)] [New Thread 0x7fffed8006c0 (LWP 8284)] [New Thread 0x7fffece006c0 (LWP 8285)] [New Thread 0x7fffe7e006c0 (LWP 8286)] [Thread 0x7fffe7e006c0 (LWP 8286) exited] [New Thread 0x7fffe7e006c0 (LWP 8287)] [New Thread 0x7fffe74006c0 (LWP 8288)] [Thread 0x7fffe7e006c0 (LWP 8287) exited] [Thread 0x7fffe74006c0 (LWP 8288) exited] [New Thread 0x7fffe74006c0 (LWP 8289)] [New Thread 0x7fffe7e006c0 (LWP 8290)] [Thread 0x7fffe74006c0 (LWP 8289) exited] [Thread 0x7fffe7e006c0 (LWP 8290) exited] [New Thread 0x7fffe7e006c0 (LWP 8292)] [New Thread 0x7fffe74006c0 (LWP 8293)] [New Thread 0x7fffe6a006c0 (LWP 8294)] [New Thread 0x7fffe60006c0 (LWP 8295)] [New Thread 0x7fffe56006c0 (LWP 8296)] [New Thread 0x7fffe4c006c0 (LWP 8297)] [New Thread 0x7fffdfe006c0 (LWP 8298)] [New Thread 0x7fffdf4006c0 (LWP 8299)] [New Thread 0x7fffd7e006c0 (LWP 8300)] [New Thread 0x7fffd74006c0 (LWP 8301)] [New Thread 0x7fffd6a006c0 (LWP 8302)] [New Thread 0x7fffd60006c0 (LWP 8303)] [Thread 0x7fffd60006c0 (LWP 8303) exited] [Thread 0x7fffd6a006c0 (LWP 8302) exited] [New Thread 0x7fffd6a006c0 (LWP 8304)] [2024-02-16 11:52:33.040] [ui] [info] Restoring window size 1424x885 [2024-02-16 11:52:33.051] [ui] [info] WebRTC: initialised GStreamer 1.22.9 [New Thread 0x7fffd60006c0 (LWP 8305)] [New Thread 0x7fffd52006c0 (LWP 8306)] [New Thread 0x7fffcfe006c0 (LWP 8307)] [New Thread 0x7fffcf4006c0 (LWP 8308)] [New Thread 0x7fffcea006c0 (LWP 8309)] [Thread 0x7fffcea006c0 (LWP 8309) exited] [New Thread 0x7fffcea006c0 (LWP 8310)] [Thread 0x7fffcea006c0 (LWP 8310) exited] [2024-02-16 11:52:33.342] [ui] [info] Loaded jdenticon plugin. [New Thread 0x7fffcea006c0 (LWP 8311)] [New Thread 0x7fffce0006c0 (LWP 8312)] [Thread 0x7fffce0006c0 (LWP 8312) exited] [Thread 0x7fffcea006c0 (LWP 8311) exited] [2024-02-16 11:52:33.557] [ui] [info] starting nheko 0.11.3 [New Thread 0x7fffcea006c0 (LWP 8313)] [2024-02-16 11:52:33.558] [ui] [info] User already signed in, showing chat page [2024-02-16 11:52:33.559] [ui] [info] Switching to chat page [New Thread 0x7fffce0006c0 (LWP 8314)] [2024-02-16 11:52:33.604] [qml] [warning] qrc:/qml/TopBar.qml:234:13: QML AbstractButton: Binding loop detected for property "implicitWidth" (qrc:/qml/TopBar.qml:234, ) [2024-02-16 11:52:33.604] [qml] [warning] qrc:/qml/TopBar.qml:241:30: QML EncryptionIndicator: Binding loop detected for property "sourceSize.height" (qrc:/qml/TopBar.qml:241, ) [2024-02-16 11:52:33.622] [ui] [info] Unity service available: true [New Thread 0x7fffcca006c0 (LWP 8315)] [New Thread 0x7fffbfe006c0 (LWP 8316)] [New Thread 0x7fffbf4006c0 (LWP 8317)] [2024-02-16 11:52:33.629] [qml] [warning] qrc:/qml/ChatPage.qml:105:17: QML RoomList: Binding loop detected for property "implicitWidth" (qrc:/qml/ChatPage.qml:105, ) [2024-02-16 11:52:33.629] [qml] [warning] qrc:/qml/ChatPage.qml:105:17: QML RoomList: Binding loop detected for property "implicitWidth" (qrc:/qml/ChatPage.qml:105, ) [New Thread 0x7fffbd2006c0 (LWP 8318)] [2024-02-16 11:52:33.719] [db] [info] database ready [2024-02-16 11:52:33.720] [db] [info] restoring state from cache [2024-02-16 11:52:33.729] [db] [info] Restored 150 rooms from cache [2024-02-16 11:52:33.770] [db] [info] Invalidating self verification status [New Thread 0x7fffb7e006c0 (LWP 8319)] [2024-02-16 11:52:33.775] [crypto] [info] ed25519 : <redacted> [2024-02-16 11:52:33.775] [crypto] [info] curve25519: <redacted> mdb.c:2185: Assertion 'rc == 0' failed in mdb_page_dirty() [New Thread 0x7fffb74006c0 (LWP 8320)] Thread 1 "nheko" received signal SIGABRT, Aborted. 0x00007ffff4eae834 in __pthread_kill_implementation () from /lib64/libc.so.6 (gdb) where #0 0x00007ffff4eae834 in __pthread_kill_implementation () from /lib64/libc.so.6 #1 0x00007ffff4e5c8ee in raise () from /lib64/libc.so.6 #2 0x00007ffff4e448ff in abort () from /lib64/libc.so.6 #3 0x00007ffff780f56b in mdb_assert_fail.constprop.0 (env=0x5555572b3940, expr_txt=<optimized out>, func=<optimized out>, line=<optimized out>, file=0x7ffff781c9d0 "mdb.c") at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:1588 #4 0x00007ffff780da59 in mdb_page_dirty (txn=<optimized out>, mp=<optimized out>) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:2172 #5 mdb_page_dirty (txn=0x555557a50220, mp=<optimized out>) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:2172 #6 0x00007ffff781be5e in mdb_page_alloc.isra.0 (num=1, mp=0x7fffffffb768, mc=<optimized out>) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:2366 #7 0x00007ffff7812e52 in mdb_page_touch (mc=mc@entry=0x7fffffffbcb0) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:2486 #8 0x00007ffff7814ac7 in mdb_cursor_touch (mc=mc@entry=0x7fffffffbcb0) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:6602 #9 0x00007ffff7817879 in _mdb_cursor_put (mc=mc@entry=0x7fffffffbcb0, key=key@entry=0x7fffffffc080, data=data@entry=0x7fffffffc090, flags=<optimized out>, flags@entry=0) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:6736 #10 0x00007ffff78188ee in mdb_put (txn=0x555557a50220, dbi=17, key=0x7fffffffc080, data=0x7fffffffc090, flags=0) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:9150 #11 0x00005555559f41c2 in lmdb::dbi_put (flags=0, data=0x7fffffffc090, key=0x7fffffffc080, dbi=<optimized out>, txn=<optimized out>) at /usr/include/lmdb++.h:787 #12 lmdb::dbi::put(MDB_txn*, std::basic_string_view<char, std::char_traits<char> >, std::basic_string_view<char, std::char_traits<char> >, unsigned int) [clone .constprop.0] [clone .isra.0] (txn=<optimized out>, key=..., data=..., flags=0, this=<optimized out>) at /usr/include/lmdb++.h:1413 #13 0x00005555559521e5 in Cache::markUserKeysOutOfDate (this=this@entry=0x555557264f40, txn=..., db=..., user_ids=std::vector of length 1, capacity 1 = {...}, sync_token="s117629150_1_50402_53153589_3038507_9889_1030948_33315610_0_2131") at /usr/include/lmdb++.h:1187 #14 0x00005555559524d5 in Cache::markUserKeysOutOfDate (this=0x555557264f40, user_ids=std::vector of length 1, capacity 1 = {...}) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/Cache.cpp:4580 #15 0x00005555559333ee in operator() (__closure=<optimized out>) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/encryption/SelfVerificationStatus.cpp:32 #16 QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, SelfVerificationStatus::SelfVerificationStatus(QObject*)::<lambda()> >::call (arg=<optimized out>, f=...) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:146 #17 QtPrivate::Functor<SelfVerificationStatus::SelfVerificationStatus(QObject*)::<lambda()>, 0>::call<QtPrivate::List<>, void> (arg=<optimized out>, f=...) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:256 #18 QtPrivate::QFunctorSlotObject<SelfVerificationStatus::SelfVerificationStatus(QObject*)::<lambda()>, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (which=<optimized out>, this_=<optimized out>, r=<optimized out>, a=<optimized out>, ret=<optimized out>) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:443 #19 0x00007ffff58e9151 in QtPrivate::QSlotObjectBase::call (a=0x7fffffffc970, r=<optimized out>, this=0x5555567a6ff0) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #20 doActivate<false> (sender=0x555556030bc0, signal_index=5, argv=0x7fffffffc970) at kernel/qobject.cpp:3925 #21 0x00007ffff58e4077 in QMetaObject::activate (sender=sender@entry=0x555556030bc0, m=<optimized out>, local_signal_index=local_signal_index@entry=2, argv=argv@entry=0x0) at kernel/qobject.cpp:3985 #22 0x0000555555977046 in ChatPage::contentLoaded (this=0x555556030bc0) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/redhat-linux-build/nheko_autogen/UVLADIE3JM/moc_ChatPage.cpp:820 #23 ChatPage::loadStateFromCache (this=0x555556030bc0) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/ChatPage.cpp:600 #24 0x0000555555977919 in ChatPage::bootstrap(QString, QString, QString)::{lambda()#1}::operator()() const [clone .lto_priv.0] () at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/ChatPage.cpp:497 #25 0x00007ffff58e9151 in QtPrivate::QSlotObjectBase::call (a=0x7fffffffcf00, r=<optimized out>, this=0x5555572b4c50) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #26 doActivate<false> (sender=0x555557264f40, signal_index=10, argv=0x7fffffffcf00) at kernel/qobject.cpp:3925 #27 0x00007ffff58e4077 in QMetaObject::activate (sender=sender@entry=0x555557264f40, m=<optimized out>, local_signal_index=local_signal_index@entry=7, argv=argv@entry=0x0) at kernel/qobject.cpp:3985 #28 0x000055555593873e in Cache::databaseReady (this=0x555557264f40) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/redhat-linux-build/nheko_autogen/UVLADIE3JM/moc_Cache_p.cpp:275 #29 Cache::loadSecretsFromStore(std::vector<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool>, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool> > >, std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>, bool) (this=0x555557264f40, toLoad=std::vector of length 0, capacity 0, callback=..., databaseReadyOnFinished=true) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/Cache.cpp:393 #30 0x000055555596e7f1 in operator() (__closure=<optimized out>) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/Cache.cpp:457 #31 QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, Cache::loadSecretsFromStore(std::vector<std::pair<std::__cxx11::basic_string<char>, bool> >, std::function<void(const std::__cxx11::basic_string<char>&, bool, const std::__cxx11::basic_string<char>&)>, bool)::<lambda(QKeychain::Job*)> mutable::<lambda()> >::call (arg=<optimized out>, f=...) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:146 #32 QtPrivate::Functor<Cache::loadSecretsFromStore(std::vector<std::pair<std::__cxx11::basic_string<char>, bool> >, std::function<void(const std::__cxx11::basic_string<char>&, bool, const std::__cxx11::basic_string<char>&)>, bool)::<lambda(QKeychain::Job*)> mutable::<lambda()>, 0>::call<QtPrivate::List<>, void> (arg=<optimized out>, f=...) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:256 #33 QtPrivate::QFunctorSlotObject<Cache::loadSecretsFromStore(std::vector<std::pair<std::__cxx11::basic_string<char>, bool> >, std::function<void(const std::__cxx11::basic_string<char>&, bool, const std::__cxx11::basic_string<char>&)>, bool)::<lambda(QKeychain::Job*)> mutable::<lambda()>, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (which=<optimized out>, this_=<optimized out>, r=<optimized out>, a=<optimized out>, ret=<optimized out>) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:443 #34 0x00007ffff58df9fb in QObject::event (this=0x555557264f40, e=0x7fffe8008f30) at kernel/qobject.cpp:1347 #35 0x00007ffff65aeb95 in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0x555557264f40, e=0x7fffe8008f30) at kernel/qapplication.cpp:3640 #36 0x00007ffff58b4e78 in QCoreApplication::notifyInternal2 (receiver=0x555557264f40, event=0x7fffe8008f30) at kernel/qcoreapplication.cpp:1064 #37 0x00007ffff58b5092 in QCoreApplication::sendEvent (receiver=<optimized out>, event=<optimized out>) at kernel/qcoreapplication.cpp:1462 #38 0x00007ffff58b8325 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x555555d6ef30) at kernel/qcoreapplication.cpp:1821 #39 0x00007ffff58b85dd in QCoreApplication::sendPostedEvents (receiver=<optimized out>, event_type=<optimized out>) at kernel/qcoreapplication.cpp:1680 #40 0x00007ffff59078cf in postEventSourceDispatch (s=0x555556019530) at kernel/qeventdispatcher_glib.cpp:277 #41 0x00007ffff5511e5c in g_main_dispatch (context=0x7fffe8000ec0) at ../glib/gmain.c:3476 #42 g_main_context_dispatch_unlocked (context=0x7fffe8000ec0) at ../glib/gmain.c:4284 #43 0x00007ffff556cf18 in g_main_context_iterate_unlocked.isra.0 (context=context@entry=0x7fffe8000ec0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4349 #44 0x00007ffff550fad3 in g_main_context_iteration (context=0x7fffe8000ec0, may_block=1) at ../glib/gmain.c:4414 #45 0x00007ffff59073b9 in QEventDispatcherGlib::processEvents (this=0x555555f57ae0, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #46 0x00007ffff58b383b in QEventLoop::exec (this=this@entry=0x7fffffffd640, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69 #47 0x00007ffff58bbacb in QCoreApplication::exec () at ../../include/QtCore/../../src/corelib/global/qflags.h:121 #48 0x00007ffff5d60ead in QGuiApplication::exec () at kernel/qguiapplication.cpp:1863 #49 0x00007ffff65aeb09 in QApplication::exec () at kernel/qapplication.cpp:2832 #50 0x000055555570d10d in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/main.cpp:405 (gdb) Looks like this was reported to nheko already, but they don't know what's causing it: https://github.com/Nheko-Reborn/nheko/issues/1303 . -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9096] tons of crashing and core dumps after every boot
by openldap-its＠openldap.org 15 Apr '26

15 Apr '26

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

1 0

[Issue 9378] New: Crash in mdb_put() / mdb_page_dirty()
by openldap-its＠openldap.org 15 Apr '26

15 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=9378 Issue ID: 9378 Summary: Crash in mdb_put() / mdb_page_dirty() Product: LMDB Version: 0.9.26 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: nate(a)kde.org Target Milestone: --- The KDE Baloo file indexer uses lmdb as its database (source code available at https://invent.kde.org/frameworks/baloo). Our most common crash, with over 100 duplicate bug reports, is in lmdb. Here's the bug report tracking it: https://bugs.kde.org/show_bug.cgi?id=389848. The version of lmdb does not seem to matter much. We have bug reports from Arch users with lmdb 0.9.26 as well as bug reports from people using many earlier versions. Here's an example backtrace, taken from https://bugs.kde.org/show_bug.cgi?id=426195: #6 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #7 0x00007f3c0bbb9859 in __GI_abort () at abort.c:79 #8 0x00007f3c0b23ba83 in mdb_assert_fail (env=0x55e2ad710600, expr_txt=expr_txt@entry=0x7f3c0b23e02f "rc == 0", func=func@entry=0x7f3c0b23e978 <__func__.7221> "mdb_page_dirty", line=line@entry=2127, file=0x7f3c0b23e010 "mdb.c") at mdb.c:1542 #9 0x00007f3c0b2306d5 in mdb_page_dirty (mp=<optimized out>, txn=0x55e2ad7109f0) at mdb.c:2114 #10 mdb_page_dirty (txn=0x55e2ad7109f0, mp=<optimized out>) at mdb.c:2114 #11 0x00007f3c0b231966 in mdb_page_alloc (num=num@entry=1, mp=mp@entry=0x7f3c0727aee8, mc=<optimized out>) at mdb.c:2308 #12 0x00007f3c0b231ba3 in mdb_page_touch (mc=mc@entry=0x7f3c0727b420) at mdb.c:2495 #13 0x00007f3c0b2337c7 in mdb_cursor_touch (mc=mc@entry=0x7f3c0727b420) at mdb.c:6523 #14 0x00007f3c0b2368f9 in mdb_cursor_put (mc=mc@entry=0x7f3c0727b420, key=key@entry=0x7f3c0727b810, data=data@entry=0x7f3c0727b820, flags=flags@entry=0) at mdb.c:6657 #15 0x00007f3c0b23976b in mdb_put (txn=0x55e2ad7109f0, dbi=5, key=key@entry=0x7f3c0727b810, data=data@entry=0x7f3c0727b820, flags=flags@entry=0) at mdb.c:9022 #16 0x00007f3c0c7124c5 in Baloo::DocumentDB::put (this=this@entry=0x7f3c0727b960, docId=<optimized out>, docId@entry=27041423333263366, list=...) at ./src/engine/documentdb.cpp:79 #17 0x00007f3c0c743da7 in Baloo::WriteTransaction::replaceDocument (this=0x55e2ad7ea340, doc=..., operations=operations@entry=...) at ./src/engine/writetransaction.cpp:232 #18 0x00007f3c0c736b16 in Baloo::Transaction::replaceDocument (this=this@entry=0x7f3c0727bc10, doc=..., operations=operations@entry=...) at ./src/engine/transaction.cpp:295 #19 0x000055e2ac5d6cbc in Baloo::UnindexedFileIndexer::run (this=0x55e2ad79ca20) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:60 #20 0x00007f3c0c177f82 in QThreadPoolThread::run (this=0x55e2ad717f20) at thread/qthreadpool.cpp:99 #21 0x00007f3c0c1749d2 in QThreadPrivate::start (arg=0x55e2ad717f20) at thread/qthread_unix.cpp:361 #22 0x00007f3c0b29d609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #23 0x00007f3c0bcb6103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 -- You are receiving this mail because: You are on the CC list for the issue.

1 31

[Issue 9736] New: pwrite bug in OSX breaking LMDB promise about the maximum value size
by openldap-its＠openldap.org 15 Apr '26

15 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=9736 Issue ID: 9736 Summary: pwrite bug in OSX breaking LMDB promise about the maximum value size 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: renault.cle(a)gmail.com Target Milestone: --- Hi, I was working with LMDB and found an issue when trying to write a value of approximately 3.3GiB in the database, I dive into the LMDB source code of the mdb_put method using the lldb debugger and found out that it was not related to an issue in LMDB itself but rather a bug in the pwrite function of the Mac OS libc implementation. The pwrite function is given four parameters, the file descriptor, the buffer, the count of bytes to write from the buffer and, the offset of where to write it in the file. On Mac OS the count of bytes is a size_t that must be a 64bits unsigned integer but when you call pwrite with a number bigger or equal to 2^31 it returns an error 22 (invalid argument). LMDB was returning a 22 error from the mdb_put call and not an EINVAL because the error was cause by an internal issue and not something catchable by LMDB. I am not sure about what we can do, can we implement this single pwrite [1] as multiple pwrite with counts smaller than 2^31 in a loop, just for Mac OS? Like for Windows where we do specific things for this operating system too? I also found this issue on the RocksDB repository [2] about a similar problem they have with pwrite and write on Mac OS it seems. I understand that this is not a real promise that LMDB is specifying but rather an "in theory" rule [3]. Thank you for your time, kero [1]: https://github.com/LMDB/lmdb/blob/01b1b7dc204abdf3849536979205dc9e3a0e3ece/… [2]: https://github.com/facebook/rocksdb/issues/5169 [3]: http://www.lmdb.tech/doc/group__mdb.html#structMDB__val -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10050] New: Use of stack allocated string in mdb_strerror
by openldap-its＠openldap.org 15 Apr '26

15 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10050 Issue ID: 10050 Summary: Use of stack allocated string in mdb_strerror Product: LMDB Version: unspecified Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: es(a)m-labs.hk Target Milestone: --- https://git.openldap.org/openldap/openldap/-/blob/mdb.master/libraries/libl… This piece of code exists from 2014, and these lines are not working outside of MSVC. Moreover, they lead to segfaults in MINGW compiled environments. Please see the patch we use for potential fix: https://github.com/msys2/MINGW-packages/blob/31012dd33a32390d1e5f9b93388799… -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8361] mdb_strerror() issues
by openldap-its＠openldap.org 15 Apr '26

15 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8361 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |es(a)m-labs.hk --- Comment #1 from Howard Chu <hyc(a)openldap.org> --- *** Issue 10050 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 8318] Add RECNUM support in LMDB
by openldap-its＠openldap.org 15 Apr '26

15 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8318 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 10486 *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7754] Unaligned MDB_DUPSORT sub-pages
by openldap-its＠openldap.org 15 Apr '26

15 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=7754 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|IN_PROGRESS |RESOLVED Target Milestone|--- |1.0.0 --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- Fixed in mdb.master3 / LMDB 1.0 *** This issue has been marked as a duplicate of issue 8988 *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8988] Undefined Behavior in slapadd
by openldap-its＠openldap.org 15 Apr '26

15 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8988 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hallvard(a)openldap.org --- Comment #30 from Howard Chu <hyc(a)openldap.org> --- *** Issue 7754 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 8905] Client side debug log should include timestamps
by openldap-its＠openldap.org 10 Apr '26

10 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8905 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1 --- Comment #1 from Howard Chu <hyc(a)openldap.org> --- https://git.openldap.org/openldap/openldap/-/merge_requests/859 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6462] DNS SRV records: ldaps ???
by openldap-its＠openldap.org 09 Apr '26

09 Apr '26

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

1 0

[Issue 6462] DNS SRV records: ldaps ???
by openldap-its＠openldap.org 09 Apr '26

09 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=6462 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net Status|UNCONFIRMED |IN_PROGRESS --- Comment #5 from Ondřej Kuzník <ondra(a)mistotebe.net> --- https://git.openldap.org/openldap/openldap/-/merge_requests/855 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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 08 Apr '26

08 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10475 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |TEST --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: by Ondřej Kuzník at 2026-04-08T15:54:44+00:00 ITS#10475 Escape asserted value before pasting into filter • 0347718d by Ondřej Kuzník at 2026-04-08T15:54:44+00:00 ITS#10476 Escape asserted value before pasting into filter RE26: • 2028cb47 by Ondřej Kuzník at 2026-04-08T23:19:21+00:00 ITS#10476 Escape asserted value before pasting into filter • 2028cb47 by Ondřej Kuzník at 2026-04-08T23:19:21+00:00 ITS#10476 Escape asserted value before pasting into filter -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10474] New: Update contributing page to note no AI generated code
by openldap-its＠openldap.org 07 Apr '26

07 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10474 Issue ID: 10474 Summary: Update contributing page to note no AI generated code Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Need to update the contributing page to note that we do not accept AI generated code in the project. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10464] slapd crashes in ppolicy when PasswordPolicyRequest control is sent with rejected operations
by openldap-its＠openldap.org 07 Apr '26

07 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10464 --- Comment #11 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 6052b633 by Tero Saarni at 2026-04-07T15:48:49+01:00 ITS#10464 Add tests for ppolicy reject cases -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9009] 2.7: Switch to LMDB v1.0
by openldap-its＠openldap.org 07 Apr '26

07 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=9009 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |10274 Referenced Issues: https://bugs.openldap.org/show_bug.cgi?id=10274 [Issue 10274] Replication issue on MMR configuration -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10455] New: Allow handling of empty group in memberof_saveMember_cb()
by openldap-its＠openldap.org 07 Apr '26

07 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10455 Issue ID: 10455 Summary: Allow handling of empty group in memberof_saveMember_cb() Product: OpenLDAP Version: 2.6.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: roger.j.meier(a)gmx.ch Target Milestone: --- Created attachment 1117 --> https://bugs.openldap.org/attachment.cgi?id=1117&action=edit Protect e_attrs with a NULL pointer test instead of an assert() to allow empty groups In slapd/overlays/memberof.c, the callback memberof_saveMember_cb() uses two assert statements for the sr_entry and its e_attrs pointer in sequence. This makes the service abort on an empty group. If the use of rs->sr_entry->e_attrs is just protected by a test of the e_attrs pointer, the code does not abort and allows empty groups. Please consider to add this patch to the official source. It was now several month in production and did not lead to unexpected results. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10257] New: Documentation assessment
by openldap-its＠openldap.org 07 Apr '26

07 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10257 Issue ID: 10257 Summary: Documentation assessment Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Created attachment 1031 --> https://bugs.openldap.org/attachment.cgi?id=1031&action=edit Admin guide assessment Last month I commissioned a tech writer to review the current 2.6 Admin Guide to see what needs to be worked on before the 2.7 release. I'm attaching the report here so we can reference it. Should have distributed it sooner but Life got in the way. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9596] New: Python test suite
by openldap-its＠openldap.org 07 Apr '26

07 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=9596 Issue ID: 9596 Summary: Python test suite Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- The bash test suite is extremely limited, hard to write for and slow. We can't lose it as it is also portable, but something should be introduced for developers/CI on more modern systems and increase coverage. A Python 3 seed for one is in development in MR!347. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 8890] adapt to 64-bit time_t on systems with 32-bit long
by openldap-its＠openldap.org 07 Apr '26

07 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8890 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |TEST --- Comment #20 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 8584c582 by Steve Langasek at 2026-04-05T19:30:39+00:00 ITS#8890 Handle sizeof(time_t) > sizeof(long) in format strings 64-bit time_t means that on some architectures, time_t is now larger than a long, and making some references in format strings incorrect. To avoid truncation or other size mismatch issues, always cast to a long long and read using %lld. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9398] New: Stale accesslog cookie due to unclean shutdown
by openldap-its＠openldap.org 07 Apr '26

07 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=9398 Issue ID: 9398 Summary: Stale accesslog cookie due to unclean shutdown Product: OpenLDAP Version: 2.4.56 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- If slapd terminates uncleanly, a checkpoint will be lost on the accesslog db. Depending on the syncprov overlay checkpoint settings (usually no checkpointing is enabled on the accesslog db) this can cause the system to refuse engage in replication at startup. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs