Repository navigation
fix: never release the process-lifetime Winsock hold - #407
Merged
Merged
Conversation
The process hold kept the Winsock count above zero between io_contexts but still released it from a static destructor, so WSACleanup ran at exit. An asynchronous GetAddrInfoExW can still be settling inside ws2_32 then, and WSACleanup unloads the name-service providers under it: a system thread-pool worker faults with no corosio frame on its stack, after every test has passed. Take the hold once and never drop it; process teardown reclaims Winsock.
|
An automated preview of the documentation is available at https://407.corosio.prtest3.cppalliance.org/index.html If more commits are pushed to the pull request, the docs will rebuild at the same URL. 2026-10-28 12:53:11 UTC |
|
GCOVR code coverage report https://407.corosio.prtest3.cppalliance.org/gcovr/index.html Build time: 2026-10-28 12:54:23 UTC |
Benchmark report
linux — full results (226 benchmarks, 5 iterations, 1.5s each)accept_churn
fan_out
http_server
local_socket_latency
local_socket_throughput
socket_latency
socket_throughput
windows — full results (77 benchmarks, 5 iterations, 1.5s each)accept_churn
fan_out
http_server
socket_latency
socket_throughput
macos — full results (113 benchmarks, 5 iterations, 1.5s each)accept_churn
fan_out
http_server
local_socket_latency
local_socket_throughput
socket_latency
socket_throughput
Run & raw JSON artifacts · flag rule: |median Δ| > max(2%, 3×CV of the noisier side) · advisory only |
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
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.
The
boost.corosio.resolvertest sometimes crashes on Windows after every test has passed.developCI hit it on the MinGW static leg (run 40588449659) with anACCESS_VIOLATIONatffffffff00000000.The process-lifetime Winsock hold still releases its reference from a static destructor, so
WSACleanupruns at exit. An asynchronousGetAddrInfoExWcan still be running inside ws2_32 at that point.WSACleanupunloads the name-service providers under it, and a system thread-pool worker faults with no corosio frame on its stack. This is the race from 039fe65, moved to process exit.The hold is now taken once and never released. Process teardown reclaims Winsock.
Captured under gdb on the MinGW static build, every crash shows the same three threads:
exit→win_wsa_hold_process()::holder::~holder→WSACleanup.GetAddrInfoExW→DnsQueryEx.0xffffffff00000000.A Windows debug job ran
resolver.exein a loop on 4 vCPUs: 24,000 runs on 8 parallel workers, then up to 1,800 runs under gdb on 6 workers.