[Issue 9381] New: librewrite warnings for unused variables
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9381
Issue ID: 9381
Summary: librewrite warnings for unused variables
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
There are some unused variables in librewrite that need fixing, and one case
where an rc is set but never returned which also needs addressing.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 week, 3 days
[Issue 9380] New: connection_write_resume should be type void rather than int
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9380
Issue ID: 9380
Summary: connection_write_resume should be type void rather
than int
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
connection_write_resume does not return anything, but is declared to return an
int. This can cause compile failure depending on the flags used during
compilation (-Werror=return-type)
--
You are receiving this mail because:
You are on the CC list for the issue.
1 week, 3 days
[Issue 9341] New: Delta-sync MPR needs to be stable regardless of ordering
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9341
Issue ID: 9341
Summary: Delta-sync MPR needs to be stable regardless of
ordering
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: replication
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If two or more updates are spread across several providers before they have a
chance to learn about the others, all replicas need to arrive at the same
content regardless of the order in which they arrive.
One example that is broken at the moment:
- (csn a) server 1 accepts a modify
- (csn b) server 2 accepts a delete on the same DN
- (csn c) server 2 accepts an add on that DN again
If a replica receives the actions in the order bca vs. abc, the content of the
entry will be different even though the final CSN set is the same -> they will
never converge. The ordering 'bac' also needs to result in eventual
convergence, even if it means a refresh or replication from either provider
stalling temporarily?
Merge request with this test case (so far):
https://git.openldap.org/openldap/openldap/-/merge_requests/145
--
You are receiving this mail because:
You are on the CC list for the issue.
2 weeks
[Issue 9379] New: slapd should reject invalid listener URLs
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9379
Issue ID: 9379
Summary: slapd should reject invalid listener URLs
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: trivial
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Most common instance of invalid listener URLs is specifying an ldapi URL
without URLencoding the socket pathname. Then the slashes in the pathname are
treated as URL field separators, which yields a pathname quite different from
what was intended.
--
You are receiving this mail because:
You are on the CC list for the issue.
2 weeks, 3 days
[Issue 9354] New: Tool for monitoring slapd status
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9354
Issue ID: 9354
Summary: Tool for monitoring slapd status
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: enhancement
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Something we've seen in various scripts many times - this tool continuously
reports operation counts from cn=Monitor and tracks contextCSN from a specified
baseDN, polling at the specified interval (default 10 seconds). It tracks when
contextCSN changes start and stop, and for a set of multiprovider servers,
reports the lag between consumers and providers.
Sample output of a screen:
2020-09-21 06:25:36
ldap://tx01
Entries Bind Unbind Search Compare Modify
ModDN Add Delete Abandon Extended
Num 1601143 95 108 617710 0 0
0 600000 0 0 9
Num/s 0.00 0.00 0.00 0.40 0.00 0.00
0.00 0.00 0.00 0.00 0.00
contextCSN: 20200921004518.559704Z#000000#001#000000 idle
contextCSN: 20200921004548.656746Z#000000#002#000000 actv@2020-09-21 00:58:57,
idle@2020-09-21 01:12:24, sync'd, max delta 00:03:11
contextCSN: 20200921004446.224575Z#000000#003#000000 actv@2020-09-21 00:58:57,
idle@2020-09-21 01:12:24, sync'd, max delta 00:02:54
contextCSN: 20200921004331.841460Z#000000#004#000000 actv@2020-09-21 00:58:57,
idle@2020-09-21 01:12:24, sync'd, max delta 00:02:19
ldap://tx02
Entries Bind Unbind Search Compare Modify
ModDN Add Delete Abandon Extended
Num 1601143 105 120 2217678 0 0
0 400000 200000 0 3
Num/s 0.00 0.00 0.00 0.40 0.00 0.00
0.00 0.00 0.00 0.00 0.00
contextCSN: 20200921004518.559704Z#000000#001#000000 actv@2020-09-21 00:58:57,
idle@2020-09-21 01:11:33, sync'd, max delta 00:03:09
contextCSN: 20200921004548.656746Z#000000#002#000000 idle
contextCSN: 20200921004446.224575Z#000000#003#000000 actv@2020-09-21 00:58:57,
idle@2020-09-21 01:11:33, sync'd, max delta 00:02:52
contextCSN: 20200921004331.841460Z#000000#004#000000 actv@2020-09-21 00:58:57,
idle@2020-09-21 01:11:33, sync'd, max delta 00:02:17
ldap://uk03
Entries Bind Unbind Search Compare Modify
ModDN Add Delete Abandon Extended
Num 1601143 1407 107 675570 0 3677
0 601135 14 0 3
Num/s 0.00 0.00 0.00 0.40 0.00 0.00
0.00 0.00 0.00 0.00 0.00
contextCSN: 20200921004518.559704Z#000000#001#000000 actv@2020-09-21 00:58:57,
idle@2020-09-21 01:05:56, sync'd, max delta 00:02:11
contextCSN: 20200921004548.656746Z#000000#002#000000 actv@2020-09-21 00:58:57,
idle@2020-09-21 01:05:56, sync'd, max delta 00:02:14
contextCSN: 20200921004446.224575Z#000000#003#000000 idle
contextCSN: 20200921004331.841460Z#000000#004#000000 actv@2020-09-21 00:58:57,
idle@2020-09-21 01:05:56, sync'd, max delta 00:01:33
ldap://uk04
Entries Bind Unbind Search Compare Modify
ModDN Add Delete Abandon Extended
Num 1601143 98 116 2217670 0 0
0 400000 200000 0 3
Num/s 0.00 0.00 0.00 0.40 0.00 0.00
0.00 0.00 0.00 0.00 0.00
contextCSN: 20200921004518.559704Z#000000#001#000000 actv@2020-09-21 00:58:57,
idle@2020-09-21 01:02:11, sync'd, max delta 00:01:13
contextCSN: 20200921004548.656746Z#000000#002#000000 actv@2020-09-21 00:58:57,
idle@2020-09-21 01:02:11, sync'd, max delta 00:01:17
contextCSN: 20200921004446.224575Z#000000#003#000000 actv@2020-09-21 00:58:57,
idle@2020-09-21 01:02:11, sync'd, max delta 00:01:01
contextCSN: 20200921004331.841460Z#000000#004#000000 idle
--
You are receiving this mail because:
You are on the CC list for the issue.
3 weeks, 4 days
[Issue 9364] New: Rework encryption API
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9364
Issue ID: 9364
Summary: Rework encryption API
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Currently a single initialization vector is set at env creation time, and is
used for the entire life of the DB. Ideally it should be a value uniquely
generated on every write to a page. The most straightforward approach would be
to use a combination of the page number and txid. Even better would be to use a
keyed hash of these two values.
--
You are receiving this mail because:
You are on the CC list for the issue.
4 weeks
[Issue 9382] New: client tools ldapvc.c tracks criticality but doesn't use it
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9382
Issue ID: 9382
Summary: client tools ldapvc.c tracks criticality but doesn't
use it
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
In clients/toolsldapv.c, we have:
switch ( i ) {
char *control, *cvalue;
int crit;
...
case 'E': /* vc extension */
crit = 0;
if( optarg[0] == '!' ) {
crit = 1;
and then we never use "crit" again. It would appear the intention was to
determine whether or not this control is marked critical and then do something
based on that, but there is in fact nothing ever done.
This leads to a warning that crit is set but unused.
If the criticality of the control doesn't matter, than this variable should be
eliminated. If it does matter, then the missing code needs to be added.
--
You are receiving this mail because:
You are on the CC list for the issue.
4 weeks, 1 day
[Issue 9378] New: Crash in mdb_put() / mdb_page_dirty()
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9378
Issue ID: 9378
Summary: Crash in mdb_put() / mdb_page_dirty()
Product: LMDB
Version: 0.9.26
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: nate(a)kde.org
Target Milestone: ---
The KDE Baloo file indexer uses lmdb as its database (source code available at
https://invent.kde.org/frameworks/baloo). Our most common crash, with over 100
duplicate bug reports, is in lmdb. Here's the bug report tracking it:
https://bugs.kde.org/show_bug.cgi?id=389848.
The version of lmdb does not seem to matter much. We have bug reports from Arch
users with lmdb 0.9.26 as well as bug reports from people using many earlier
versions.
Here's an example backtrace, taken from
https://bugs.kde.org/show_bug.cgi?id=426195:
#6 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#7 0x00007f3c0bbb9859 in __GI_abort () at abort.c:79
#8 0x00007f3c0b23ba83 in mdb_assert_fail (env=0x55e2ad710600,
expr_txt=expr_txt@entry=0x7f3c0b23e02f "rc == 0",
func=func@entry=0x7f3c0b23e978 <__func__.7221> "mdb_page_dirty",
line=line@entry=2127, file=0x7f3c0b23e010 "mdb.c") at mdb.c:1542
#9 0x00007f3c0b2306d5 in mdb_page_dirty (mp=<optimized out>,
txn=0x55e2ad7109f0) at mdb.c:2114
#10 mdb_page_dirty (txn=0x55e2ad7109f0, mp=<optimized out>) at mdb.c:2114
#11 0x00007f3c0b231966 in mdb_page_alloc (num=num@entry=1,
mp=mp@entry=0x7f3c0727aee8, mc=<optimized out>) at mdb.c:2308
#12 0x00007f3c0b231ba3 in mdb_page_touch (mc=mc@entry=0x7f3c0727b420) at
mdb.c:2495
#13 0x00007f3c0b2337c7 in mdb_cursor_touch (mc=mc@entry=0x7f3c0727b420) at
mdb.c:6523
#14 0x00007f3c0b2368f9 in mdb_cursor_put (mc=mc@entry=0x7f3c0727b420,
key=key@entry=0x7f3c0727b810, data=data@entry=0x7f3c0727b820,
flags=flags@entry=0) at mdb.c:6657
#15 0x00007f3c0b23976b in mdb_put (txn=0x55e2ad7109f0, dbi=5,
key=key@entry=0x7f3c0727b810, data=data@entry=0x7f3c0727b820,
flags=flags@entry=0) at mdb.c:9022
#16 0x00007f3c0c7124c5 in Baloo::DocumentDB::put
(this=this@entry=0x7f3c0727b960, docId=<optimized out>,
docId@entry=27041423333263366, list=...) at ./src/engine/documentdb.cpp:79
#17 0x00007f3c0c743da7 in Baloo::WriteTransaction::replaceDocument
(this=0x55e2ad7ea340, doc=..., operations=operations@entry=...) at
./src/engine/writetransaction.cpp:232
#18 0x00007f3c0c736b16 in Baloo::Transaction::replaceDocument
(this=this@entry=0x7f3c0727bc10, doc=..., operations=operations@entry=...) at
./src/engine/transaction.cpp:295
#19 0x000055e2ac5d6cbc in Baloo::UnindexedFileIndexer::run
(this=0x55e2ad79ca20) at
/usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:60
#20 0x00007f3c0c177f82 in QThreadPoolThread::run (this=0x55e2ad717f20) at
thread/qthreadpool.cpp:99
#21 0x00007f3c0c1749d2 in QThreadPrivate::start (arg=0x55e2ad717f20) at
thread/qthread_unix.cpp:361
#22 0x00007f3c0b29d609 in start_thread (arg=<optimized out>) at
pthread_create.c:477
#23 0x00007f3c0bcb6103 in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
--
You are receiving this mail because:
You are on the CC list for the issue.
1 month