openldap-bugs

openldap-bugs@openldap.org

1 participants
20945 discussions

[Issue 10024] New: MDB_PREVSNAPSHOT broken
by openldap-its＠openldap.org 21 Feb '25

21 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10024 Issue ID: 10024 Summary: MDB_PREVSNAPSHOT broken Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: markus(a)objectbox.io Target Milestone: --- It seems that the patch #9496 had a negative side effect on MDB_PREVSNAPSHOT. In certain cases, when opening the DB using MDB_PREVSNAPSHOT, the previous (2nd latest) commit is not selected. Instead, reads show that the latest commit was selected voiding the effect of MDB_PREVSNAPSHOT. I observed this in our test cases a while back. Today, I was finally able to reproduce it and debug into it. When creating the transaction to read the data, I debugged into mdb_txn_renew0. Here, ti (MDB_txninfo; env->me_txns) was non-NULL. However, ti->mti_txnid was 0 (!) and thus txn->mt_txnid was set to 0. That's the reason for always selecting the first (index 0) meta page inside mdb_txn_renew0: meta = env->me_metas[txn->mt_txnid & 1]; This line occurs twice (once for read txn and once for write txn; it affects both txn types). Thus, the chances of MDB_PREVSNAPSHOT selecting the correct meta page is 50-50. It's only correct if the first meta page (index 0) is the older one. I believe that this is related to #9496 because the patch, that was provided there, removed the initialization of "env->me_txns->mti_txnid" in mdb_env_open2. This would explain why txn->mt_txnid inside mdb_txn_renew0 was set to 0. I can confirm that adding back the following two lines back in fixes MDB_PREVSNAPSHOT: if (env->me_txns) env->me_txns->mti_txnid = meta.mm_txnid; The said patch including the removal of these two lines was applied in the commit(s) "ITS#9496 fix mdb_env_open bug from #8704" (Howard Chu on 09.04.21). I hope this information is useful to find a suitable fix. Please let me know if you have questions. Also, I'd be happy to help confirming a potential fix with our test suite. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10303] New: Web site still presents the 2.5 version as LTS
by openldap-its＠openldap.org 20 Feb '25

20 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10303 Issue ID: 10303 Summary: Web site still presents the 2.5 version as LTS Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: elecharny(a)apache.org Target Milestone: --- The OpenLDAP web site still indicates that the OpenLDAP 2.5 version is the LTS, despite a mail announced on August 10, 2024 that starting from January 2025 teh 2.6 branch will be the LTS. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10309] New: Handle potential null pointers returned by ber_strdup
by openldap-its＠openldap.org 20 Feb '25

20 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10309 Issue ID: 10309 Summary: Handle potential null pointers returned by ber_strdup Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: safecoding233(a)gmail.com Target Milestone: --- Created attachment 1052 --> https://bugs.openldap.org/attachment.cgi?id=1052&action=edit fix patch I added two null pointer checks for pointers returned by ber_strdup. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10265] New: Make it possible to change olcBkLloadListen at runtime
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10265 Issue ID: 10265 Summary: Make it possible to change olcBkLloadListen at runtime Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Currently, olcBkLloadListen changes only take effect on lloadd startup: - an added olcBkLloadListen should come online at the end of the modify operation - at the end of the modify operation a removed olcBkLloadListen will stop listening on the sockets associated with it, clients that connected over these are marked CLOSING - to facilitate replacing a value where URIs resolved sockets overlap, olcBkLloadListen should become a MAY in olcBkLloadConfig objectclass Lloadd's startup was modelled upon slapd's, but the requirements have changed considerably when it was turned into a module. Sockets are acquired at module configuration time, which is much later than standalone/slapd's own startup and so the way the URLs are handled also needs to be reworked. This will resolve other related issues. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Bug 9186] New: RFE: More metrics in cn=monitor
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=9186 Bug ID: 9186 Summary: RFE: More metrics in cn=monitor Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- Currently I'm grepping metrics from syslog with mtail: https://gitlab.com/ae-dir/ansible-ae-dir-server/-/blob/master/templates/mta… With a new binary logging this is not possible anymore. Thus it would be nice if cn=monitor provides more metrics. 1. Overall connection count per listener starting at 0 when started. This would be a simple counter added to: entries cn=Listener 0,cn=Listeners,cn=Monitor 2. Counter for the various "deferring" messages separated by the reason for deferring. 3. Counters for all possible result codes. In my mtail program I also label it with the result type. -- You are receiving this mail because: You are on the CC list for the bug.

1 15

[Issue 7249] slapd segfault with memberof overlay on frontend db
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=7249 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED --- Comment #23 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE26: • d66062dc by Ondřej Kuzník at 2025-02-19T18:37:48+00:00 ITS#7249 Let backend_attribute know who's calling it • 5c734d2b by Ondřej Kuzník at 2025-02-19T18:37:53+00:00 ITS#7249 Disallow memberof-addcheck when memberof is global -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10279] New: add debug notice also to client tools
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10279 Issue ID: 10279 Summary: add debug notice also to client tools Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: rossi.f(a)inwind.it Target Milestone: --- Created attachment 1040 --> https://bugs.openldap.org/attachment.cgi?id=1040&action=edit openldap-2.6.4-debug-notice.patch The command line -d option, when used for debugging, does nothing if openldap was not compiled byth --enable-debug option. For the server part there is a notice to the user regarding this, I propose to add the same also to client tools. Here is attached the simple patch. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10307] New: Regression when searching for nonexistent entries and no access to DB
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10307 Issue ID: 10307 Summary: Regression when searching for nonexistent entries and no access to DB Product: OpenLDAP Version: 2.5.17 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Patch incoming -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10302] New: Double free of idcursor
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10302 Issue ID: 10302 Summary: Double free of idcursor Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: simon.rupf(a)lzlabs.com Target Milestone: --- Created attachment 1050 --> https://bugs.openldap.org/attachment.cgi?id=1050&action=edit proposed patch, which was created from current master, but also applies to 2.6.6 While switching from Oracle Linux (a RHEL clone) 8 to 9 one of our larger LDAP samples started causing a double free error at the end of the slapadd run. While I can't share the LDIF in question and it didn't consistently cause the issue, only every 5-6 times it ran, I could ran gdb and valgrind on it and suggest the attached patch that resolves that error to re-occur. I validated the patch still applies to the current master branch of openldap, as well as to 2.6.6 on EL9 where we encountered this. The error originally observed was this (commands being run as ldap user): [...] rm -r /var/lib/ldap mkdir /var/lib/ldap slapadd -l /tmp/lz_vault_convert_add.ldif -q -w -n 2 PROXIED attributeDescription "LZVAULTPROFILECOUNT" inserted. PROXIED attributeDescription "LZVAULTGLOBALPROFILECOUNT" inserted. -#################### 100.00% eta none elapsed 03s spd 4.2 M/s Closing DB...double free or corruption (!prev) Under valgrind, the following trace could be observed: valgrind --vgdb=full --leak-check=full --show-leak-kinds=all --track-origins=yes slapadd -l /tmp/lz_vault_convert_add.ldif -q -w -n 2 ==502== Memcheck, a memory error detector ==502== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==502== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info ==502== Command: slapadd -l /tmp/lz_vault_convert_add.ldif -q -w -n 2 ==502== PROXIED attributeDescription "LZVAULTPROFILECOUNT" inserted. PROXIED attributeDescription "LZVAULTGLOBALPROFILECOUNT" inserted. ==502== Invalid read of size 8 ==502== at 0x1E65A9: mdb_cursor_close (mdb.c:7764) ==502== by 0x1F71B8: UnknownInlinedFun (tools.c:202) ==502== by 0x1F71B8: mdb_tool_entry_close (tools.c:152) ==502== by 0x1D8291: slapadd (slapadd.c:511) ==502== by 0x1348C6: main (main.c:540) ==502== Address 0x188c8af8 is 8 bytes inside a block of size 392 free'd ==502== at 0x4847B4C: free (vg_replace_malloc.c:989) ==502== by 0x22CEFE: mdb_cursors_close.isra.0 (mdb.c:2638) ==502== by 0x1EBAAE: mdb_txn_commit (mdb.c:3640) ==502== by 0x1F75E2: mdb_tool_entry_modify (tools.c:1066) ==502== by 0x1D9AF9: slap_tool_update_ctxcsn.part.0 (slapcommon.c:1069) ==502== by 0x1D8440: UnknownInlinedFun (slapcommon.c:962) ==502== by 0x1D8440: slapadd (slapadd.c:502) ==502== by 0x1348C6: main (main.c:540) ==502== Block was alloc'd at ==502== at 0x484482F: malloc (vg_replace_malloc.c:446) ==502== by 0x1E8699: mdb_cursor_open (mdb.c:7690) ==502== by 0x1F8C45: mdb_tool_entry_put (tools.c:707) ==502== by 0x1D8150: slapadd (slapadd.c:453) ==502== by 0x1348C6: main (main.c:540) [...] Please advise if I can provide any further diagnostics, while I can still relatively easily reproduce the issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10290] New: Combination of syncrepl+rwm+syncprov frees the wrong modlist
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10290 Issue ID: 10290 Summary: Combination of syncrepl+rwm+syncprov frees the wrong modlist Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- An MPR setup with rwm enabled (regardless of configuration it seems) will crash with the provided modlist being freed twice. This is the sequence of events of what is stored in op->orm_modlist, allocated and freed by whom, replacing the actual pointers to make it easier to track: syncrepl_message_to_op: preparing a modify with 0xoriginal syncrepl_op_modify: old modlist 0xoriginal replacing with 0xsyncrepl_op_modify rwm_op_modify: old modlist 0xsyncrepl_op_modify replacing with 0xrwm_op_modify <modify happens> syncrepl_modify_cb: freeing 0xsyncrepl_op_modify, replacing with 0xoriginal (forgetting 0xrwm_op_modify) rwm_op_rollback: freeing 0xoriginal replacing with 0xsyncrepl_op_modify syncrepl_message_to_op: went in with 0xoriginal, got 0xsyncrepl_op_modify back syncrepl_message_to_op: freeing 0xsyncrepl_op_modify Not sure who is at fault: syncrepl_modify_cb is the one freeing the wrong modlist, but then if backover were to work with an actual "stack", running response callbacks in the opposite order from the request, things would have been ok too. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

← Newer
1
2
3
4
5
6
7
...
2095
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs