https://bugs.openldap.org/show_bug.cgi?id=10034
Issue ID: 10034
Summary: Assertion 'i < NUMKEYS(mp)' failed in
mdb_page_search_root()"
Product: LMDB
Version: 0.9.23
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: 763280032(a)qq.com
Target Milestone: ---
We found that when lmdb is opened after OS startup and data is written to it,
lmdb will trigger abort probabilistically(Restart the OS 600 times will trigger
once);
We want to know what situation triggers this issue(Assertion 'i < NUMKEYS(mp)'
failed in mdb_page_search_root()); we want to know if there is a problem with
our usage;
Please Help Us
(gdb) x/8s 0x8baee988
0x8baee988: "8\373Բ\b\371Բmdb.c:5542: Assertion 'i < NUMKEYS(mp)' failed in
mdb_page_search_root()"
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9619
Issue ID: 9619
Summary: mdb_env_copy2 with MDB_CP_COMPACT in mdb.master3
produces corrupt mdb file
Product: LMDB
Version: 0.9.29
Hardware: All
OS: Windows
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: kriszyp(a)gmail.com
Target Milestone: ---
When copying an LMDB database with mdb_env_copy2 with the MDB_CP_COMPACT with
mdb.master3, the resulting mdb file seems to be corrupt and when using it in
LMDB, I get segmentation faults. Copying without the compacting flag seems to
work fine. I apologize, I know this is not a very good issue report, as I
haven't had a chance to actually narrow this down to a more
reproducible/isolated case, or look for how to patch. I thought I would report
in case there are any ideas on what could cause this. The segmentation faults
always seem to be memory write faults (as opposed to try fault on trying to
read). Or perhaps the current backup/copying functionality is eventually going
to be replaced by incremental backup/copying anyway
(https://twitter.com/hyc_symas/status/1315651814096875520). I'll try to update
this if I get a chance to investigate more, but otherwise feel free to
ignore/consider low-priority since the work around is easy.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9360
Issue ID: 9360
Summary: MDB_BAD_TXN: Transaction must abort, has a child, or
is invalid
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: spam(a)markandruth.co.uk
Target Milestone: ---
I have 2 python scripts writing to a database (lmdb 0.9.26, py-lmdb 0.98) and
5-10 lua processes (with lightningmdb module which uses lmdb 0.9.22) which are
long-running serving queries from the database.
The database seems fine, not corrupted, and the python writes still working all
the time. But periodically (perhaps 10-20% of the time), in a way I am unable
to reliably reproduce, when the lua starts up every time a query is issued txn
dbi_open returns "MDB_BAD_TXN: Transaction must abort, has a child, or is
invalid". A direct restart of the processes does not fix this issue, however
stopping lua+python and then starting again after a 5-20s wait usually fixes
the issue. This has been reproduced over multiple servers but I'm at a loss as
to how to debug this any further?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9475
Issue ID: 9475
Summary: Add support for MAP_POPULATE
Product: LMDB
Version: unspecified
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: aa531811820(a)gmail.com
Target Milestone: ---
In some case (such as cloud computing platforms), the reading speed of large
files is very fast while the small files is very slow, and we have enough
memory, so we hope to prefetch the entire LMDB file into the memory during MMAP
through the MAP_POPULATE flag . According to our test, this is faster than
using readahead flag. Here are some test data:
# mmap with no readahead
read one sample: 0.2s
total time: 4800s
# mmap with readahead
read one sample: 0.0001s~0.03s
total time: 95.86s
# mmap with MAP_POPULATE
db init: 20s
read one sample: 0.0001s
total time: 78s
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9397
Issue ID: 9397
Summary: LMDB: A second process opening a file with
MDB_WRITEMAP can cause the first to SIGBUS
Product: LMDB
Version: 0.9.26
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: github(a)nicwatson.org
Target Milestone: ---
Created attachment 780
--> https://bugs.openldap.org/attachment.cgi?id=780&action=edit
Full reproduction of SIGBUS MDB_WRITEMAP issue (works on Linux only)
The fundamental problem is that a ftruncate() on Linux that makes a file
smaller will cause accesses past the new end of the file to SIGBUS (see the
mmap man page).
The sequence that causes a SIGBUS involves two processes.
1. The first process opens a new LMDB file with MDB_WRITEMAP.
2. The second process opens the same LMDB file with MDB_WRITEMAP and with an
explicit map_size smaller than the first process's map size.
* This causes an ftruncate that makes the underlying file *smaller*.
3. (Optional) The second process closes the environment and exits.
4. The first process opens a write transaction and writes a bunch of data.
5. The first process commits the transaction. This causes a memory read from
the mapped memory that's now past the end of the file. On Linux, this triggers
a SIGBUS.
Attached is code that fully reproduces the problem on Linux.
The most straightforward solution is to allow ftruncate to *reduce* the file
size if it is the only reader. Another possibility is check the file size and
ftruncate if necessary every time a write transaction is opened. A third
possibility is to catch the SIGBUS signal.
Repro note: I used clone() to create the subprocess to most straightforwardly
demonstrate that the problem is not due to inherited file descriptors. The
problem still manifests when the processes are completely independent.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9207
Bug ID: 9207
Summary: Remove Moznss compatibility layer
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: ---
For the 2.5 release, remove the MozNSS compatibility layer.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9204
Bug ID: 9204
Summary: slapo-constraint allows anyone to apply Relax control
Product: OpenLDAP
Version: 2.4.49
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
slapo-constraint doesn't limit who can use the Relax control, beyond the global
limits applied by slapd. In practice, for many modifications this means any
configured constraints are advisory only.
In my opinion this should be considered a bug, in design if not implementation.
I expect many admins would not read the man page closely enough to realize the
behaviour does technically adhere to the letter of what's written there.
Either slapd should require manage privileges for the Relax control globally,
or slapo-constraint should perform a check for manage privilege itself, like
slapo-unique does.
Quoting ando in https://bugs.openldap.org/show_bug.cgi?id=5705#c4:
> Well, a user with "manage" privileges on related data could bypass
> constraints enforced by slapo-constraint(5) by using the "relax"
> control. The rationale is that a user with manage privileges could be
> able to repair an entry that needs to violate a constraint for good
> reasons. Note that the user:
>
> - must have enough privileges to do it (manage)
>
> - must inform the DSA that intends to violate the constraint (by using
> the control)
but such privileges are currently not being required.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=10266
Issue ID: 10266
Summary: Adopt broader RFC4511 NoD interpretation on lloadd's
client side
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Server side, lloadd has long implemented a broad interpretation of NoD
unsolicited response handling: when the message is issued, no new requests are
accepted on the session however the client and server are both free to keep the
session open if there are any operations that have not resolved yet. The server
is still expected to close the connection as soon as no operations are still
pending.
This seems to interoperate with known clients. Those that want to will close
the session immediately, unaware of this possibility, those that also want to
interpret RFC 4511 this way can choose to wait for existing operations to
resolve.
This ticket is to track the lloadd's implementation of the client side of this
- when receiving a NoD message, we don't close the connection
immediately+unconditionally either but are willing to wait.
Related functionality:
- if connection was a bind connection processing a multi-stage SASL bind, the
bind should fail if/when the client attempts to progress it
- clients assigned to this connection through coherence at least 'connection'
are also marked closing
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10229
Issue ID: 10229
Summary: ldap_result, when invoked with MSG_RECEIVED and a
timeout value set to 0 (polling), does not return all
available messages until it is called again
Product: OpenLDAP
Version: 2.6.8
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
The issue is noticeable when ldap_result is used by the proxy back-ends. It has
not affected back-meta behavior, because when a first call is unsuccessful, it
retries with a small timeout. back-asyncmeta will also usually call it twice on
the same connection from different threads, although this is not a desired
behavior.
--
You are receiving this mail because:
You are on the CC list for the issue.