Repository navigation
Conversation
…ny connections mio 1.2.3 has a use-after-free in Windows named pipes (tokio-rs/mio#2011, fixed by tokio-rs/mio#2014): many hook connections opening and closing quickly crash Coucou with STATUS_HEAP_CORRUPTION (0xC0000374). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 23, 2026
This branch has not been deployed
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.
Coucou for Windows can crash with heap corruption (
0xC0000374, no panic, no log line: the process just disappears) when many hook connections open and close quickly on the relay pipe. The cause is in mio 1.2.3, the library under tokio's named pipes: a use-after-free reported as tokio-rs/mio#2011 and fixed by tokio-rs/mio#2014 in mio 1.2.4.This PR only bumps
mio1.2.3 → 1.2.4 inwindows/Cargo.lock(two lines; nothing else in the lockfile changes,cargo test --lockedaccepts it).How I found it. While testing #872 (#853, hook server stops after a failed connect), I hammered the pipe: 8 workers opening and closing client connections for 10 s (script below). Coucou didn't hang; it crashed. Windows' crash log shows
coucou.exewithc0000374each time.Verification on Windows 11 Pro 26H2 (20-thread CPU):
pipe.rs's loop (no Coucou code)The minimal copy crashes even when each connection is dropped right away without reading, so it's not Coucou's handler code.
cargo test --lib: 516 passed.npm test: 466 passed.Does it happen in normal use? I haven't seen it happen on its own: a normal session sends far fewer connections than this test. The mio issue says it needs a busy multi-threaded runtime, which a burst of parallel subagents or a loaded machine can produce. So it's a rare crash, but an easy fix.
About #872: in these runs, the failed-
connect()path it fixes never ran, so this doesn't replace it. It just fixes a different way the relay pipe can die.Stress script (PowerShell)
🤖 Generated with Claude Code