fix(resolver): keep Winsock initialized for the process lifetime - #356
Merged
sgerbino merged 1 commit intoSep 10, 2026
Merged
Conversation
win_wsa_init reference counts WSAStartup/WSACleanup across the services
that derive from it, so the count reaches zero every time the last
io_context in a process is destroyed. An asynchronous GetAddrInfoExW is
still settling inside ws2_32 well past its completion routine, with no
way to observe when, and the WSACleanup lands under it: the fault is an
access violation on a system DNS thread, with no corosio frame on the
stack. That is the intermittent boost.corosio.resolver SEGFAULT on
Windows.
Hold one reference until static destruction so the count never falls back
to zero between one io_context and the next. Suppressing the WSACleanup
alone took the failure rate from 9/15 runs to 0/15 on a repro that tears
down a context with a lookup still in flight.
The earlier reorder of post() against work_finished() addressed a
different, and as it turns out inapplicable, theory. Drop it in favour of
the reactor's own convention: the work credit taken at initiation rides
with the op and is released where the op is consumed, on the scheduler
thread, so no foreign thread balances the count and the count cannot
reach zero with a completion still queued. Both directions now match
posix_resolver_service.
Two further defects on the same path:
- The GetAddrInfoExCancel handle is valid only until the completion
routine is entered or the first cancel consumes it, but it was
cleared in do_complete, which runs on the scheduler and may never run
at all. A resolver destroyed with a lookup pending therefore handed
Windows a handle it had already reclaimed. Retire it in the
completion routine, and let cancel() claim it, so exactly one of the
two owns it. The claim is taken under a lock but the cancel itself is
issued outside it, because GetAddrInfoExCancel can wait on the
completion routine.
- The ADDRINFOEXW hints were a local of resolve(), passed to a lookup
that outlives that frame. Move them into the op.
The new test tears down a context with the lookup still live in the
system resolver rather than already queued, which the existing test does
not reach: it resolves localhost, which the hosts file answers
synchronously.
|
An automated preview of the documentation is available at https://356.corosio.prtest3.cppalliance.org/index.html If more commits are pushed to the pull request, the docs will rebuild at the same URL. 2026-09-09 20:34:50 UTC |
|
GCOVR code coverage report https://356.corosio.prtest3.cppalliance.org/gcovr/index.html Build time: 2026-09-09 20:54:17 UTC |
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.
win_wsa_init reference counts WSAStartup/WSACleanup across the services that derive from it, so the count reaches zero every time the last io_context in a process is destroyed. An asynchronous GetAddrInfoExW is still settling inside ws2_32 well past its completion routine, with no way to observe when, and the WSACleanup lands under it: the fault is an access violation on a system DNS thread, with no corosio frame on the stack. That is the intermittent boost.corosio.resolver SEGFAULT on Windows.
Hold one reference until static destruction so the count never falls back to zero between one io_context and the next. Suppressing the WSACleanup alone took the failure rate from 9/15 runs to 0/15 on a repro that tears down a context with a lookup still in flight.
The earlier reorder of post() against work_finished() addressed a different, and as it turns out inapplicable, theory. Drop it in favour of the reactor's own convention: the work credit taken at initiation rides with the op and is released where the op is consumed, on the scheduler thread, so no foreign thread balances the count and the count cannot reach zero with a completion still queued. Both directions now match posix_resolver_service.
Two further defects on the same path:
The GetAddrInfoExCancel handle is valid only until the completion routine is entered or the first cancel consumes it, but it was cleared in do_complete, which runs on the scheduler and may never run at all. A resolver destroyed with a lookup pending therefore handed Windows a handle it had already reclaimed. Retire it in the completion routine, and let cancel() claim it, so exactly one of the two owns it. The claim is taken under a lock but the cancel itself is issued outside it, because GetAddrInfoExCancel can wait on the completion routine.
The ADDRINFOEXW hints were a local of resolve(), passed to a lookup that outlives that frame. Move them into the op.
The new test tears down a context with the lookup still live in the system resolver rather than already queued, which the existing test does not reach: it resolves localhost, which the hosts file answers synchronously.