https://bugs.openldap.org/show_bug.cgi?id=10258
Issue ID: 10258
Summary: test050 failure: connection_close race?
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: ---
Created attachment 1032
--> https://bugs.openldap.org/attachment.cgi?id=1032&action=edit
tail of slapd log
Running test050 repeatedly, the slapd managed to get itself into an apparent
inconsistency in the connections structure. The logs suggest that there might
be a race closing the connection. Unfortunately the sanitiser didn't initiate a
core dump in this case.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9244
Bug ID: 9244
Summary: API calls blocking after async connect
Product: OpenLDAP
Version: 2.4.49
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
Created attachment 721
--> https://bugs.openldap.org/attachment.cgi?id=721&action=edit
async connect test without TLS
My understanding of LDAP_OPT_CONNECT_ASYNC is that the attached program should
not block. If the connection does not establish fast enough, the bind call is
supposed to return LDAP_X_CONNECTING.
(At least that's how I understand it, based on the original behaviour (circa
2.4.23 up to 2.4.40) as well as the bind loop in back-meta. On the other hand,
the man page does "Subsequent calls to library routines will poll for
completion of the connect before performing further operations" which might be
interpreted as meaning they would block...)
In current releases it does block, as demonstrated by strace on Linux (latency
added using 'tc qdisc'):
[...]
connect(3, {sa_family=AF_INET, sin_port=htons(389),
sin_addr=inet_addr("192.168.1.204")}, 16) = -1 EINPROGRESS (Operation now in
progress)
write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=3, events=POLLOUT|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=3,
revents=POLLOUT}])
write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = 14
poll([{fd=3, events=POLLIN|POLLPRI}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
read(3, "0\f\2\1\1a\7\n", 8) = 8
read(3, "\1\0\4\0\4\0", 6) = 6
write(2, "OK: ldap_simple_bind_returned 0 "..., 42OK: ldap_simple_bind_returned
0 (Success)
) = 42
[...]
As discussed in IRC, I believe I bisected this down to commit ae6347bac, from
bug 8022. The reasoning is sound, but ldap_int_open_connection does not
actually return -2, only -1 or 0.
The patch is simple enough, but I'm also looking at some later commits that
were probably done to work around this, and might not be needed now (bug 8957,
bug 8968, bug 8980). Also need to test all setups thoroughly (ldap, ldaps,
STARTTLS, not to mention back-meta/asyncmeta).
I also notice that LDAP_OPT_CONNECT_ASYNC is not effective unless
LDAP_OPT_NETWORK_TIMEOUT is also set. It might be intentional, but the man page
doesn't mention this specifically, and I don't see why it would be necessary...
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=10160
Issue ID: 10160
Summary: Add negset and negurl for slapo-constraint
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: manu(a)netbsd.org
Target Milestone: ---
Created attachment 1003
--> https://bugs.openldap.org/attachment.cgi?id=1003&action=edit
Add negset and negurl for slapo-constraint
Add negset and negurl constraints for slapo-constraint. THe two new types are
logical not of set and url. They will fire a constraint violation if the set or
LDAP URL query is non empty.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10191
Issue ID: 10191
Summary: backend searches should respond to pause requests
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
A long running search will cause mods to cn=config to wait a long time. Search
ops should periodically check for threadpool pause requests.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9513
Issue ID: 9513
Summary: Enhanced debug output
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: enhancement
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
While debugging ITS#9479 I needed more information on which threads were doing
what actions. Also, when looking for delays/hangs/race conditions, the 1-second
granularity of the debug msg timestamp was inadequate. And also, some of the
debug output for the Search operation was being done in separate Debug calls
for a single line of output. This gets jumbled up pretty badly if other threads
are printing output as well.
New patch set will extend the debug timestamp to have fractional seconds too;
it will use clock_gettime for nanosecond resolution if available, otherwise use
gettimeofday for microsecond resolution. Also tweak the Search debug output to
only use one Debug invocation per line of output.
This is MR!279.
--
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=10250
Issue ID: 10250
Summary: syncrepl_diff_entry assumes attributes come in the
same order
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: ---
When trying to diff an entry, syncrepl_diff_entry explicitly assumes attribute
come in the same order. That's not always the case and could cause it to report
a spurious rewrite of the attribute.
Normally this is ok, unless the rewrite itself (not) occurring has other
side-effects, when it could cause issues. (e.g. a DB with memberof
inconsistencies being mysteriously repaired in some scenarios, which is how it
was found).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9225
Bug ID: 9225
Summary: back-mdb: Add support for PREPARE/2-phase commit
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Add support for PREPARE/2-phase commit in back-mdb
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9224
Bug ID: 9224
Summary: Add support for PREPARE/2-phase commit
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
In LMDB, add support for PREPARE/2-phase commits
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=10162
Issue ID: 10162
Summary: Fix for binary attributes data corruption in back-sql
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: dex.tracers(a)gmail.com
Target Milestone: ---
Created attachment 1006
--> https://bugs.openldap.org/attachment.cgi?id=1006&action=edit
Fix for binary attributes corruption on backed-sql
I've configured slapd to use back-sql (mariadb through odbc) and observed
issues with the BINARY data retrievals from the database. The length of the
attributes was properly reported, but the correct data inside was always 16384
bytes and after that point - some junk (usually filled-up with AAAAAAAA and
some other attributes data from memory).
During the debugging - I've noticed that:
- The MAX_ATTR_LEN (16384 bytes) is used to set the length of the data for
BINARY columns when SQLBindCol is done inside of the
"backsql_BindRowAsStrings_x" function
- After SQLFetch is done - data in row->cols[i] is fetched up to the specified
MAX_ATTR_LEN
- After SQLFetch is done - the correct data size (greater than MAX_ATTR_LEN) is
represented inside of the row->value_len
I'm assuming that slapd allocates the pointer in memory (row->cols[i]), fills
it with the specified amount of data (MAX_ATTR_LEN), but when forming the
actual attribute data - uses the length from row->value_len and so everything
from 16384 bytes position till row->value_len is just a junk from the memory
(uninitialized, leftovers, data from other variables).
After an investigation, I've find-out that:
- for BINARY or variable length fields - SQLGetData should be used
- SQLGetData supports chunked mode (if length is unknown) or full-read mode if
the length is known
- it could be used in pair with SQLBindCol after SQLFetch (!)
Since we have the correct data length inside of row->value_len, I've just added
the code to the backsql_get_attr_vals() function to overwrite the corrupted
data with the correct data by issuing SQLGetData request. And it worked -
binary data was properly retrieved and reported over LDAP!
My current concerns / help needed - I'm not very familiar with the memory
allocation/deallocation mechanisms, so I'm afraid that mentioned change can
lead to memory corruption (so far not observed).
Please review attached patch (testing was done on OPENLDAP_REL_ENG_2_5_13, and
applied on the master branch for easier review/application).
--
You are receiving this mail because:
You are on the CC list for the issue.