[Issue 9736] New: pwrite bug in OSX breaking LMDB promise about the maximum value size
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9736
Issue ID: 9736
Summary: pwrite bug in OSX breaking LMDB promise about the
maximum value size
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: renault.cle(a)gmail.com
Target Milestone: ---
Hi,
I was working with LMDB and found an issue when trying to write a value of
approximately 3.3GiB in the database, I dive into the LMDB source code of the
mdb_put method using the lldb debugger and found out that it was not related to
an issue in LMDB itself but rather a bug in the pwrite function of the Mac OS
libc implementation.
The pwrite function is given four parameters, the file descriptor, the buffer,
the count of bytes to write from the buffer and, the offset of where to write
it in the file. On Mac OS the count of bytes is a size_t that must be a 64bits
unsigned integer but when you call pwrite with a number bigger or equal to 2^31
it returns an error 22 (invalid argument). LMDB was returning a 22 error from
the mdb_put call and not an EINVAL because the error was cause by an internal
issue and not something catchable by LMDB.
I am not sure about what we can do, can we implement this single pwrite [1] as
multiple pwrite with counts smaller than 2^31 in a loop, just for Mac OS? Like
for Windows where we do specific things for this operating system too?
I also found this issue on the RocksDB repository [2] about a similar problem
they have with pwrite and write on Mac OS it seems. I understand that this is
not a real promise that LMDB is specifying but rather an "in theory" rule [3].
Thank you for your time,
kero
[1]:
https://github.com/LMDB/lmdb/blob/01b1b7dc204abdf3849536979205dc9e3a0e3ec...
[2]: https://github.com/facebook/rocksdb/issues/5169
[3]: http://www.lmdb.tech/doc/group__mdb.html#structMDB__val
--
You are receiving this mail because:
You are on the CC list for the issue.
7 months, 3 weeks
[Issue 9735] New: [PATCH] try hard to find free space if database cannot grow
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9735
Issue ID: 9735
Summary: [PATCH] try hard to find free space if database cannot
grow
Product: LMDB
Version: 0.9.24
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: libor.peltan(a)nic.cz
Target Milestone: ---
Created attachment 851
--> https://bugs.openldap.org/attachment.cgi?id=851&action=edit
Patch fixing the issue "try hard to find free space if database cannot grow"
Note:
- the issue is the same in version 0.9.70 (git)
Situation:
- the database had already grown to its limit (mapsize) in the past
- overflow pages are used heavily as stored values are usually several pages
long
- free space got fragmented
Problem:
- attempt to insert new value results in MDB_MAP_FULL despite there is free
space available
Cause: there is a heursitic in mdb_page_alloc() that gives up searching for
free space chunk if this would take too much time. This is useful when the
database can still grow, as it balances performance with space usage. However,
if the database can no longer grow, it prevents inserting new values.
Solution: detect early on in mdb_page_alloc() if the database can grow, and if
not, let it try hard to search for free space.
Patch: attached
--
You are receiving this mail because:
You are on the CC list for the issue.
7 months, 3 weeks
[Issue 9744] New: Phoenix American Financial Services
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9744
Issue ID: 9744
Summary: Phoenix American Financial Services
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: robertleemaxpro(a)gmail.com
Target Milestone: ---
Phoenix American Financial Services provides full-service fund administration,
fund accounting, transfer agent and investor services as well as sales and
marketing reporting to fund sponsors in the alternative investment industry.
Visit site: https://www.phxa.com/
--
You are receiving this mail because:
You are on the CC list for the issue.
7 months, 3 weeks
[Issue 9741] New: Meaningless out-of-bound read in ldif-filter.c
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9741
Issue ID: 9741
Summary: Meaningless out-of-bound read in ldif-filter.c
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: matthias.st.pierre(a)ncp-e.com
Target Milestone: ---
I just stumbled over the following compiler warning in ldif-filter.c (see [1]):
14:10:41 ldif-filter.c:209:16: warning: adding 'int' to a string does not
append to the string [-Wstring-plus-int]
14:10:41 sep = "\r\n" + 2 - line_len; /* sep = copy(line)
*/
14:10:41 ~~~~~~~^~~
14:10:41 ldif-filter.c:209:16: note: use array indexing to silence this
warning
14:10:41 sep = "\r\n" + 2 - line_len; /* sep = copy(line)
*/
14:10:41 ^
14:10:41 & [ ]
While the expression is valid pointer arithmetic, it does not make sense to me,
because it calculates some (possibly negative) offset to the literal string
"\r\n" in memory, not the address of the beginning of some line, as the comment
`sep = copy(line)` suggests. (Originally added in commit [2]).
[1]
https://git.openldap.org/openldap/openldap/-/blob/master/tests/progs/ldif...
[2] https://git.openldap.org/openldap/openldap/-/commit/725743abdb
--
You are receiving this mail because:
You are on the CC list for the issue.
7 months, 3 weeks
[Issue 9734] New: database ldap does not use SSL client certs as configured
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9734
Issue ID: 9734
Summary: database ldap does not use SSL client certs as
configured
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: daniel(a)ylitalo.io
Target Milestone: ---
Created attachment 849
--> https://bugs.openldap.org/attachment.cgi?id=849&action=edit
Generated config
I'm trying to setup openldap to proxy against our account on ldap.google.com
with backend ldap but it does not seem like slapd uses the client cert and key
eventhough it's configured.
I'm receiving response "result: 50 Insufficient access" from local proxy/google
and the only way you can get that response is by not providing the client cert
and key.
I'm attaching the config used and the slapd.conf used to generate this config,
as you can see the olcDbStartTLS options are there in the ldif file but seems
not to be used.
(I've replaced our suffix with example.com)
The debug log entry is;
Nov 02 10:26:20 dev.example.com slapd[864482]:conn=1012 op=1 SRCH
base="dc=example,dc=com" scope=2 deref=0 filter="(uid=daniel.ylitalo)"
Nov 02 10:26:20 dev.example.com slapd[864482]: ==> limits_get: conn=1012 op=1
self="[anonymous]" this="dc=example,dc=com"
Nov 02 10:26:20 dev.example.com slapd[864482]: =>ldap_back_getconn: conn
0x7fb6101044b0 fetched refcnt=1.
Nov 02 10:26:20 dev.example.com slapd[864482]: => ldap_back_munge_filter
"(uid=daniel.ylitalo)"
Nov 02 10:26:20 dev.example.com slapd[864482]: <= ldap_back_munge_filter
"(uid=daniel.ylitalo)" (0)
Nov 02 10:26:20 dev.example.com slapd[864482]: conn=1012 op=1 ldap_back_retry:
retrying URI="ldaps://ldap.google.com:636" DN=""
Nov 02 10:26:20 dev.example.com slapd[864482]: => ldap_back_munge_filter
"(uid=daniel.ylitalo)"
Nov 02 10:26:20 dev.example.com slapd[864482]: <= ldap_back_munge_filter
"(uid=daniel.ylitalo)" (0)
Nov 02 10:26:20 dev.example.com slapd[864482]: send_ldap_result: conn=1012 op=1
p=3
Nov 02 10:26:20 dev.example.com slapd[864482]: send_ldap_result: err=50
matched="" text=""
Nov 02 10:26:20 dev.example.com slapd[864482]: send_ldap_response: msgid=2
tag=101 err=50
Nov 02 10:26:20 dev.example.com slapd[864482]: conn=1012 op=1 SEARCH RESULT
tag=101 err=50 nentries=0 text=
While using ldapsearch against same endpoint works just fine with the certs;
LDAPTLS_CERT=/etc/ldap/google.crt LDAPTLS_KEY=/etc/ldap/google.key ldapsearch
-H ldaps://ldap.google.com -b dc=example,dc=com '(uid=daniel.ylitalo)'
--
You are receiving this mail because:
You are on the CC list for the issue.
8 months