Of course it's a concurrency bug. It races sending data to the kernel against the kernel sending data to the network. If the wrong one wins the bug occurs.
Isn't that like saying there can never be a language with safe concurrency since the code could interact with C code that segfaults?
I dunno this kinda reminds me of the 10/10 Rust CVE that turned out to be cmd.exe on Windows not sanitizing inputs and languages like Java just labeled it "won't fix".
This does not appear to be a concurrency bug though?
Of course it's a concurrency bug. It races sending data to the kernel against the kernel sending data to the network. If the wrong one wins the bug occurs.
But it did not take 2 threads within the same application to interact in a bad way on data the system controlled to cause this problem.
This reads more like an overly broad transition in a deterministic state machine. The fix was to split up a bad transition to shutdown.
2 replies →
Isn't that like saying there can never be a language with safe concurrency since the code could interact with C code that segfaults? I dunno this kinda reminds me of the 10/10 Rust CVE that turned out to be cmd.exe on Windows not sanitizing inputs and languages like Java just labeled it "won't fix".
2 replies →
“ a race condition that occurred only under specific conditions — in the hyper library”