https://bugs.openldap.org/show_bug.cgi?id=9919
Issue ID: 9919
Summary: The use of a separate section for cold code can cause
linking issues on macOS
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: mh-bcrayqnc(a)glandium.org
Target Milestone: ---
See e.g. https://github.com/llvm/llvm-project/issues/52767
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9365
Issue ID: 9365
Summary: Mem leaks with Æ-DIR providers
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
Created attachment 772
--> https://bugs.openldap.org/attachment.cgi?id=772&action=edit
valgrind output on openSUSE Tumbleweed x86_64
An Æ-DIR installation with self-compiled OpenLDAP 2.4.53 on Debian (now
buster) has memory leak issues on the Æ-DIR providers. The read-only
consumers do not have this issue. The provider config is more complex
with more overlays and more ACLs.
In this production deployment slapd is automatically restarted (by monit) when
memory consumption reaches 80%. Thus monitoring clearly shows a frequent saw
tooth pattern.
I've also tested on openSUSE Tumbleweed x86_64 with a RE24 build [1] by running
slapd under control of valgrind for a couple of minutes continously sending
simple bind operations (additional to the monitoring and other back-ground jobs
running).
Find valgrind output of my first attempt attached.
Does that make sense at all?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9923
Issue ID: 9923
Summary: extensible match ignored
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: francois(a)rcdevs.com
Target Milestone: ---
Hi,
I'm trying to use a matching rule with slapd as a proxy in front of Active
Directory with back-ldap
The request is something similar to
'(memberOf:1.2.840.113556.1.4.1941:=cn=gp1,o=Root)'
It works if I use it directly on AD.
Unfortunately, the request is ignored by slapd and not forwarded, I receive a
"success" but the result is empty.
The request is forwarded if I use something like this:
'(memberOf=cn=gp1,o=Root)'
Could it be possible to forward the request to the backend? slapd doesn't need
to understand the meaning of the OID.
slapd with matching rule:
[2022-09-28 11:07:39] begin get_filter
[2022-09-28 11:07:39] EXTENSIBLE
[2022-09-28 11:07:39] daemon: activity on 1 descriptor
[2022-09-28 11:07:39] end get_filter 0
[2022-09-28 11:07:39] filter: (?=undefined)
[2022-09-28 11:07:39] attrs: dn
[2022-09-28 11:07:39] conn=1000 op=1 SRCH base="o=root" scope=2 deref=0
filter="(?=undefined)"
slapd without matching rule:
[2022-09-28 11:07:47] begin get_filter
[2022-09-28 11:07:47] EQUALITY
[2022-09-28 11:07:47] get_ava: unknown attributeType memberOf
[2022-09-28 11:07:47]
[2022-09-28 11:07:47] end get_filter 0
[2022-09-28 11:07:47] daemon: epoll: listen=7 active_threads=0 tvp=NULL
[2022-09-28 11:07:47] daemon: epoll: listen=8 active_threads=0 tvp=NULL
[2022-09-28 11:07:47] filter: (?memberOf=cn=gp1,o=Root)
[2022-09-28 11:07:47] attrs: dn
[2022-09-28 11:07:47] conn=1001 op=1 SRCH base="o=root" scope=2 deref=0
filter="(?memberOf=cn=gp1,o=Root)"
searchrequest dump:
0000 30 56 02 01 02 63 51 04 06 6f 3d 72 6f 6f 74 0a 0V...cQ..o=root.
0010 01 02 0a 01 00 02 01 00 02 01 00 01 01 00 a9 32 ...............2
0020 81 17 31 2e 32 2e 38 34 30 2e 31 31 33 35 35 36 ..1.2.840.113556
0030 2e 31 2e 34 2e 31 39 34 31 82 08 6d 65 6d 62 65 .1.4.1941..membe
0040 72 4f 66 83 0d 63 6e 3d 67 70 31 2c 6f 3d 52 6f rOf..cn=gp1,o=Ro
0050 6f 74 30 04 04 02 64 6e ot0...dn
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9878
Issue ID: 9878
Summary: test043 failures in 2.5/2.6
Product: OpenLDAP
Version: unspecified
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: ---
With test043 update for ITS#9823, we manage to introduce a scenario where the
server is completely idle except for a runqueue change.
This is partly identical with ITS#9642 and a similar approach would work.
Except that changes our module facing ABI so might not be something we can
backport. For the streams we can't, we might have to change the test to make
the server not idle.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9922
Issue ID: 9922
Summary: Uninitialized value reading in
clients/tools/common.c:tool_bind()
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
One possible flow in
https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/comm…
is:
int err;
if ( result ) {
rc = ldap_parse_result( ld, result, &err, &matched, &info, &refs, &ctrls, 1
);
if ( rc != LDAP_SUCCESS ) {
tool_perror( "ldap_bind parse result", rc, NULL, matched, info, refs );
tool_exit( ld, LDAP_LOCAL_ERROR );
}
}
if ( err != LDAP_SUCCESS …
When result is NULL, err is not initialized, and the last line reads
uninitialized value.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9030
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |0.9.30
--- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
RE0.9:
• 4bb20ed0
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9030
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #2 from Howard Chu <hyc(a)openldap.org> ---
patched in mdb.master ; mdb.master3 ; mdb.RE/0.9
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9918
Issue ID: 9918
Summary: Can't log on git.openldap.org
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: mh-bcrayqnc(a)glandium.org
Target Milestone: ---
Followup for https://github.com/LMDB/lmdb/pull/23#issuecomment-1254532527.
I created the account in February, apparently, with login glandium, but I'm not
sure what email. Presumably the one from this bugzilla account.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9524
Issue ID: 9524
Summary: Removing last entry in database triggers MDB_PROBLEM
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: kriszyp(a)gmail.com
Target Milestone: ---
With a fresh database, if you have have an open read transaction, and you
create a new entry in a write transaction and commit it, and then create a new
transaction and delete that entry, when you commit, it will return an
MDB_PROBLEM from approximately line 4408 from the mt_loose_count/dirty_list
check. This seems to occur on mdb.master3, but not mdb.master. Here is a
minimal example/test-case of how to reproduce:
MDB_env* env;
mdb_env_create(&env);
int rc, flags = 0;
mdb_env_open(env, "test", flags, 0664);
MDB_txn* readonly_txn;
mdb_txn_begin(env, nullptr, MDB_RDONLY, &readonly_txn);
MDB_txn* txn;
MDB_dbi dbi;
mdb_txn_begin(env, nullptr, 0, &txn);
mdb_dbi_open(txn, nullptr, MDB_CREATE, &dbi);
MDB_val val;
val.mv_data = (void*) "test";
val.mv_size = 4;
mdb_put(txn, dbi, &val, &val, 0);
mdb_txn_commit(txn);
mdb_txn_begin(env, nullptr, 0, &txn);
mdb_del(txn, dbi, &val, nullptr);
rc = mdb_txn_commit(txn); // this returns MDB_PROBLEM
(let me know if this should be submitted differently)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9910
Issue ID: 9910
Summary: undefined MDB_FDATASYNC in mdb.master3 on macOs
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: info(a)parlepeuple.fr
Target Milestone: ---
Created attachment 912
--> https://bugs.openldap.org/attachment.cgi?id=912&action=edit
patch
I am using the mdb.master3 branch which contains the encryption codebase.
While testing on macOS, compilation fails with "undefined MDB_FDATASYNC"
This is because commit #d85fe32
https://git.openldap.org/openldap/openldap/-/commit/d85fe32dab55b88cec25fc7…
introduced a bug in the sense that the #elif on line 167 is not executed if the
previous #elif is true.
So when defined(__APPLE__) && !defined(MDB_USE_ROBUST) is true, the following
#elif is skipped.
But this seconf @elif is essential, as it defines MDB_FDATASYNC
Proposed patch:
---
libraries/liblmdb/mdb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c
index 5bdec70..b54c8ae 100644
--- a/libraries/liblmdb/mdb.c
+++ b/libraries/liblmdb/mdb.c
@@ -164,9 +164,10 @@ typedef SSIZE_T ssize_t;
#if defined(__FreeBSD__) && defined(__FreeBSD_version) && __FreeBSD_version >=
1100110
# define MDB_USE_POSIX_MUTEX 1
# define MDB_USE_ROBUST 1
-#elif defined(__APPLE__) && !defined(MDB_USE_ROBUST)
-# define MDB_USE_POSIX_SEM 1
#elif defined(__APPLE__) || defined (BSD) || defined(__FreeBSD_kernel__)
+# if defined(__APPLE__) && !defined(MDB_USE_ROBUST)
+# define MDB_USE_POSIX_SEM 1
+# endif
# if !(defined(MDB_USE_POSIX_MUTEX) || defined(MDB_USE_POSIX_SEM))
# define MDB_USE_SYSV_SEM 1
# endif
--
--
You are receiving this mail because:
You are on the CC list for the issue.