Move master changes to 5.7.0 release branch#1472
Merged
Merged
Conversation
…nd OpenSSL 3.x [HZ-5424] (#1464) Closes #1463 ## Summary - The Boost 1.83.0 + OpenSSL 3.x matrix entry of the `nightly-Windows` workflow fails to compile `rfc2818_verification.ipp`: `error C2027: use of undefined type 'asn1_string_st'` (followed by a cascading `C2660` on `memcmp`). - The client never references `boost::asio::ssl::rfc2818_verification`; it uses the modern `host_name_verification` (`hazelcast/src/hazelcast/util/util.cpp`). The broken `.ipp` was being dragged in transitively through the umbrella `<boost/asio/ssl.hpp>` include in three internal socket headers. - Replaced the umbrella include in `BaseSocket.h`, `SSLSocket.h`, and `SocketFactory.h` with the specific subheaders the codebase actually uses (`context.hpp`, `error.hpp`, `host_name_verification.hpp`, `stream.hpp`) — matching the include pattern already used in `util.cpp`. This avoids `rfc2818_verification.hpp` entirely. ## Root cause In Boost 1.83.0, `<boost/asio/ssl.hpp>` lists `<boost/asio/ssl/rfc2818_verification.hpp>` among its includes. In Boost.Asio's default header-only mode that pulls in `rfc2818_verification.ipp`, whose hostname-matching code dereferences `ASN1_STRING` fields directly (`domain->data`, `domain->length`). OpenSSL 3.0 made `ASN1_STRING` an opaque type whose layout is no longer exposed by the public headers, so MSVC refuses to compile the field accesses (hence `C2027`; the `C2660` is a follow-on because `domain->data` collapses to a non-pointer expression). GCC/Clang on Linux/macOS happen to accept the opaque-struct dereference more leniently on this path, which is why only the Windows + MSVC + OpenSSL 3.x combination breaks. Upstream Boost dropped `rfc2818_verification` from `<boost/asio/ssl.hpp>` after 1.83.0; it is no longer present in 1.90.0. That is why only the 1.83.0 matrix entry is affected. Tracking: HZ-5424
…side the row loop [HZ-5424] (#1471) Fixes #1470 ## Summary - `SqlTest.select` was iterating over 4 096 SQL rows and calling `EXPECT_THROW` three times per row to verify `get_object()` raises `index_out_of_bounds` / `illegal_argument`. That is **~12 000 C++ exception throws** per test run. - On Windows the CI step runs ProcDump as a debugger (`procdump -e -ma -w client_test.exe`). Every C++ `throw` raises SEH code `0xE06D7363`; the OS delivers this as a *first-chance debug event* to ProcDump **before** the C++ `catch` handler can run. ProcDump logs `[HH:MM:SS]Exception: E06D7363.?AVindex_out_of_bounds@...`, then calls `ContinueDebugEvent()` — **two mandatory kernel-mode round-trips per throw**. 12 000 throws × 2 = 24 000 kernel transitions, combined with 4 096 synchronous `map->get()` server calls, made the loop slow enough for the server-side connection health-check to fire and cancel the SQL cursor (`Client cannot be reached`). - Fix: fetch the first page before the main loop, run the three `EXPECT_THROW` checks on its first row only, then iterate all pages in a `for(;;)` loop starting from the already-fetched first page. Exception count drops from **12 000 to 3**. The `bounds_checked` flag is eliminated. ## Why it was Windows-only Linux/macOS CI does not use ProcDump. Without a debugger attached, `throw` → `catch` is entirely in-process with zero kernel transitions, so the loop completes well within any timeout. ## Root cause detail On Windows, C++ exceptions are built on SEH. When a debugger is attached via `DebugActiveProcess()`, the kernel suspends the target process's threads and delivers an `EXCEPTION_DEBUG_EVENT` to the debugger through the kernel debug port. The debugger must call `WaitForDebugEvent()`, process the event, and call `ContinueDebugEvent()` before the target resumes. This happens for *every* throw, even ones that are immediately caught — ProcDump cannot skip them. Under heavy exception load (12 000 throws), the cumulative stall is enough to trigger server-side timeouts.
ihsandemir
reviewed
Jun 2, 2026
ihsandemir
left a comment
ihsandemir
left a comment
Contributor
There was a problem hiding this comment.
Can you update the description how you generated this PR from master?
Contributor
Author
done |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport some changes from master to 5.7.0