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.
https://bugs.openldap.org/show_bug.cgi?id=9193
Bug ID: 9193
Summary: HTML in mailing list description
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
e.g. https://lists.openldap.org/postorius/lists/openldap-devel.openldap.org/
contains code for links and formatting, but all inside of a <pre> block.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9660
Issue ID: 9660
Summary: back-mdb Permission denied => Restore from backup
Product: OpenLDAP
Version: 2.5.7
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: geert.hendrickx(a)telenetgroup.be
Target Milestone: ---
Cosmetic issue:
When an mdb database has incorrect ownership or permissions (typically after
slapadd as root), back-mdb fails with:
mdb_db_open: database "dc=my-domain,dc=com" cannot be opened: Permission denied
(13). Restore from backup!
"Permission denied" is correct, but "Restore from backup" is maybe not the most
appropriate advice. ;-)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9717
Issue ID: 9717
Summary: The RADIUSOV overlay can be incorporated into OpenLDAP
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: rdubner(a)symas.com
Target Milestone: ---
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9719
Issue ID: 9719
Summary: refreshOnly sends empty cookie when client up to date
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Syncprov will send an empty cookie if the consumer has the same cookie as
provider. To the best of my knowledge this is not in line with RFC4533 and
consumers would effectively drop their cookie when the search finishes.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9786
Issue ID: 9786
Summary: liblber: missing export of ber_pvt_wsa_err2string
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: tobias.junghans(a)veyon.io
Target Milestone: ---
When building (cross-compiling) OpenLDAP via GCC/mingw-w64, an undefined
reference to ber_pvt_wsa_err2string() is reported when libldap.dll is linked.
This can be fixed easily by adding ber_pvt_wsa_err2string() to
libraries/liblber/lber.map
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9677
Issue ID: 9677
Summary: Create "make install-strip” target
Product: OpenLDAP
Version: 2.5.7
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
All open source make-based projects shall follow the same naming and semantics
of targets, described at
https://www.gnu.org/prep/standards/html_node/Standard-Targets.html .
In particular “make install-strip” shall strip the binaries during the
installation, while “make install” shall not strip them.
In openldap currently “make install” does strip, which surprised me.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9640
Issue ID: 9640
Summary: ACL privilege for MOD_INCREMENT
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
I'm using LDAP write operations with MOD_INCREMENT with pre-read-control for
uidNumber/gidNumber generation.
I'd like to limit write access to an Integer attribute "nextID" to
MOD_INCREMENT, ideally even restricting the de-/increment value.
(Uniqueness is achieved with slapo-unique anyway but still I'd like to avoid
users messing with this attribute).
IMHO the ideal solution would be a new privilege "i".
Example for limiting write access to increment by one and grant read access for
using read control:
access to
attrs=nextID
val=1
by group=... =ri
Example for decrementing by two without read:
access to
attrs=nextID
val=-2
by group=... =i
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9612
Issue ID: 9612
Summary: Change index_hash64 default to on
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Change the default value of index_hash64. By default this means slapd won't
run on a 32-bit CPU (It will continue to work on 32-bit OSes running on 64-bit
CPUs).
If someone needs to run slapd on a 32-bit CPU they can turn this option off.
In the documentation, mark the option as deprecated for eventual removal in a
future release.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9580
Issue ID: 9580
Summary: Refresh vs. accesslog in delta-MPR
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: replication
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
A server consuming a plain syncrepl session (might be a delta-MMR refresh)
still has to log the entries into accesslog, however that accesslog stops being
capable of serving as a delta-sync source:
- operation entryCSNs will be out-of-order
- the changes logged will not be the intended modifications (e.g. if we fell
back after a conflict, the conflicting entry will be replaced with the other
version, other examples available)
We need to deal with that somehow, at the very least we need to make sure the
consumer will not take them at face value. We could record this in the
accesslog root entry if we can detect when this starts and match it up with the
final cookie, syncprov would still need some tweaks to understand it.
We could mark the entries received this way and make sure delta-consumers treat
them as "poison", as if they were running a plain syncrepl session themselves
(not update contextCSN until that's finished, mark its own accesslog entries
this way, ...). Anything like that needs guarantees that it will clean itself
up once all of the real plain sessions finish otherwise we've lost delta-sync
altogether.
A different approach might or might not be needed for live delta-persist
sessions replicating from a refreshing provider, but at least that syncprov has
a way of detecting this live if it chooses to.
--
You are receiving this mail because:
You are on the CC list for the issue.