3 ms·

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.

• inexcf 3mo ago
  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".
  • microgpt 3mo ago
    You mean the one where Windows doesn't have argv the way Unix does, and instead just has a single string that is interpreted slightly differently by each executable? That is a language making false assertions about how the underlying platform works, causing an impedance mismatch that is impossible to fix.
    • inexcf 3mo ago
      Yeah, the one most languages (except for Rust)* decided was not a language problem and did not fix. *should clarify, Node.js, PHP, and Haskell did ship patches. Python, Ruby, Erlang, and Go opted for documentation updates; Java went "won't fix."
• tetha 3mo ago
  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.
  • microgpt 3mo ago
    Concurrency bugs don't have to be within a single process.
    • inexcf 3mo ago
      By that definition, every write() call that doesn't check for EAGAIN is a concurrency bug you're racing the disk controller. The term stops meaning anything.