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/01b1b7dc204abdf3849536979205dc9e3a0e3ece/…
[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.
https://bugs.openldap.org/show_bug.cgi?id=9967
Issue ID: 9967
Summary: Please register my company on the support page, again
(www.openldap.org)
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: sjsong(a)aboutdap.kr
Target Milestone: ---
Howard Chu <hyc(a)openldap.org>
송상준 <sjsong(a)aboutdap.kr>
Hi,
you can submit a ticket against "website" in the ITS for this. Thanks.
송상준 wrote:
>
> Hello. openldap page administrater.
> My name is sang jun song.
>
> I want to register my company on the support page.
> I registered before, but it seems to have disappeared.
> Our company has been attending ldapcon since 2015.
>
> The sysmas employees who attended the LDAPCON in 2019 may remember me.
>
> Please register my company on the support page. Please contact me if you need additional information..
>
> thank you.
>
> Song.
>
> Registration phrase
>
> Seojindsa Co., Ltd. (Aboutdap Co., Ltd.)- Korea
>
> Provides consultancy, development, training and user support for OpenLDAP software in Korea.
>
> URL : seojindsa : www.seojindsa.kr
>
> ------------------------------------------------------
> (주) 어바웃답 기술영업팀 송상준 부장
> TEL. 010-9780-6746
> email: sjsong(a)aboutdap.kr
> homepage: www.aboutdap.kr
> -------------------------------------------------------
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
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=9513
Issue ID: 9513
Summary: Enhanced debug output
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: enhancement
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
While debugging ITS#9479 I needed more information on which threads were doing
what actions. Also, when looking for delays/hangs/race conditions, the 1-second
granularity of the debug msg timestamp was inadequate. And also, some of the
debug output for the Search operation was being done in separate Debug calls
for a single line of output. This gets jumbled up pretty badly if other threads
are printing output as well.
New patch set will extend the debug timestamp to have fractional seconds too;
it will use clock_gettime for nanosecond resolution if available, otherwise use
gettimeofday for microsecond resolution. Also tweak the Search debug output to
only use one Debug invocation per line of output.
This is MR!279.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10132
Issue ID: 10132
Summary: manage syncrepl as a cn=config entry
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Maybe it being exposed through both places (olcSyncrepl and the entry) could be
a way to manage the transition (unless we have a way to handle cn=config schema
upgrades internally). Uncertain as to how that affects cn=config replication.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9884
Issue ID: 9884
Summary: Document "set" patterns in ACLs
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The slapd.access(5) man page has this exceptionally unhelpful line where sets
are concerned:
"The statement set=<pattern> is undocumented yet."
Even if it is an experimental feature, it should still be documented on how it
is meant to operate.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9936
Issue ID: 9936
Summary: slapd attempting free on address which was not
malloced
Product: OpenLDAP
Version: 2.6.3
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: kimjuhi96(a)snu.ac.kr
Target Milestone: ---
I get invalid free running this on the latest openldap from git, built with
CFLAGS="-fsanitize=address" using clang 15.
Seems this is similar to https://bugs.openldap.org/show_bug.cgi?id=9912.
./servers/slapd/slapd -T c -s1 -s1
Stopped reason: SIGABRT
__GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
gdb-peda$ bt
#0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff78ca859 in __GI_abort () at abort.c:79
#2 0x00005555556eb04f in __sanitizer::Abort ()
at
/home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cpp:143
#3 0x00005555556e8aac in __sanitizer::Die ()
at
/home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:58
#4 0x00005555556c5dda in __asan::ScopedInErrorReport::~ScopedInErrorReport
(this=0x7fffffffbe7e, __in_chrg=<optimized out>)
at
/home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:192
#5 0x00005555556c72b8 in __asan::ReportFreeNotMalloced (addr=<optimized out>,
free_stack=0x7fffffffca90)
at
/home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:199
#6 0x00005555556c02ab in __interceptor_free (ptr=0x7fffffffe359)
at
/home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:53
#7 0x0000555555d3efe2 in ber_memfree_x ()
#8 0x0000555555847d33 in ch_free ()
#9 0x0000555555a31178 in slap_tool_init ()
#10 0x0000555555a2e54d in slapcat ()
#11 0x000055555570901f in main ()
#12 0x00007ffff78cc083 in __libc_start_main (main=0x555555706ef0 <main>,
argc=0x5, argv=0x7fffffffdfc8,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7fffffffdfb8)
at ../csu/libc-start.c:308
#13 0x000055555561011e in _start ()
at
/home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h:397
gdb-peda$
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10100
Issue ID: 10100
Summary: Non-sequential timestamps being logged on Windows
Product: OpenLDAP
Version: 2.6.6
Hardware: x86_64
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: smckinney(a)symas.com
Target Milestone: ---
Presents as a dsync during replication. Consumer will log
```
650af021.2eadd901 0000000000001b40 slap_queue_csn: queueing 0000000002ac1620
20230920131409.992477Z#000000#001#000000
650af021.2eaed239 0000000000001b40 slap_graduate_commit_csn: removing
0000000002ac1620 20230920131409.992477Z#000000#001#000000
650af021.317b2a35 000000000000185c do_syncrep2: rid=102 CSN too old, ignoring
20230920131409.040136Z#000000#001#000000
(uid=slapd-test1-FOO1-6,ou=People,dc=example,dc=com)
```
The entry was not be added.
The provider will log messages using non-sequential timestamps. For example,
when grepping the CSN from above (in provider log):
```
# This:
650af021.3b3060d9 0000000000001ad8 conn=1001 op=1 syncprov_sendresp: to=002,
cookie=rid=102,sid=001,csn=20230920131409.992477Z#000000#001#000000
# and:
650af021.02648749 0000000000001810 slap_get_csn: conn=1003 op=7 generated new
csn=20230920131409.040136Z#000000#001#000000 manage=1
```
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9584
Issue ID: 9584
Summary: cn=config replication ops/refresh should pause server
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Looking into this crash: https://git.openldap.org/openldap/openldap/-/jobs/7286
The thread in question is running a plain syncrepl refresh while another thread
seems to have done the same. This thread fetched the entryUUID attribute of the
'cn=config' entry as 'a' and in the meantime, that entry has been rewritten,
with 'a' presumably cleaned up and returned to the pool, so addressing
a->a_nvals[0] is a NULL-dereference now.
This might or might not be related to the fix in ITS#8102.
--
You are receiving this mail because:
You are on the CC list for the issue.