#48311 nunc-stans: Attempt to release connection that is not acquired
Closed: wontfix None Opened 8 years ago by rmeggins.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1271330

Description of problem:
DS with nunc stans enabled produces lots of messages like
[13/Oct/2015:11:29:24 -0400] connection - conn=98 fd=161 Attempt to release
connection that is not acquired

Version-Release number of selected component (if applicable):
389-ds-base-1.3.4.0-19.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. Enable nunc stans and restart the server
nsslapd-enable-nunc-stans: on

2. Add 1k users with ldclt
ldclt -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -f cn=MrXXXXXX
-b "ou=people,dc=example,dc=com" -e add,person,incr,noloop,commoncounter -r0
-R1000

3. Check errors log for "Attempt to release connection that is not acquired"

Actual results:
grep "Attempt to release connection that is not acquired" -c
/var/log/dirsrv/slapd-instance/errors
1024

Expected results:


Additional info:

9c84b93..97946bd master -> master
commit 97946bd
Author: Mark Reynolds mreynolds@redhat.com
Date: Fri Oct 23 15:17:44 2015 -0400

f27c164..a8d30b3 389-ds-base-1.3.4 -> 389-ds-base-1.3.4
commit a8d30b3

Wrap calls with if statements to validate returns when we do not use PR_ASSERT
0001-Ticket-48311-nunc-stans-Attempt-to-release-connectio.2.patch

Hi,

I reviewed this, and I wondered why we would do something like:

connection_acquire_nolock(conn); /* event framework now has a reference */

But we wouldn't check the return. I've added a patch that checks these returns, but I want you to see if it's relevant or if there is a better way to handle this.

Thanks!

Replying to [comment:7 firstyear]:

Hi,

I reviewed this, and I wondered why we would do something like:

connection_acquire_nolock(conn); /* event framework now has a reference */

But we wouldn't check the return. I've added a patch that checks these returns, but I want you to see if it's relevant or if there is a better way to handle this.

Thanks!

This looks good, but your indentation is off. Looks like you used spaces instead of tabs. While we want to use spaces where possible, the surrounding code is using tabs, so it should match the existing code.

Okay, just wanting to confirm in all three cases that a straight return is an appropriate action to take. Should we be logging the error, or doing something else as well?

Replying to [comment:9 firstyear]:

Okay, just wanting to confirm in all three cases that a straight return is an appropriate action to take. Should we be logging the error, or doing something else as well?

Logging would be nice. If these conditions are hit it would be a serious issue.

A side note: without William's patch [1], we are having these warnings.
{{{
In file included from ldap/servers/slapd/slap.h:125:0,
from ldap/servers/slapd/daemon.c:48:
ldap/servers/slapd/daemon.c: In function 'ns_handle_closure':
../nunc-stans-0.1.7/include/nunc-stans/nunc-stans.h:305:37: warning: value computed is not used [-Wunused-value]
#define NS_JOB_IS_THREAD(eee) ((eee)&NS_JOB_THREAD)
^
ldap/servers/slapd/daemon.c:1839:2: note: in expansion of macro 'NS_JOB_IS_THREAD'
NS_JOB_IS_THREAD(ns_job_get_type(job));
^
ldap/servers/slapd/daemon.c: In function 'ns_handle_pr_read_ready':
../nunc-stans-0.1.7/include/nunc-stans/nunc-stans.h:305:37: warning: value computed is not used [-Wunused-value]
#define NS_JOB_IS_THREAD(eee) ((eee)&NS_JOB_THREAD)
^
ldap/servers/slapd/daemon.c:1922:2: note: in expansion of macro 'NS_JOB_IS_THREAD'
NS_JOB_IS_THREAD(ns_job_get_type(job));
^
}}}

[1] https://fedorahosted.org/389/attachment/ticket/48311/0001-Ticket-48311-nunc-stans-Attempt-to-release-connectio.3.patch

Attachment 0001-Ticket-48311-nunc-stans-Attempt-to-release-connectio.5.patch​ added
Change to DEBUG_ANY

Acked. Thanks, William!

Pushed to 389-ds-base-1.3.4, as well:
d192435..b039876 389-ds-base-1.3.4 -> 389-ds-base-1.3.4
commit b039876

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.5.0

7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1642

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata