openldap-bugs

openldap-bugs@openldap.org

1 participants
21425 discussions

[Issue 10529] New: assertion failure
by openldap-its＠openldap.org 29 Jul '26

29 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10529 Issue ID: 10529 Summary: assertion failure Product: LMDB Version: 1.0.0 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: christopher(a)gmerlin.de Target Milestone: --- When testing the OCaml bindings with lmdb 1.0 I encountered this assertion failure: at src/mdb.c:7588: Assertion 'root > 1' failed in mdb_page_search()") It was triggered by: - start transaction - add new key-value - commit transaction - rollback transaction - start read only transaction - try to get any key -> assertion failure On another note I notice that this fails with MDB_CANT_ROLLBACK: - start transaction - commit ¡EMPTY! transaction - rollback transaction -> MDB_CANT_ROLLBACK Of course this is a nonsensical transaction. But nevertheless maybe this case should be mentioned in the documentation, too. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 10553] New: Fix types to allow compilation on windows
by openldap-its＠openldap.org 29 Jul '26

29 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10553 Issue ID: 10553 Summary: Fix types to allow compilation on windows Product: LMDB Version: 1.0.0 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: christopher(a)gmerlin.de Target Milestone: --- Created attachment 1178 --> https://bugs.openldap.org/attachment.cgi?id=1178&action=edit Patch including ac041af3d Compilation on windows fails because of pointer type errors. Commit ac041af3dd044d433e73432839cc323bffa357f3 does not fix all of those compilation failures: * NtMapViewOfSection() expects void * in its 3rd argument. * 7th expects SIZE_T *, but in mdb_env_copyfd0() a DWORD * is passed. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10550] New: back ldap idletimeout broken
by openldap-its＠openldap.org 28 Jul '26

28 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10550 Issue ID: 10550 Summary: back ldap idletimeout broken 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: --- When an operation takes longer than idletimeout/conttl, back-ldap decides to terminate the connection. But if that connection is private, it doesn't do it right and asserts in ldap_back_conn_delete Two issues: - the TAINTED flag should not be set without the real state being set to match - a connection with an outstanding operation shouldn't be considered idle -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10551] New: mdb_put() returns MDB_PAGE_FULL depending on key-length parity and insertion order
by openldap-its＠openldap.org 28 Jul '26

28 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10551 Issue ID: 10551 Summary: mdb_put() returns MDB_PAGE_FULL depending on key-length parity and insertion order Product: LMDB Version: 1.0.0 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: adam.req(a)gmx.de Target Milestone: --- Created attachment 1175 --> https://bugs.openldap.org/attachment.cgi?id=1175&action=edit insertion order ## Background I am currently getting familiar with LMDB and encountered the following reproducible behavior. ## Tested versions * OpenLDAP LMDB (`master`) * LMDB (`mdb.RE/1.0`) hint: 0.9.x was okay ## Description A new LMDB environment is created, followed by the creation of two DBIs. The attached key/value pairs are inserted using `mdb_put()` as follows (only the first dbi was used here): Key: excl. comma, including the terminating null character (`'\0'`) Value: raw byte sequence (number of bytes exactly as shown in the attachment) Example: GX\c, 100 -> means 4+1(zero)=5 bytes for key, and 100 bytes for value The final call to `mdb_put()` fails with: MDB_PAGE_FULL: Internal error - page has no more space ## Reproduction The failure is reproducible using the attached key/value sequence in "insertion order" file. The error does not occur if either of the following changes is made (just tested): * All keys are forced to have the same byte-length parity by appending an additional `0x00` byte where necessary (all keys become either even- or odd-sized). * The last two insertions are swapped. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10549] New: lloadd rejects proxied connections: proxyp() cannot read PROXY header on non-blocking socket
by openldap-its＠openldap.org 28 Jul '26

28 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10549 Issue ID: 10549 Summary: lloadd rejects proxied connections: proxyp() cannot read PROXY header on non-blocking socket Product: OpenLDAP Version: 2.6.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: tim.wagner(a)freenet.de Target Milestone: --- # Overview When an lloadd listener is configured with the PROXY protocol enabled, a large fraction of incoming connections are dropped before they are accepted as clients. We're using HAProxy 3.4 (asme with 3.3, 3.2) to distribute the connections across 3 lloadd proxies. The log of lloadd fills with: ``` proxyp(<fd>): header read failed 11 (Resource temporarily unavailable) lload_listener: proxyp(<fd>) failed ``` The root cause is that `proxyp()` is written for a *blocking* socket, but the socket lloadd hands it is *non-blocking*. `proxyp()` (`servers/slapd/proxyp.c`) reads the PROXY header with a single synchronous `tcp_read()` that expects the whole header at once, and its retry loop only handles `EINTR`: ```c /* servers/slapd/proxyp.c:73 */ do { ret = tcp_read( SLAP_FD2SOCK( sfd ), (char *)&pph, sizeof(pph) ); } while ( ret == -1 && errno == EINTR ); if ( ret == -1 ) { ... "header read failed %d (%s)" ... /* EAGAIN lands here */ return 0; } ``` In lloadd, the accept callback runs on a non-blocking fd. The listener is created via libevent without `LEV_OPT_LEAVE_SOCKETS_BLOCKING`: ```c /* servers/lloadd/daemon.c:945 */ listener = evconnlistener_new( listener_base, lload_listener, ls, LEV_OPT_THREADSAFE|LEV_OPT_DEFERRED_ACCEPT, SLAPD_LISTEN_BACKLOG, ls->ls_sd ); ``` libevent's `evconnlistener` sets every accepted socket non-blocking unless that flag is set. `lload_listener()` then calls `proxyp( s, from, &dummy )` (`daemon.c:788`) synchronously, without ever making the fd blocking. So whenever the full PROXY header is not already buffered in the kernel at the moment the accept callback fires, `tcp_read()` returns -1/`EAGAIN`, `proxyp()` returns 0, and lloadd closes the connection. slapd is not affected: it `accept()`s the fd itself and calls `proxyp()` while the fd is still blocking (only the *listening* socket is made non-blocking, `servers/slapd/daemon.c:2624`; Linux `accept()` does not inherit `O_NONBLOCK`), so the single-shot reads block until the header arrives. # Actual Results Many connections are refused with (we see 7-12/s on every ldap proxy): ``` proxyp(<fd>): header read failed 11 (Resource temporarily unavailable) lload_listener: proxyp(<fd>) failed ``` The PROXY header is never parsed; the connection is closed. # Expected Results `proxyp()` should wait for the PROXY header to arrive (up to a timeout) on a non-blocking socket, parse it, and let the connection proceed — matching the behavior lloadd users get from slapd. # Additional Information (my speculation and assumptions) 1. **Primary trigger.** The specific errno-11 message requires an open, non-blocking fd with *zero* bytes buffered. A peer that completes the TCP handshake but has not yet sent the header produces exactly this. `TCP_DEFER_ACCEPT` (from `LEV_OPT_DEFERRED_ACCEPT`) reduces the race but does not remove it: its retransmit-based timeout delivers a data-less established connection, and health checkers/scanners that connect and stay silent hit the same path. (A peer that connects and immediately sends FIN would instead yield `ret == 0` → the "header read insufficient data" branch, not EAGAIN.) 2. **Latent secondary bug (same root cause).** Even when some bytes are present but not the full header, the non-blocking `tcp_read()` returns a short read, hitting the "header read insufficient data" branch (`proxyp.c:85`). A PROXY header split across TCP segments is therefore also rejected. The same applies to the address (`proxyp.c:129`) and options (`proxyp.c:206`) reads. 3. **Suggested fix direction.** Harden `proxyp()` for non-blocking sockets: on `EAGAIN`, `poll()`/`select()` for readability with a bounded timeout and retry; accumulate the header/address/options across partial reads instead of assuming a single `tcp_read()` delivers each field in full. This fixes both the EAGAIN rejection and the split-header rejection, and keeps proxyp() correct for both slapd (blocking) and lloadd (non-blocking) callers. (An alternative — temporarily setting the fd blocking around the proxyp() call in `lload_listener()` — is simpler but blocks the accept thread on a slow/malicious peer and still needs a timeout.) If you nee additional information please let me know. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10552] New: LMDB database getting corrupted
by openldap-its＠openldap.org 28 Jul '26

28 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10552 Issue ID: 10552 Summary: LMDB database getting corrupted Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: donxenapo(a)gmail.com Target Milestone: --- We have deployed LMDB version 1.0.0 and we're getting corruption-type errors from some users. We don't have the exact number of affected users yet, but apparently deleting the database and recreating it seems to work around the issue. The error seems to happen either during a get or a put request, and once the database is corrupted, it will keep resulting in the same error for that user until the database is purged/recreated. Here are some examples of errors that we're getting: During Put: LMDB Put Failed Error: MDB_PROBLEM: Unexpected problem - txn should abort LMDB Put Failed Error: MDB_CORRUPTED: Located page was wrong type LMDB Put Failed Error: MDB_PAGE_NOTFOUND: Requested page not found During Get: LMDB Get Failed Error: MDB_PAGE_NOTFOUND: Requested page not found LMDB Get Failed Error: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid Sometimes it crashes during Put in memcpy, instead of returning an error. Call stack: memcpy(void) mdb_cursor_get mdb_txn_begin We're still in the process of collecting corrupted databases from our users, so we don't have any corruption examples yet. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10509] New: 2.7: Feature notes for announcement file
by openldap-its＠openldap.org 22 Jul '26

22 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10509 Issue ID: 10509 Summary: 2.7: Feature notes for announcement file 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: --- Add feature notes for the 2.7 announcement file -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10548] New: slapmodify replaces entryUUID
by openldap-its＠openldap.org 22 Jul '26

22 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10548 Issue ID: 10548 Summary: slapmodify replaces entryUUID Product: OpenLDAP Version: 2.6.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: dhawes(a)gmail.com Target Milestone: --- When using slapmodify with olcLastMod=TRUE, the entryUUID is replaced for every entry modified. This is undesirable and has implications with syncrepl. The check for lastmod is here: https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/slap… Replacing the entryUUID is here: https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/slap… More discussion is available at: 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 3

[Issue 10026] New: Refresh handling can skip entries (si_dirty not managed properly)
by openldap-its＠openldap.org 22 Jul '26

22 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10026 Issue ID: 10026 Summary: Refresh handling can skip entries (si_dirty not managed properly) Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Take MPR plain syncrepl with 3+ providers. When a provider's own syncrepl session transitions to persist and a it starts a new parallel session towards another host, that session always has to start as a refresh. If that refresh serves entries to us, our handling of si_dirty is not consistent: - if the existing persist session serves some of these entries to us, we can "forget" to pass the others to a newly connected consumer - same if the refresh is abandoned and we start refreshing from a different provider that might be behind what we were being served (again our consumers could suffer) - if we restart, si_dirty is forgotten and our consumers suffer even worse We might need to be told (at the beginning of the refresh?) what the end state we're going for is, so we can keep si_dirty on until then. And somehow persist that knowledge in the DB... -- You are receiving this mail because: You are on the CC list for the issue.

1 30

[Issue 10535] New: syncprov_play_accesslog issue when consumer up to date with provider but provider dirty
by openldap-its＠openldap.org 22 Jul '26

22 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10535 Issue ID: 10535 Summary: syncprov_play_accesslog issue when consumer up to date with provider but provider dirty 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: --- If the provider state is dirty (changes applied but contextCSN not) and a consumer connects to it with that cookie, syncprov_play_accesslog gets invoked but there is nothing to send. That is currently covered by an assert(). -- You are receiving this mail because: You are on the CC list for the issue.

1 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs