openldap-bugs September 2022

openldap-bugs@openldap.org

2 participants
114 discussions

[Issue 9906] New: cn=monitor leaks in lloadd
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

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.

1 5

[Issue 9898] New: slapd-addel.c contains invalid struct initialization which does not compile on HP-UX aCC
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

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.

1 11

[Issue 9892] New: LDAP_TXN_SPECIFY assumes cleanup responsibility for writes but never performs it
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

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.

1 6

[Issue 9880] New: reqStart filter with trailing zeros is truncated, which breaks certain searches
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

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.

1 9

[Issue 9924] New: Increased/RunAway memory usage slapo-deref
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

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.

1 16

[Issue 9915] New: Changing slapo-unique to use serialize causes cn=config replication to fail
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

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.

1 8

[Issue 9897] New: ldapcompare return FALSE when dynlist in use
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9897 Issue ID: 9897 Summary: ldapcompare return FALSE when dynlist in use 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: sdalu(a)sdalu.com Target Milestone: --- The server configuration enable dynlist with: overlay dynlist dynlist-attrset groupOfURLs memberURL member Entry is: dn: cn=Admins,ou=Services,ou=Members,dc=zog,dc=com member: uid=foo,ou=People,dc=zog,dc=com cn: Admins objectClass: groupOfNames The ldap compare will return false, was expected true ldapcompare -x cn=Admins,ou=Services,ou=Members,dc=zog,dc=com member:uid=foo,ou=People,dc=zog,dc=com Now if I comment the dynlist-attrset directive, I will get TRUE for the same ldapcompare request -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9904] New: A Potential NPD
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9904 Issue ID: 9904 Summary: A Potential NPD Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 1157401338(a)qq.com Target Milestone: --- Created attachment 911 --> https://bugs.openldap.org/attachment.cgi?id=911&action=edit diagram of NPD Hi, I found a NPD bug in the project source code of ldap, and I have shown the execution sequence of the program that may have generated the bug on a diagram,which is added to the attachment The red text illustrates the steps that created the bug the red arrows represent the call relationships the file path can be seen in the blue framed section. additionally,at step 4 I do not expand more detail about why function ber_memalloc_x can return null(actually it can be seen as function malloc and the reason ber_memalloc_x return null is same with malloc),because there are many code snippet can be found in project source code that judge whether ber_memalloc_x return null and make further process if return value equal to null. I look forward to your reply and thank you very much for your patience! -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9901] New: Fix non-standard printf arguments in liblbert and libldap
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9901 Issue ID: 9901 Summary: Fix non-standard printf arguments in liblbert and libldap Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: michael.osipov(a)siemens.com Target Milestone: --- Created attachment 910 --> https://bugs.openldap.org/attachment.cgi?id=910&action=edit Patch gainst source tarball As a followup to Bug 9898 and Bug 9899 I have played around with LLVM 13 and "-std=c17 -pedantic -Wall" it fails to compile several files. Find a patch attached which makes it standards compliant. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9899] New: "cyrus.c" uses non-portable GNU extension for void pointer arithmetics and fails on HP-UX aCC
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9899 Issue ID: 9899 Summary: "cyrus.c" uses non-portable GNU extension for void pointer arithmetics and fails on HP-UX aCC Product: OpenLDAP Version: 2.6.3 Hardware: All OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: michael.osipov(a)siemens.com Target Milestone: --- On HP-UX with cc: HP C/aC++ B3910B A.06.29 [Oct 18 2016] tells me libtool: compile: /opt/aCC/bin/aCC -Ae -g -I../../include -I../../include -I/opt/ports/include -DLDAP_LIBRARY -c cyrus.c -DPIC -o .libs/cyrus.o "cyrus.c", line 420: error #3143: arithmetic on pointer to void or function type memcpy( cb_data + plen, cbv.bv_val, cbv.bv_len ); ^ 1 error detected in the compilation of "cyrus.c". gmake[2]: *** [Makefile:434: cyrus.lo] Error 1 void pointer arithmetics is not valid/undefined and just a GNU extension supported by GCC or clang. I was able to reproduce this on FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303): osipovmi@deblndw011x:~/var/Projekte/openldap-2.6.3/libraries/libldap $ cc -std=c17 -I../../include -I../../include -I/usr/local/include -DLDAP_LIBRARY -c cyrus.c -o cyrus.o -pedantic -Werror cyrus.c:420:18: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wpointer-arith] memcpy( cb_data + plen, cbv.bv_val, cbv.bv_len ); ~~~~~~~ ^ 1 error generated. I am not a daily C hacker, but I guess cb_data needs to be typed to "unsigned char" just like data from sasl_channel_binding_t (https://github.com/cyrusimap/cyrus-sasl/blob/cb549ef71c5bb646fe583697ebdcab…). Or at least a malloc with an "unsigned char", save the pointer start address, copy the prefix, increment by prefix length, copy the channel binding value and then assign the pointer start address to the output struct. I will unset SASL_CHANNEL_BINDING for now since it is not required in your AD environment when SASL GSSAPI with minssf=1 is set. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

← Newer
1
...
5
6
7
8
9
10
11
12
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2022