https://bugs.openldap.org/show_bug.cgi?id=10018
Issue ID: 10018
Summary: lmdb runs for two years and triggers abort error
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: Zhou.chang(a)h3c.com
Target Milestone: ---
We found that when the Last transaction ID exceeds the maximum value, the
database abort signal will be triggered and two errors will be reported:
Assertion 'rc == 0' failed in mdb_page_dirty()
Assertion 'mp->mp_pgno != pgno' failed in mdb_page_touch()
I would like to ask whether the current lmdb has considered this situation,
./mdb_stat -e /tmp/lmdb
Environment Info
Map address: (nil)
Map size: 10485760
Page size: 4096
Max pages: 2560
Number of pages used: 238
Last transaction ID: 4294967295
Max readers: 126
Number of readers used: 2
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8447
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |TEST
--- Comment #4 from Howard Chu <hyc(a)openldap.org> ---
Fixed in mdb.master c7b3cc4df6dfe8f0772fb509bdc74777667caa43
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10007
Issue ID: 10007
Summary: lmdb does not work on MSYS2/Cygwin
Product: LMDB
Version: unspecified
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: facboy(a)gmail.com
Target Milestone: ---
lmdb can be compiled if the correct flags are set on MSYS2/Cygwin, but it does
not actually work. `make test` will result in errors.
If `make CPPFLAGS="-DMDB_USE_ROBUST=0"` is used, `mtest` fails with:
> mtest.c:50: mdb_env_open(env, "./testdb", MDB_FIXEDMAP , 0664): Invalid argument
> Aborted (core dumped)
If `make CPPFLAGS="-DMDB_USE_POSIX_SEM=1"` is used, `mtest` fails with:
> mtest.c:50: mdb_env_open(env, "./testdb", MDB_FIXEDMAP , 0664): No such file or directory
> Aborted (core dumped)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9972
Issue ID: 9972
Summary: SSS needs READ instead of SEARCH access
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
I have configured an OpenLDAP 2.6 server with
dn: olcDatabase=mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: mdb
olcAccess: to dn="cn=bodies,dc=aegee,dc=org"
by * search # no problem if this is READ
olcAccess: to dn.sub="dc=aegee,dc=org"
by * read
…
dn: olcOverlay=sssvlv,olcDatabase={1}mdb,cn=config
objectClass:olcOverlayConfig
The content of the tree is available anymously by calling
ldapsearch -ZZxH ldap://ldap.aegee.org -b "dc=aegee,dc=org" -s sub .
When I modify the call to use SSS:
ldapsearch -ZxH ldap://ldap.aegee.org -b "dc=aegee,dc=org" -s sub -E
sss=ou:2.5.13.15
it also returns results, but ends with
```
# search result
search: 93
result: 50 Insufficient access
# numResponses: 3
# numEntries: 2
```
When I modify above:
olcAccess: to dn="cn=bodies,dc=aegee,dc=org"
by * read
then the access is sufficient.
There is no entry called "dn:cn=bodies,dc=aegee,dc=org", or rather the entry
shall not be returned on searches and `ldapsearch -ZxH ldap://ldap.aegee.org -b
"dc=aegee,dc=org" -s sub` does not return it.
These work without a problem:
ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s one -E
sss=ou:2.5.13.15
ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s sub
ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s one
This produces Insufficient access:
ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s sub -E
sss=ou:2.5.13.15
That said client-side-sorting does work without a problem, but server-side
sorting requires not only SEARCH, but also READ privileges on
dn="cn=bodies,dc=aegee,dc=org".
I find this is a bug: SSS requires read-acesss to data, which is not supposed
to be returned to the client (dn:cn=bodies,dc=aegee,dc=org). For the
additional server-side sorting no additional privileges shall be required,
compared to returning the results without server-side-sorting.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10009
Issue ID: 10009
Summary: test076 execution failed
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: test suite
Assignee: bugs(a)openldap.org
Reporter: 1010881517(a)qq.com
Target Milestone: ---
openldap-2.6.3test case test076-authid-rewrite failed when I upgrade openssl to
openssl3.0
Does anyone have a similar problem?
>>>>> 00:27:30 Starting test076-authid-rewrite for mdb...
running defines.sh
Starting slapd on TCP/IP port 9011...
/home/abuild/rpmbuild/BUILD/openldap-2.6.3/openldap-2.6.3/tests
Using ldapsearch to check that slapd is running...
Checking whether DIGEST-MD5 is supported...
Adding schema and database...
Using ldapadd to populate the database...
Adding olcAuthzRegexp rule for static mapping...
Testing ldapwhoami as Manager...
./scripts/test076-authid-rewrite: line 177: 219330 Segmentation fault
(core dumped) $LDAPSASLWHOAMI -H $URI1 -Y $MECH -U $ID -w $PASSWD
ldapwhoami failed (139)!
>>>>> 00:27:33 Failed test076-authid-rewrite for mdb after 3 seconds
(exit 139)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10012
Issue ID: 10012
Summary: fcntl called without checking value
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: balaev(a)tarantool.org
Target Milestone: ---
Created attachment 949
--> https://bugs.openldap.org/attachment.cgi?id=949&action=edit
patch file
ldap_pvt_socket() and ldap_int_socket() calls fcntl without checking value of
file descriptor.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10008
Issue ID: 10008
Summary: Makefile does not building DLLs on Cygwin/MSYS2
Product: LMDB
Version: unspecified
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: facboy(a)gmail.com
Target Milestone: ---
Currently when building on Cygwin/MSYS2 make does not generate DLL files.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8447
--- Comment #3 from nicolas.werner(a)hotmail.de ---
I can reproduce this without using any cursors. I am using the lmdb++ header
for simplicity (https://github.com/hoytech/lmdbxx), but it also reproduces
using the plain C API. Full repro:
#include <iostream>
#include <stdlib.h>
#include "lmdb++.h"
#define PROJECT_NAME "mdb-dup-bug"
static int compare_state_key(const MDB_val *a, const MDB_val *b)
{
auto get_skey = [](const MDB_val *v) {
std::string_view data(static_cast<const char
*>(v->mv_data), v->mv_size);
return data.substr(0, data.find(','));
};
return get_skey(a).compare(get_skey(b));
}
int main(int argc, char **argv) {
if(argc != 1) {
std::cout << argv[0] << "takes no arguments.\n";
return 1;
}
std::cout << "This is project " << PROJECT_NAME << ".\n";
auto env = lmdb::env::create();
env.set_max_dbs(10);
char dirname[] = "/tmp/lmdb-bug.XXXXXX";
env.open(mkdtemp(dirname));
lmdb::dbi db;
{
auto txn = lmdb::txn::begin(env);
db = lmdb::dbi::open(
txn, std::string("dupsort").c_str(), MDB_CREATE | MDB_DUPSORT);
lmdb::dbi_set_dupsort(txn, db, compare_state_key);
db.put(txn, "abcd", "ab,cdef");
db.put(txn, "abcd", "a,abc");
txn.commit();
}
{
auto txn = lmdb::txn::begin(env);
std::string_view data;
db.get(txn, "abcd", data);
std::cout << "Data size: " << data.size() << " expected: 5, data:
'" << data << "', expected: 'a,abc'\n";
txn.commit();
}
{
auto txn = lmdb::txn::begin(env);
db.put(txn, "abcd", "a,12");
txn.commit();
}
{
auto txn = lmdb::txn::begin(env);
std::string_view data;
db.get(txn, "abcd", data);
std::cout << "Data size: " << data.size() << " expected: 4, data:
'" << data << "', expected: 'a,12'\n";
txn.commit();
}
{
auto txn = lmdb::txn::begin(env);
db.put(txn, "abcd", "a,x");
txn.commit();
}
{
auto txn = lmdb::txn::begin(env);
std::string_view data;
db.get(txn, "abcd", data);
std::cout << "Data size: " << data.size() << " expected: 3, data:
'" << data << "', expected: 'a,x'\n";
txn.commit();
}
return 0;
}
This prints the following output:
This is project mdb-dup-bug.
Data size: 5 expected: 5, data: 'a,abc', expected: 'a,abc'
Data size: 5 expected: 4, data: 'a,12c', expected: 'a,12'
Data size: 5 expected: 3, data: 'a,x2c', expected: 'a,x'
Commenting out the first put with the different data-key resolves the issue,
but certainly you would expect that replacing a duplicate replaces the size
too. Doing explicit delete before the put works around this issue.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=4501
--- Comment #5 from Fredrik Roubert <fredrik(a)roubert.name> ---
Java 1.5 is no longer sufficient to be able to build this code base using a
still supported JDK, so I propose updating the scope of this issue to Java 8
instead and then resolve that with this series of patches:
https://git.openldap.org/openldap/jdbcldap/-/merge_requests/6
--
You are receiving this mail because:
You are on the CC list for the issue.