https://bugs.openldap.org/show_bug.cgi?id=10163
Issue ID: 10163
Summary: Cleanup configure/test integration
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
The sed commandline configure uses to perform substitutions is getting unwieldy
and may be exceeding platform limits on various systems.
All of the BUILD_xxx substitutions for overlays are only used in tests/run.in.
They could be completely removed, and instead each of the enabled overlays
could be emitted into a separate file that just gets included by the test
scripts. There's no need for them to be part of the sed invocation at all.
There's also leftover BUILD_xxx cruft from backends that we've removed (e.g.
back-shell BUILD_SHELL) that nothing else in the tree references any more.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9739
Issue ID: 9739
Summary: Undefined reference to ber_sockbuf_io_udp in 2.6.0
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: simon.pichugin(a)gmail.com
Target Milestone: ---
While I was trying to build OpenLDAP 2.6 on Fedora Rawhide I've got the error
message:
/usr/bin/ld: ./.libs/libldap.so: undefined reference to
`ber_sockbuf_io_udp'
I've checked commits from https://bugs.openldap.org/show_bug.cgi?id=9673 and
found that 'ber_sockbuf_io_udp' was not added to
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblber/…
I've asked on the project's mailing list and got a reply:
"That symbol only exists if OpenLDAP is built with LDAP_CONNECTIONLESS
defined, which is not a supported feature. Feel free to file a bug report
at https://bugs.openldap.org/"
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
Hence, creating the bug.
--
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=9291
Issue ID: 9291
Summary: Detection of corrupted database files
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: markus(a)objectbox.io
Target Milestone: ---
Let's assume we have to deal with a corrupted database for whatever reason
(e.g. broken hardware or file system). Current behavior seems to be mostly
undefined, which is understandable as it's not known what is broken (e.g. there
are no checksums).
For example, I'm seeing a SIGBUS in mdb_page_touch because the cursor's top
page (mp) is pointing to invalid memory (0x7f99cf004000) during a commit:
mdb_page_touch mdb.c:2772
mdb_page_search mdb.c:6595
mdb_freelist_save mdb.c:3575
mdb_txn_commit mdb.c:4060
Cursor data at that point: mc_snum = 1, mc_top = 0; myki[0] = 0
A SIGBUS is troublesome as it crashes the process, and I wonder if there are
other ways to detect such inconsistencies. If that be possible there could be
user-specific handling in place. E.g. a user might start a new database file.
This issue was reported by our users, which also provided DB files:
https://github.com/objectbox/objectbox-java/issues/859
I did not find a lot of consistency checks besides MDB_PAGE_NOTFOUND and
MDB_CORRUPTED. Also, I think there's no current way to thoroughly check a DB
file (e.g. like fsck for the DB file)?
My first idea other than checksums was to walk through the branch pages from
the root and check if the referenced pages are within reasonable bounds. Also
check the page content (e.g. nodes, flags). Additionally (optionally?), it
should be possible to check that the key values are actually sorted.
So, it boils down to 3 points in summary:
1.) If there no way to check the DB file for consistency yet(?), which approach
do you think would make sense? There might be two modes; one for a through
check through all data, and a quick check that does not take long and could be
e.g. done when opening the DB. Goal is to avoid process crashes and let users
handle the situation.
2.) In general, is it possible to add more consistency checks in regular DB
operations?
3.) Could the the particular situation (for which I provided the stack trace)
detected (e.g. is myki[0] = 0 legal here?)
I'd be happy to provide a patch if you provide some direction where you want to
take that.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10203
Issue ID: 10203
Summary: no pkgconfig file included for liblmdb
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: otto(a)drijf.net
Target Milestone: ---
liblmdb does not ship with a pkgconfig file. More and more build systems rely
on presense of a pkgconfig file, so it would be nice if liblmdb installed
oneone. An example:
prefix=/usr/local
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include
Name: lmdb
Description: Lightning memory-mapped database: key-value data store
URL: https://www.symas.com/symas-embedded-database-lmdb
Version: 0.9.32
Libs: -L${libdir} -llmdb
Cflags: -I${includedir}
Thanks.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9388
Issue ID: 9388
Summary: mdb_stat for DupSort DBI shows incorrect data
Product: LMDB
Version: 0.9.26
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: AskAlexSharov(a)gmail.com
Target Milestone: ---
It doesn't include pages pages used for values.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10454
Issue ID: 10454
Summary: O_DSYNC is busted on macos
Product: LMDB
Version: unspecified
Hardware: All
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: pyry.kovanen(a)gmail.com
Target Milestone: ---
LMDB relies on O_DSYNC for writing the meta page, unfortunately it doesn't work
on macos. Previous discovery by the tigerbeetle guys:
https://github.com/tigerbeetle/viewstamped-replication-made-famous#leaderbo…,
some more context at https://x.com/jorandirkgreef/status/1532314169604726784.
I discovered this during benchmarking and was wondering why lmdb writes were
twice as fast as macos as on linux.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9223
Bug ID: 9223
Summary: Add support for incremental backup
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: ---
For LMDB 1.0, add support for incremental backups
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=10275
Issue ID: 10275
Summary: mdb_load could use a parameter to pass batch size
Product: LMDB
Version: 0.9.21
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: tools
Assignee: bugs(a)openldap.org
Reporter: gkwicker(a)amazon.com
Target Milestone: ---
Created attachment 1037
--> https://bugs.openldap.org/attachment.cgi?id=1037&action=edit
Patch to mdb_load.c in version 0.9.21
mdb_load is very slow when ingesting a large db. The attached patch (0.9.21
but will apply to other versions with modification) allows the user to pass a
batch size to be used instead of the default value of 100. Changing the batch
size to a larger value improves ingestion speed.
I, Gary Wicker, hereby place the following modifications to OpenLDAP Software
(and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose with or
without attribution and/or other notice.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10108
Issue ID: 10108
Summary: "mdb_dump -a" does not dump the main database
Product: LMDB
Version: 0.9.29
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: tuukka.pensala(a)gmail.com
Target Milestone: ---
In mdb_dump.c we have these instructions:
/* -a: dump main DB and all subDBs
* -s: dump only the named subDB
* -n: use NOSUBDIR flag on env_open
* -p: use printable characters
* -f: write to file instead of stdout
* -V: print version and exit
* (default) dump only the main DB
*/
However, contrary to the description, the option -a does not dump the main DB.
With argument -a "dumpit(..)" is called for the named databases, but not for
the unnamed one.
With the current behavior, if the data store contains subDBs and has user-added
data in the main DB, there seems to be no way to dump all of it at once using
mdb_dump.
--
You are receiving this mail because:
You are on the CC list for the issue.