You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Flaky Windows handle count in loop_drop_terminates_live_children_and_releases_their_handles (83 vs 82) #26
loop_drop_terminates_live_children_and_releases_their_handles (crates/turnloop-contract/tests/windows_lifetimes.rs, added in #13) failed intermittently on windows-2025 default mode in PR #24's run 34941544032. PR #24 only changes release.yml and release.py:
assertion `left == right` failed: live-child drop leaked a native handle
left: 83
right: 82
It passed on #13, #16, #22 and #25. The test compares GetProcessHandleCount against an exact baseline after dropping a loop with live children.
Likely causes to rule out:
Not a leak: a handle opened by the OS or runtime asynchronously during the window, for example a thread-pool wait registration still being torn down after the child's wait callback, or a job object/process handle released slightly later.
A real leak: a handle leaked on a rare ordering (child exit racing loop drop).
Expected: find which handle it is (for example with NtQueryObject/handle-type enumeration in the failure message), then fix the leak or wait for asynchronous release deterministically. Don't loosen the exact comparison.
Fixed in #32 (commit 8610b97). Root cause was not a leak: the outstanding handle is a thread-pool WaitCompletionPacket that Windows releases on its own threads shortly after UnregisterWaitEx joins the callback. A 192-cycle sweep on windows-2025 (run 34954538795) showed 0 movements idle and 117–138 under load, always oscillating by exactly one and never accumulating. The exact comparison is kept; only the sampling now waits for the count to settle (bounded 5 s), and failures name the handle type.
Activity
Wait out the Windows thread pool's own wait-packet release
Fix the flaky timer precision and Windows handle-count gates (#30, #26)…
proggeramlug commentedon Sep 15, 2026
Fixed in #32 (commit 8610b97). Root cause was not a leak: the outstanding handle is a thread-pool
WaitCompletionPacketthat Windows releases on its own threads shortly afterUnregisterWaitExjoins the callback. A 192-cycle sweep on windows-2025 (run 34954538795) showed 0 movements idle and 117–138 under load, always oscillating by exactly one and never accumulating. The exact comparison is kept; only the sampling now waits for the count to settle (bounded 5 s), and failures name the handle type.