- openldap-bugs - openldap.org

[Issue 10423] New: It is possible via cn=config to add an entry of one database type with the object class of another, causing OpenLDAP to crash
by openldap-its＠openldap.org 30 Jun '26

30 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10423 Issue ID: 10423 Summary: It is possible via cn=config to add an entry of one database type with the object class of another, causing OpenLDAP to crash Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- This happens specifically because the user by mistake attempts to create a meta database by specifying the object class for back-ldap. Since these share a lot of common attributes, schema checks do not fail. As a result, slapd initializes a meta database (based on olcDatabase value), but attempts to manipulate an initialized back-ldap database after that, and segfaults. Like this: dn: olcDatabase=meta,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: meta olcDbURI: "ldap://example.com" While it seems this is only possible for the proxy databases, we cannot rely that schema checks on attributes will fail for other database combinations, who knows what common attributes can be added or supplied in the future, we we have to fix this. The issue is reproducible via slapadd and at runtime with ldapadd. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10527] Pre-Auth NULL Pointer Dereference in slapd via ExtensibleMatchFilter (mra.c:38) — git master 2026-06-26
by openldap-its＠openldap.org 30 Jun '26

30 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10527 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10527] Pre-Auth NULL Pointer Dereference in slapd via ExtensibleMatchFilter (mra.c:38) — git master 2026-06-26
by openldap-its＠openldap.org 27 Jun '26

27 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10527 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Group|OpenLDAP-devs | Keywords|needs_review | --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- It's ludicrous to report bugs in unreleased code as "vulnerabilities". -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10274] New: Replication issue on MMR configuration
by openldap-its＠openldap.org 24 Jun '26

24 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10274 Issue ID: 10274 Summary: Replication issue on MMR configuration Product: OpenLDAP Version: 2.5.14 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: falgon.comp(a)gmail.com Target Milestone: --- Created attachment 1036 --> https://bugs.openldap.org/attachment.cgi?id=1036&action=edit In this attachment you will find 2 openldap configurations for 2 instances + slamd conf exemple + 5 screenshots to show the issue and one text file to explain what you see Hello we are openning this issue further to the initial post in technical : https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… Issue : We are working on a project and we've come across an issue with the replication after performance testing : *Configuration :* RHEL 8.6 OpenLDAP 2.5.14 *MMR-delta *configuration on multiple servers attached 300,000 users configured and used for tests *olcLastBind: TRUE* Use of SLAMD (performance shooting) *Problem description:* We are currently running performance and resilience tests on our infrastructure using the SLAMD tool configured to perform BINDs and MODs on a defined range of accounts. We use a load balancer (VIP) to poll all of our servers equally. (but it is possible to do performance tests directly on each of the directories) With our current infrastructure we're able to perform approximately 300 MOD/BIND/s. Beyond that, we start to generate delays and can randomly come across one issue. However, when we run performance tests that exceed our write capacity, our replication between servers can randomly create an incident with directories being unable to catch up with their replication delay. The directories update their contextCSNs, but extremely slowly (like freezing). From then on, it's impossible for the directories to catch again. (even with no incoming traffic) A restart of the instance is required to perform a full refresh and solve the incident. We have enabled synchronization logs and have no error or refresh logs to indicate a problem ( we can provide you with logs if necessary). We suspect a write collision or a replication conflict but this is never write in our sync logs. We've run a lot of tests. For example, when we run a performance test on a single live server, we don't reproduce the problem. Anothers examples: if we define different accounts ranges for each server with SALMD, we don't reproduce the problem either. If we use only one account for the range, we don't reproduce the problem either. ______________________________________________________________________ I have add some screenshots on attachement to show you the issue and all the explanations. ______________________________________________________________________ *Symptoms :* One or more directories can no longer be replicated normally after performance testing ends. No apparent error logs. Need a restart of instances to solve the problem. *How to reproduce the problem:* Have at least two servers in MMR mode Set LastBind to TRUE Perform a SLAMD shot from a LoadBalancer in bandwidth mode OR start multiple SLAMD test on same time for each server with the same account range. Exceed the maximum write capacity of the servers. *SLAMD configuration :* authrate.sh --hostname ${HOSTNAME} --port ${PORTSSL} \ --useSSL --trustStorePath ${CACERTJKS} \ --trustStorePassword ${CACERTJKSPW} --bindDN "${BINDDN}" \ --bindPassword ${BINDPW} --baseDN "${BASEDN}" \ --filter "(uid=[${RANGE}])" --credentials ${USERPW} \ --warmUpIntervals ${WARMUP} \ --numThreads ${NTHREADS} ${ARGS} -- You are receiving this mail because: You are on the CC list for the issue.

1 23

[Issue 10486] New: Look into ranked subtree support for LMDB 1.0
by openldap-its＠openldap.org 24 Jun '26

24 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10486 Issue ID: 10486 Summary: Look into ranked subtree support for LMDB 1.0 Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- See https://github.com/datalevin/dlmdb for example -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10236] New: fragmentation makes mdb_page_alloc slow
by openldap-its＠openldap.org 24 Jun '26

24 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10236 Issue ID: 10236 Summary: fragmentation makes mdb_page_alloc slow Product: LMDB Version: 0.9.31 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: aalekseyev(a)janestreet.com Target Milestone: --- Created attachment 1022 --> https://bugs.openldap.org/attachment.cgi?id=1022&action=edit patch is relative to LMDB_0.9.31 It's a known problem that mdb_page_alloc can be slow when the free list is large and fragmented. [1] [2] [3] I'm not sure it's known *how* slow it can be. In our workload we saw a fragmented freelist leading to a pathological O(n^2) behavior. To handle a multi-page allocation we iterate loading chunks of the free list one by one, and at every iteration we do O(n) work to check if the allocation can succeed. Even small-ish allocations (tens of pages) are repeatedly hitting this edge case, with free list growing to ~1000000, and the outer loop taking ~2000 iterations (10^9 worth of work in total, just to allocate a few pages). Even though I'm sure there are ways to avoid hitting this pathological scenario so much (avoid values larger than 4k, or fix whatever causes fragmentation), it seems unacceptable to have a performance cliff this bad. I made a patch to make the allocation take ~O(n*log(n)), by loading and merging multiple chunks at once instead of doing it one-by-one. I'd appreciate it if someone could review the patch (attached), improve it, and/or come up with an alternative fix. The code in `midl.c` is kinda meme-y, including a contribution from GPT-4o, but it performs well enough to speed up our pathological workload by ~20x (which is still ~3x away from the non-fragmented case). Anyway, the main thing that warrants scrutiny is the change in `mdb.c`: I understand very little about lmdb internals and I worry that loading multiple pages at once instead of one-by-one might break something. [1] issue #8664 [2] https://lists.openldap.org/hyperkitty/list/openldap-bugs@openldap.org/threa… [3] https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 10383] New: slapd-meta ignores olcDbIDAssertBind if olcDbURI defined after it
by openldap-its＠openldap.org 23 Jun '26

23 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10383 Issue ID: 10383 Summary: slapd-meta ignores olcDbIDAssertBind if olcDbURI defined after it Product: OpenLDAP Version: 2.6.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: david.frickert(a)protonmail.com Target Milestone: --- Hi, We are using slapd-meta to connect an OpenLDAP server to another external LDAP server and it works well on first configuration. However, if we want to update any info, e.g. the external LDAP URI, we must replace the olcDbURI attribute. This means that the ordering of the attributes change and this attribute is now defined after olcDbIDAssertBind. Didn't think this would be important, but after this change the "meta" connection stops working and upon enabling debugging i can see that the external LDAP server is responding with: "ldap_bind: Inappropriate authentication (48) additional info: Anonymous Simple Bind Disabled" This seems to imply that the olcDbIDAssertBind attribute is being ignored, likely due to being defined before olcDbURI (my assumption). Is this intended? If so, what can we do to mitigate this problem? Do we need to perform a replace on all attributes of the object to ensure correct ordering, or is there any way to perform an in-place attribute modification without making it shift its position in the object? Example: First configuration (OK): # {0}uri, {2}meta, config dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config objectClass: olcMetaTargetConfig olcMetaSub: {0}uri --> olcDbURI: ldap://REDACTED/ou=users,REDACTED olcDbIDAssertBind: bindmethod=simple starttls=yes tls_reqcert=demand binddn="REDACTED" credentials="REDACTED" olcDbRewrite: {0}suffixmassage REDACTED REDACTED olcDbKeepalive: 0:0:0 olcDbBindTimeout: 100000 olcDbCancel: abandon After URI update (NOK): # {0}uri, {2}meta, config dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config objectClass: olcMetaTargetConfig olcMetaSub: {0}uri olcDbIDAssertBind: bindmethod=simple starttls=yes tls_reqcert=demand binddn="REDACTED" credentials="REDACTED" olcDbRewrite: {0}suffixmassage REDACTED REDACTED olcDbKeepalive: 0:0:0 olcDbBindTimeout: 100000 olcDbCancel: abandon --> olcDbURI: ldap://REDACTED/ou=users,REDACTED The olcDbURI attribute is shifted to the bottom after a modify operation, and seems to cause these issues. Best Regards, David -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 6710] Mods already refreshed on a forwarding server is lost by its consumer
by openldap-its＠openldap.org 15 Jun '26

15 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=6710 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=10026 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10424] New: When using more than one syncrepl directive on a single DB, the contextCSN should be stored accordingly to the replication base
by openldap-its＠openldap.org 09 Jun '26

09 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10424 Issue ID: 10424 Summary: When using more than one syncrepl directive on a single DB, the contextCSN should be stored accordingly to the replication base Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: elecharny(a)apache.org Target Milestone: --- Trying to replicate cn=config but parially, I tried to set many syncrepl directives so that each oe of them just replicate the single element it is configured for. Here is an exemple thet replicate the frontend database and only it: {0}rid=004 provider=ldaps://openldap1:10636 bindmethod=simple binddn="cn=syncrepl,ou=accounts,dc=worteks,dc=com" credentials=blah tls_cacert=/opt/application/openldap/ssl/ca.crt tls_cert=/opt/application/openldap/ssl/openldap-common.crt tls_key=/opt/application/openldap/ssl/openldap-common.key tls_reqcert=demand tls_protocol_min=3.3 searchbase="olcDatabase={-1}frontend,cn=config" scope="base" type=refreshAndPersist retry="30 +" timeout=1 schemachecking=off If I have this single syncrepl directive, all is ok, it replicates the frontend data and only this entry. Would I like to replicate, says, 'cn=config' with another syncrepl directive like: olcSyncrepl: {0}rid=001 provider=ldaps://openldap1:10636 bindmethod=simple binddn="cn=syncrepl,ou=accounts,dc=worteks,dc=com" credentials=blah tls_cacert=/opt/application/openldap/ssl/ca.crt tls_cert=/opt/application/openldap/ssl/openldap-common.crt tls_key=/opt/application/openldap/ssl/openldap-common.key tls_reqcert=demand tls_protocol_min=3.3 searchbase="cn=config" scope="base" type=refreshAndPersist retry="30 +" timeout=1 schemachecking=off where the search base is different, then suddenly I get some 'CSN too old' errors, which make totally sense as we only have one single contextCSN stored in the root entry (cn=config in my use case). I know I'm really border line here (and the rational is that I want a partial replication of cn=config because the two servers are a bit different), but I would suggest that the contextCSN to be stored in the entry associated to the searchBase, not at the root of the database. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 10476] slapo-pcache crashes on cached bind attributes containing LDAP filter metachars
by openldap-its＠openldap.org 09 Jun '26

09 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10476 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|UNCONFIRMED |RESOLVED --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: commit 0347718de33ee4e3d0c3570166052c362da6080e Author: Ondřej Kuzník <ondra(a)mistotebe.net> Date: Tue Apr 7 16:23:23 2026 +0100 ITS#10476 Escape asserted value before pasting into filter RE26: commit 2028cb473609bcdd5cfe71a888586c03d0eb93db Author: Ondřej Kuzník <ondra(a)mistotebe.net> Date: Tue Apr 7 16:23:23 2026 +0100 ITS#10476 Escape asserted value before pasting into filter -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=8901 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|IN_PROGRESS |RESOLVED --- Comment #11 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • 23c07757 by Howard Chu at 2026-06-04T18:02:30+00:00 ITS#8901 ldap_pvt_thread: add _detach() support • 5be6295e by Howard Chu at 2026-06-04T18:02:30+00:00 ITS#8901 tpool: use joinable threads instead of detached RE27: • 2fa6d246 by Howard Chu at 2026-06-08T19:44:05+00:00 ITS#8901 ldap_pvt_thread: add _detach() support • fb41f6a1 by Howard Chu at 2026-06-08T19:44:10+00:00 ITS#8901 tpool: use joinable threads instead of detached -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=8901 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |hyc(a)openldap.org -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=8901 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |2.7.0 Keywords|needs_review | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6198] Authorization for extensions
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=6198 --- Comment #10 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • e922f9f1 by Ondřej Kuzník at 2026-06-08T01:31:08+00:00 ITS#6198 doc: Extend admin guide ACL section to cover new options RE27: • 0e10c595 by Ondřej Kuzník at 2026-06-08T18:07:59+00:00 ITS#6198 doc: Extend admin guide ACL section to cover new options -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9009] 2.7: Switch to LMDB v1.0
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=9009 --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- mdb.RE/1.0: • ce139ac9 by Howard Chu at 2026-06-04T21:42:15+01:00 ITS#9009 LMDB add release notes/upgrading info mdb.master3: • b7c68db2 by Howard Chu at 2026-06-04T21:41:32+01:00 ITS#9009 LMDB add release notes/upgrading info -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=8901 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |needs_review -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10353] New: No TLS connection on Windows because of missing ENOTCONN in socket.h
by openldap-its＠openldap.org 03 Jun '26

03 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10353 Issue ID: 10353 Summary: No TLS connection on Windows because of missing ENOTCONN in socket.h Product: OpenLDAP Version: 2.6.10 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: julien.wadel(a)belledonne-communications.com Target Milestone: --- On Windows, the TLS connection cannot be done and we get the connection error: Can't contact LDAP server. => Connections are done with WSAGetLastError(). After getting WSAEWOULDBLOCK, the connection is not restart because of the state WSAENOTCONN that is not known. OpenLDAP use ENOTCONN that is set to 126 by "ucrt/errno.h" while WSAENOTCONN is 10057L. Adding #define ENOTCONN WSAENOTCONN like for EWOULDBLOCK resolve the issue. Reference commit on external project: https://gitlab.linphone.org/BC/public/external/openldap/-/commit/62fbfb12e8… -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10513] New: slapd segfault during shutdown when syncrepl is in retry mode
by openldap-its＠openldap.org 02 Jun '26

02 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10513 Issue ID: 10513 Summary: slapd segfault during shutdown when syncrepl is in retry mode Product: OpenLDAP Version: 2.6.10 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: Marcelo.DeCastroLoebens(a)windriver.com Target Milestone: --- ## Problem slapd crashes with a segfault during shutdown. The crash occurs when the syncrepl provider is unreachable (syncrepl in retry mode). The issue has been observed twice under the same conditions. ## How to Reproduce 1. Configure slapd with syncrepl+TLS pointing to an unreachable host 2. Start slapd (syncrepl enters retry loop) 3. Send SIGTERM to slapd The crash is a race condition and does not occur often, but is reproducible with repeated attempts. ## Environment - OpenLDAP: 2.6.10 - OS: Debian 13 (Trixie), Linux 6.12, amd64 - OpenSSL: 3.5.1 - glibc: 2.41 ## Configuration slapd with back-mdb, syncrepl configured in refreshAndPersist mode with TLS, pointing to a provider that is unreachable (syncrepl in retry loop). mirrormode enabled, syncprov overlay loaded. Relevant slapd.conf excerpt: database mdb directory /var/lib/ldap syncrepl rid=000 provider=ldaps://peer-host tls_reqsan=demand type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=local" bindmethod=simple binddn="cn=admin,dc=example,dc=local" credentials=secret mirrormode TRUE overlay syncprov ## Stack Traces Two threads crash simultaneously: Two threads crash simultaneously: Thread 1 (main thread, PID 6946): #0 0x00007fe467381d91 (libcrypto.so.3 + 0x137d91) #1 0x00007fe467382303 (libcrypto.so.3 + 0x138303) #2 0x00007fe467382133 (libcrypto.so.3 + 0x138133) #3 0x00007fe4673822a5 (libcrypto.so.3 + 0x1382a5) #4 0x00007fe467382133 (libcrypto.so.3 + 0x138133) #5 0x00007fe467382303 (libcrypto.so.3 + 0x138303) #6 0x00007fe467382133 (libcrypto.so.3 + 0x138133) #7 0x00007fe467382209 ASN1_item_free (libcrypto.so.3 + 0x138209) #8 0x00007fe467634ce9 X509_OBJECT_free (libcrypto.so.3 + 0x3eace9) #9 0x00007fe467601970 OPENSSL_sk_pop_free (libcrypto.so.3 + 0x3b7970) #10 0x00007fe46763528d X509_STORE_free (libcrypto.so.3 + 0x3eb28d) #11 0x00007fe4678c914e SSL_CTX_free (libssl.so.3 + 0x4614e) #12 0x0000563ee1c599b1 bindconf_free (/usr/sbin/slapd + 0x3d9b1) #13 0x0000563ee1ccf0e2 syncinfo_free (/usr/sbin/slapd + 0xb30e2) #14 0x0000563ee1c70d1c backend_destroy_one (/usr/sbin/slapd + 0x54d1c) #15 0x0000563ee1c70e6a backend_destroy (/usr/sbin/slapd + 0x54e6a) #16 0x0000563ee1c931c1 slap_destroy (/usr/sbin/slapd + 0x771c1) #17 0x0000563ee1c444c3 main (/usr/sbin/slapd + 0x284c3) #18 0x00007fe4679bbca8 (libc.so.6 + 0x29ca8) #19 0x00007fe4679bbd65 __libc_start_main (libc.so.6 + 0x29d65) #20 0x0000563ee1c45431 _start (/usr/sbin/slapd + 0x29431) Thread 2 (worker, TID 6948): #0 0x00007fe466dc9ae9 (back_mdb.so.2 + 0x29ae9) #1 0x00007fe467a22271 (libc.so.6 + 0x90271) #2 0x00007fe467a24a4e (libc.so.6 + 0x92a4e) #3 0x00007fe467aa27b8 (libc.so.6 + 0x1107b8) Kernel log: slapd[6948]: segfault at 7fe467c900c8 ip 00007fe466dc9ae9 sp 00007fe425bf4e80 error 7 in back_mdb.so.2.0.200 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 01 Jun '26

01 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=8901 --- Comment #10 from Howard Chu <hyc(a)openldap.org> --- (In reply to Marcelo.DeCastroLoebens from comment #9) > (In reply to Howard Chu from comment #8) > > Fix in https://git.openldap.org/openldap/openldap/-/merge_requests/888 > > please test. > > Thanks for the fix and the speedy replies. > > I will start testing the integration of this patch with our system. Will > need some time (can't say for sure how much) since the occurrence is low, I > will leave a test env cycling the shutdown over a bunch of times, then > report here the results. For reference, the direct way to verify this fix is to check for proper thread pool cleanup after throwing a bit of load at the server. I did this using test008 in the test suite. tests% ./run -k test008 The -k flag tells it not to kill slapd after the test finishes. Then attach to the server with gdb and set a breakpoint on the last line of the ldap_pvt_thread_pool_close() function. (tpool.c:907 with this patch). Then send slapd a signal to tell it to shutdown. When it hits the breakpoint, there should be no more threadpool worker threads left. I've tested on Linux and Windows and verified proper cleanup here. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 01 Jun '26

01 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=8901 --- Comment #9 from Marcelo.DeCastroLoebens(a)windriver.com --- (In reply to Howard Chu from comment #8) > Fix in https://git.openldap.org/openldap/openldap/-/merge_requests/888 > please test. Thanks for the fix and the speedy replies. I will start testing the integration of this patch with our system. Will need some time (can't say for sure how much) since the occurrence is low, I will leave a test env cycling the shutdown over a bunch of times, then report here the results. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 30 May '26

30 May '26

https://bugs.openldap.org/show_bug.cgi?id=8901 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS --- Comment #8 from Howard Chu <hyc(a)openldap.org> --- Fix in https://git.openldap.org/openldap/openldap/-/merge_requests/888 please test. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 29 May '26

29 May '26

https://bugs.openldap.org/show_bug.cgi?id=8901 --- Comment #7 from Howard Chu <hyc(a)openldap.org> --- (In reply to Marcelo.DeCastroLoebens from comment #6) > Thanks for the analysis and workaround provided. > > Do you have an opinion about the risk associated with the workaround? Since > I'm not familiar with the code, that would be very helpful. > > I don't have the expertise to comprehensive test slapd in isolation, so I > would like to know if you imagine possible side effects during "regular" > usage (not shutdown). There's no impact during regular use since ldap_pvt_thread_pool_close() is only called during shutdown. Actually, just to be more explicit - the sleep(1) should be inserted in slapd/daemon.c:slapd_daemon_task() right after its call to ldap_pvt_thread_pool_close(). There's no need to muck with libldap itself. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 29 May '26

29 May '26

https://bugs.openldap.org/show_bug.cgi?id=8901 --- Comment #6 from Marcelo.DeCastroLoebens(a)windriver.com --- Thanks for the analysis and workaround provided. Do you have an opinion about the risk associated with the workaround? Since I'm not familiar with the code, that would be very helpful. I don't have the expertise to comprehensive test slapd in isolation, so I would like to know if you imagine possible side effects during "regular" usage (not shutdown). -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 29 May '26

29 May '26

https://bugs.openldap.org/show_bug.cgi?id=8901 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |CONFIRMED Resolution|FEEDBACK |--- --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- The problem is because ldap_pvt_thread_pool_close() doesn't actually know when the last thread has exited. The last thread does a cond_signal() to tell that it is exiting, but there's additional time between that and when the thread actually returns (or calls pthread_exit). And LMDB's own reader_dest function doesn't execute until the actual pthread_exit occurs. So when ldap_pvt_thread_pool_close() returns, worker threads may still be running. Then when backend_shutdown is called, which invokes back-mdb's shutdown and eventual mdb_env_close(), it may get there before the worker threads have completed, and so destroy the environment while worker threads are still trying to clear their reader slots. A proper fix would require some rewriting of the thread_pool code to track thread creation and termination explicitly. A workaround for now would be to insert a sleep(1) at the end of ldap_pvt_thread_pool_close(). -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 29 May '26

29 May '26

https://bugs.openldap.org/show_bug.cgi?id=8901 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Marcelo.DeCastroLoebens@win | |driver.com --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- *** Issue 10513 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs