openldap-bugs

openldap-bugs@openldap.org

1 participants
21418 discussions

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

06 May '26

https://bugs.openldap.org/show_bug.cgi?id=6462 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |TEST --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • ed30d827 by Ondřej Kuzník at 2026-04-16T02:13:15+00:00 ITS#6462 libldap: Add ldap_domain2hostlist_proto • 3ebfd3e8 by Ondřej Kuzník at 2026-04-16T02:13:15+00:00 ITS#6462 clients: Enable DNS SRV resolution for ldaps connections • 69c2a54b by Ondřej Kuzník at 2026-04-16T02:13:15+00:00 ITS#6462 slapd-dnssrv: Enable DNS SRV resolution for ldaps -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8739] Better check for fsync on FreeBSD
by openldap-its＠openldap.org 06 May '26

06 May '26

https://bugs.openldap.org/show_bug.cgi?id=8739 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- mdb.RE/0.9: • 856c1fa8 by Howard Chu at 2026-04-15T20:04:30+01:00 ITS#8739 lmdb: No fdatasync on FreeBSD 11.0 and older mdb.master: • f759f0fc by Howard Chu at 2026-04-15T20:03:57+01:00 ITS#8739 lmdb: No fdatasync on FreeBSD 11.0 and older mdb.master3: • b2cfdd23 by Howard Chu at 2026-04-15T20:03:06+01:00 ITS#8739 lmdb: No fdatasync on FreeBSD 11.0 and older -- You are receiving this mail because: You are on the CC list for the issue.

1 0

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

06 May '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 5

[Issue 8824] openldap-2.4.46/libraries/liblmdb/mdb_dump.c:136]: (style) Suspicious condition
by openldap-its＠openldap.org 06 May '26

06 May '26

https://bugs.openldap.org/show_bug.cgi?id=8824 --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- mdb.RE/0.9: • 790035a2 by Howard Chu at 2026-04-15T18:18:39+01:00 ITS#8824 mdb_dump: cleanup check for MDB_SUCCESS mdb.master: • 331ba439 by Howard Chu at 2026-04-15T18:17:55+01:00 ITS#8824 mdb_dump: cleanup check for MDB_SUCCESS mdb.master3: • 5b3df476 by Howard Chu at 2026-04-15T18:18:44+01:00 ITS#8824 mdb_dump: cleanup check for MDB_SUCCESS -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8386] Small LMDB Documentation patch
by openldap-its＠openldap.org 06 May '26

06 May '26

https://bugs.openldap.org/show_bug.cgi?id=8386 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- mdb/RE0.9: • 9a647381 by Philipp Storz at 2026-04-15T17:32:58+01:00 ITS#8386 lmdb: be a bit more precise that mdb_get retrieves data in intro.doc mdb.master: • 7b5ffe1b by Philipp Storz at 2026-04-15T17:32:14+01:00 ITS#8386 lmdb: be a bit more precise that mdb_get retrieves data in intro.doc mdb.master3: • 06680017 by Philipp Storz at 2026-04-15T17:33:05+01:00 ITS#8386 lmdb: be a bit more precise that mdb_get retrieves data in intro.doc -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9011] add mdb_txn_flags()
by openldap-its＠openldap.org 04 May '26

04 May '26

https://bugs.openldap.org/show_bug.cgi?id=9011 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- Added to git mdb.master3, mdb.RE/1.0 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9011] add mdb_txn_flags()
by openldap-its＠openldap.org 03 May '26

03 May '26

https://bugs.openldap.org/show_bug.cgi?id=9011 --- Comment #4 from code(a)doriantaylor.com --- I was trying to determine why I got a notification for this bug, and I see now that it was because I filed a later one which was marked duplicate. Indeed, my remarks on issue 9188 constitute why a language binding would need to know if a transaction was read-only. In the Ruby bindings for LMDB which I now maintain, it's easy to find situations like db.transaction(true, &proc) # `true` enables read-only ...where `proc` itself does another transaction. I have semi-fixed this so read-only transactions "nest" by making the call a no-op if a transaction is already active, but it's still possible for read-write transactions to find their way inside read-only ones. So being able to create a `txn.readonly?` predicate would be useful for programmers downstream to better orient themselves. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

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

29 Apr '26

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

1 0

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

28 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8394 --- Comment #8 from bdallen(a)nps.edu <bdallen(a)nps.edu> --- Hi Howard, Please forgive me. Yes, I started this ten years ago on another project which was resolved. When I saw your new post https://bugs.openldap.org/show_bug.cgi?id=8394#c3 I assumed they were related. They are not. Good to hear you are still supporting LMDB. It worked very well for me. Cheers, -Bruce On 4/28/26 10:03, openldap-its(a)openldap.org wrote: > NPS WARNING: *external sender* verify before acting. > > > https://bugs.openldap.org/show_bug.cgi?id=8394 > > --- Comment #7 from Howard Chu <hyc(a)openldap.org> --- > (In reply to bdallen(a)nps.edu from comment #6) >> Hi Howard, >> >> I did not submit issue 8394. I suspect somebody in Pico Technical >> Support Team submitted this in my name in response to SUPPORT-63913 >> Crashing bug in pypicosdk that I submitted to support(a)picotech.com. I >> responded to you incorrectly believing I was working with Pico Technical >> Support. >> >> Meanwhile, I can offer some information: >> 1) You cannot reproduce this bug without having a PicoScope connected to >> a USB port and without "sudo apt install picoscope" per >> https://www.picotech.com/downloads/linux and without "pip install >> pypicosdk". >> 2) I would suspect the core dump reported is the result of object >> mismanagement in Python bindings in pypicosdk except that someone in >> Pico Technical Support has stated the fault is line 6590 of mdb.c. >> >> Please let me know if I can help. >> >> Regards, >> -Bruce > Thanks for the information. That initial report is from 10 years ago, and LMDB > v0.9.18 is long since obsolete. > > We're about to release v1.0.0. It would probably be worth seeing if you can > reproduce the problem with that release candidate. > https://git.openldap.org/openldap/openldap/-/tree/mdb.RE/1.0?ref_type=heads > > For what it's worth, using clang-20's -fsanitize=type sanitizer, it shows some > potential problems in v0.9.18 but it only gives false positives with the 1.0 > branch. > > -- > 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

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

28 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=8394 --- Comment #7 from Howard Chu <hyc(a)openldap.org> --- (In reply to bdallen(a)nps.edu from comment #6) > Hi Howard, > > I did not submit issue 8394. I suspect somebody in Pico Technical > Support Team submitted this in my name in response to SUPPORT-63913 > Crashing bug in pypicosdk that I submitted to support(a)picotech.com. I > responded to you incorrectly believing I was working with Pico Technical > Support. > > Meanwhile, I can offer some information: > 1) You cannot reproduce this bug without having a PicoScope connected to > a USB port and without "sudo apt install picoscope" per > https://www.picotech.com/downloads/linux and without "pip install > pypicosdk". > 2) I would suspect the core dump reported is the result of object > mismanagement in Python bindings in pypicosdk except that someone in > Pico Technical Support has stated the fault is line 6590 of mdb.c. > > Please let me know if I can help. > > Regards, > -Bruce Thanks for the information. That initial report is from 10 years ago, and LMDB v0.9.18 is long since obsolete. We're about to release v1.0.0. It would probably be worth seeing if you can reproduce the problem with that release candidate. https://git.openldap.org/openldap/openldap/-/tree/mdb.RE/1.0?ref_type=heads For what it's worth, using clang-20's -fsanitize=type sanitizer, it shows some potential problems in v0.9.18 but it only gives false positives with the 1.0 branch. -- 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