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=9596
Issue ID: 9596
Summary: Python test suite
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
The bash test suite is extremely limited, hard to write for and slow. We can't
lose it as it is also portable, but something should be introduced for
developers/CI on more modern systems and increase coverage.
A Python 3 seed for one is in development in MR!347.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9398
Issue ID: 9398
Summary: Stale accesslog cookie due to unclean shutdown
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If slapd terminates uncleanly, a checkpoint will be lost on the accesslog db.
Depending on the syncprov overlay checkpoint settings (usually no checkpointing
is enabled on the accesslog db) this can cause the system to refuse engage in
replication at startup.
--
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=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=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.
https://bugs.openldap.org/show_bug.cgi?id=9881
Issue ID: 9881
Summary: Ability to track last authentication for database
objects
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
For simple binds, we have the ability to track the last success via the
lastbind functionality (pwdLastSuccess attribute). However this doesn't allow
one to see when an object that exists in a database last authenticated via
SASL.
It would be useful to add similar functionality for SASL binds.
This can be useful information that allows one to tell if an object is being
actively authenticated to (generally, users and system accounts, etc).
Obviously if something is directly mapped to an identity that doesn't exist in
the underlying DB, that cannot be tracked.
--
You are receiving this mail because:
You are on the CC list for the issue.