https://bugs.openldap.org/show_bug.cgi?id=9887
Issue ID: 9887
Summary: Offer to mirror OpenLDAP
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: mirrors(a)jevincanders.net
Target Milestone: ---
Greetings,
We're from Jevin Canders, a hosting company based in New York (servers are in
Buffalo).
We're wondering if you wanted/needed another US mirror. We're already mirroring
other open source projects, including Kali Linux and F-Droid. As of next week
(tentatively), our mirror server will have a 20 Gbps pipe to work with, so
we'll be able to handle new projects.
Let us know if you have any questions, concerns, or requests.
Sincerely,
Josh Anders and Kevin Croissant
JC Mirrors Team
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9912
Issue ID: 9912
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: ---
Providing following command-line input results in invalid free.
./servers/slapd/slapd -h1 -h1
This issue exists in openldap-2.6.3 and the master branch of git.
Environment:
- Ubuntu 20.04
- clang-14.0.6 with CFLAGS="-fsanitize=address"
Backtrace:
=================================================================
==3323395==ERROR: AddressSanitizer: attempting free on address which was not
malloc()-ed: 0x7ffc8512c238 in thread T0
#0 0x4d0077
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x4d0077)
#1 0xb77152
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0xb77152)
#2 0x65ff02
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x65ff02)
#3 0x5168a9
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x5168a9)
#4 0x7ff21bd3c082 (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#5 0x42130d
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x42130d)
Address 0x7ffc8512c238 is located in stack of thread T0 at offset 10072 in
frame
#0 0x515fef
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x515fef)
This frame has 10 object(s):
[32, 36) 'rc' (line 220)
[48, 52) 'syslogUser' (line 230)
[64, 72) 'waitfds' (line 234)
[96, 100) 'level' (line 402)
[112, 128) 'opt' (line 432)
[144, 148) 'opt393' (line 717)
[160, 168) 'errmsg' (line 726)
[192, 196) 'buf' (line 778)
[208, 336) 'ebuf' (line 798)
[368, 496) 'ebuf524' (line 821) <== Memory access at offset 10072 overflows
this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: bad-free
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x4d0077)
==3323395==ABORTING
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9913
Issue ID: 9913
Summary: Some lloadd shutdown code doesn't protect memory
correctly
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
During shutdown, clients_destroy and tier_destroy are called while worker
threads might still be alive, therefore they need to participate in memory
management.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9907
Issue ID: 9907
Summary: lloadd config/shutdown leaks
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
lloadd leaks some memory in cn=config and at shutdown time. Fixes coming
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9906
Issue ID: 9906
Summary: cn=monitor leaks in lloadd
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
lloadd registers various types of monitor_subsys_t but currently doesn't tear
all parts of them down correctly, leaking memory on server shutdown. Partly
down to how back-monitor shutdown works at the moment.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9898
Issue ID: 9898
Summary: slapd-addel.c contains invalid struct initialization
which does not compile on HP-UX aCC
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: Other
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: michael.osipov(a)siemens.com
Target Milestone: ---
My compiler (cc: HP C/aC++ B3910B A.06.29 [Oct 18 2016]) gives me:
/opt/aCC/bin/aCC -Ae -g -I../../include -I../../include -I/opt/ports/include
-I/opt/ports/include -c -o slapd-addel.o slapd-addel.c
"slapd-addel.c", line 68: error #2029: expected an expression
LDIFRecord record = {};
^
"slapd-addel.c", line 70: error #2029: expected an expression
struct berval bv = {};
^
This is invalid C code, it can be easily solved by using "{0}" and the code
does compile.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9892
Issue ID: 9892
Summary: LDAP_TXN_SPECIFY assumes cleanup responsibility for
writes but never performs it
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: ---
When TXN extop is accepted and the client sends some write ops, the cleanup
path is skipped within do_modify/do_add/... however the data is never actually
freed when the transaction is being settled (regardless of whether it was
committed successfully or aborted).
Confirmed to happen with do_modify by tests/scripts/lloadd/test007-coherence,
for others it's my assumption based on reading the code.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9880
Issue ID: 9880
Summary: reqStart filter with trailing zeros is truncated,
which breaks certain searches
Product: OpenLDAP
Version: 2.5.12
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: subbarao(a)computer.org
Target Milestone: ---
Note: ITS#9358 seems to address this very issue, but it doesn't seem to help
this particular case.
Certain range searches with reqStart on the changelog don't work as expected.
For example:
(!(reqStart<=20220707123456.000000Z))
The idea here is to grab all entries strictly greater than the timestamp. But
slapd truncates zeros in this filter, rewriting it to:
(!(reqStart<=20220707123456Z))
As a result, the reqStart=20220707123456.000000Z entry is the first match since
it is greater than 20220707123456Z, which is not the desired behavior.
I was able to reproduce this issue on 2.5.12 as follows:
1) Start the test043-delta-syncrepl test, let it run almost to the end so that
it makes many changes, and then hit ^Z to suspend the script. I waited until
one of the last occurrences of "Waiting 7 seconds for syncrepl to receive
changes".
2) pkill -CONT -f slapd to restart slapd (but not the test script)
3) ldapsearch -x -h localhost:9011 -b cn=log objectclass=top | grep
'^dn:.*.000000Z'
Look for a change with all trailing zeros. It's not as rare as one might think,
I saw at least one trailing-zeros change in two consecutive runs of the test
script. I suppose you could also just create an entry with all trailing zeros
in the accesslog :-)
4) Run a range search to only return changes after that change (I used -z 1 and
-s one so that it would only give me one result):
ldapsearch -x -z 1 -h localhost:9011 -b cn=log -s one
'(!(reqStart<=20220708012121.000000Z))'
If you see the same entry, then the problem is present.
5) Even if you can't have an accesslog entry with all trailing zeros, you can
still do the above search verbatim and look at the slapd log file
testrun/slapd.1.log:
62c7873f.145b4396 0x7fabf14c9700 conn=1011 op=1 SRCH base="cn=log" scope=1
deref
=0 filter="(!(reqStart<=20220708012121Z))"
The filter being rewritten in the server log seems to indicate that trailing
zeros are being truncated somewhere.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9924
Issue ID: 9924
Summary: Increased/RunAway memory usage slapo-deref
Product: OpenLDAP
Version: 2.5.13
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: erikdewaard(a)gmail.com
Target Milestone: ---
Created attachment 916
--> https://bugs.openldap.org/attachment.cgi?id=916&action=edit
slapd.conf
Increased/RunAway memory usage slapo-deref
Running: 2.5.13
After enabling slapo-deref slapd memory usage increased and growing.
I can reproduce this on every consumer with deref enabled.
From:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
173229 ldap 20 0 26.6g 1.0g 941996 S 4.0 0.8 3674:19 slapd
To:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2745810 ldap 20 0 141.5g 115.8g 468940 S 3.0 92.5 312:42.93 slapd
How best to debug this?
I should probably recompile to get all symbols for slapd available.
#valgrind.sh
valgrind --leak-check=full \
--show-leak-kinds=all \
--extra-debuginfo-path=/usr/lib/debug/usr/lib64/openldap \
--allow-mismatched-debuginfo=yes \
--track-origins=yes \
--error-limit=no \
--verbose \
--log-file=valgrind-out.txt \
/usr/sbin/slapd -F /etc/openldap/slapd.d -u ldap -h "ldap:///
ldaps:/// ldapi:///"
#mleak.sh
LD_PRELOAD=/tmp/mleak/mleak.so \
/usr/sbin/slapd -F /etc/openldap/slapd.d -u ldap -h "ldap:/// ldaps:///
ldapi:///"
sent kill -2
#mleak_report.sh
./mdump /usr/sbin/slapd ml.*
./report.sh | more
fncdump: Cant open linux-vdso.so.1
Memory leaks (14480 total):
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9915
Issue ID: 9915
Summary: Changing slapo-unique to use serialize causes
cn=config replication to fail
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: quanah(a)openldap.org
Target Milestone: ---
I updated my slapo-unique configuration from:
olcUniqueURI: ldap:///?uid?sub?
to
olcUniqueURI: "serialize ldap:///?uid?sub?"
and replication of the config database fails with the following error:
syncrepl_null_callback: error code 0x50
syncrepl_entry: rid=001 be_modify
olcOverlay={2}unique,olcDatabase={2}mdb,cn=config (80)
syncrepl_entry: rid=001 be_modify failed (80)
--
You are receiving this mail because:
You are on the CC list for the issue.