https://bugs.openldap.org/show_bug.cgi?id=9860
Issue ID: 9860
Summary: ldapsearch memory leaks
Product: OpenLDAP
Version: 2.5.12
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: hamano(a)osstech.co.jp
Target Milestone: ---
When using page control, The control value leaks with each goto getNextPage;
loop due to `i` and `nctrl` step back.
```
1114 getNextPage:
...
1124 save_nctrls = nctrls;
1125 i = nctrls;
```
```
1284 if ( ldap_create_page_control_value( ld,
1285 pageSize, &pr_cookie, &c[i].ldctl_value
) )
```
```
1445 /* step back to the original number of controls, so that
1446 * those set while parsing args are preserved */
1447 nctrls = save_nctrls;
```
```
1612 goto getNextPage;
```
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9718
Issue ID: 9718
Summary: test022 can fail on expiry
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
>>>>> Starting test022-ppolicy for mdb...
running defines.sh
Starting slapd on TCP/IP port 9011...
Using ldapsearch to check that slapd is running...
Testing redundant ppolicy instance...
Using ldapadd to populate the database...
Testing account lockout...
Waiting 13 seconds for lockout to reset...
Testing password expiration
Waiting seconds for password to expire...
sleep: missing operand
Try 'sleep --help' for more information.
Password expiration test failed
>>>>> test022-ppolicy failed for mdb after 43 seconds
(exit 1)
The issue here is apparently that line 122-123 failed to populate the DELAY
variable.
121
122 DELAY=`$LDAPSEARCH -D "$MANAGERDN" -H $URI1 -w $PASSWD \
123 -b "$USER" -E accountUsability 1.1 | sed -n -e
's/.*expire=\(\d*\)/\1/p'`
124
125 echo "Testing password expiration"
126 echo "Waiting $DELAY seconds for password to expire..."
127 sleep $DELAY
128 sleep 1
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9343
Issue ID: 9343
Summary: Expand ppolicy policy configuration to allow URL
filter
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Currently, ppolicy only supports a single global default policy, and past that
any policies must be manually added to a given user entry if they are supposed
to have something other than the default policy.
Also, some sites want no default policy, and only a specific subset to have a
policy applied to them.
For both of these cases, it would be helpful if it were possible to configure a
policy to apply to a set of users via a URL similar to the way we handle
creating groups of users in dynlist
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9600
Issue ID: 9600
Summary: Rework lloadd's cn=monitor interface (connections)
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
At the moment, most of the lloadd's monitor entries are generated on demand for
the search. To support management of the server and its connections, an entry
should be created when a connection is set up and torn down accordingly.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9806
Issue ID: 9806
Summary: MDB_PAGE_FULL on mdb_put
Product: LMDB
Version: unspecified
Hardware: Other
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: casey(a)rodarmor.com
Target Milestone: ---
I'm using the using latest lmdb from OpenLDAP, commit
e8813b12b6188d5ba5f174ff8726c438c8ca4bfd.
I'm getting an MDB_PAGE_FULL error after calling `mdb_put`. If I delete the
database and perform the same sequence of inserts, I get the same error in on
the same mdb_put.
If there's any information I can provide to help debug this, let me know.
--
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=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=9886
Issue ID: 9886
Summary: At "sync" logging, nothing shows how long a write op
took on consumers
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If sync logging is enabled on a consumer, there's no etime logged which means
it is not possible to see how long a write op took on that consumer. This can
be useful information to see how the node is performing, particularly if it is
a read only node where there will be no general MOD timing logged.
--
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.