6 ms·

So basically if you write and read immediately, windows will give you bad data in some cases. Not a good sign for the underlying design.

huhtenberg 9y ago
No, basically it's not like that. From the TFA: if a program writes a PE file (EXE or DLL) using memory mapped file I/O and if that program is then immediately executed (or loaded with LoadLibrary or LoadLibraryEx), and if the system is under very heavy disk I/O load then a necessary file-buffer flush may fail
- dingo_bat 9y ago
  I don't know if you're trolling. > if a program writes a PE file (EXE or DLL) using memory mapped file I/O and Write > if that program is then immediately executed (or loaded Read immediately > then a necessary file-buffer flush may fail You get bad data in memory.
  - huhtenberg 9y ago
    You've abstracted very specific conditions to the point of absurdity. I don't see any reason for that except for pulling a strawman and taking a stab at Windows.
- quietbritishjim 9y ago
  How does your comment contradict the parent one?
  - barrkel 9y ago
    Memory-mapped I/O is a lot more precise a description of "writing" and more unusual than simply writing out, and execution similarly is not a normal read path for a just-written file. The parent made it sounds like you could just write a loop with for(;;) { write_file("x"); read_file("x"); } and expect discrepancies. That's not the case and it's wilfully misleading to suggest it is.
    - quietbritishjim 9y ago
      The parent said "in some cases". I guess it could be misinterpreted, but I took that to mean "in some very specific access patterns" (rather than, say, "in any access pattern some random small proportion of the time").
      - ksk 9y ago
        Um, also, in some cases, I might win the lottery.
  - narag 9y ago
    Writing a binary executable file is not a common situation, only compilers do that. If you add the unusual heavy IO, this is a fringe case.
    - mehrdadn 9y ago
      [Edit: whoops, never mind, thanks. Might be worth adding the memory-mapped part to your comment to clarify for others too.]
      - narag 9y ago
        Not the same. Notice the memory mapped file bit.
      - DougBTX 9y ago
        You're right that it is an example of a case that matches the "basic" description of the conditions to hit the bug, but it probably won't satisfy any of the three conditions when they are considered in detail: * The files being written probably won't be using memory mapped IO (I'd expect them to use the equivalent of fwrite instead) as the installer won't need to make complex changes to the binaries in the same way that a compiler/linker would * There will likely be a significant delay between writing the file and running it compared with a build process that uses its own build output as part of the build (even in the build process case, the bug went away for a year, possibly due to an additional delay between the write and execute steps) * Once the installer has run, the system will probably not be under heavy load (the author was running a highly parallel build on a 24-core machine, and this bug was still only hit in 3% of builds) Really the earlier post was just misleading, as it implies the bug is much easier to hit than it really is.
        kuschku 9y ago
        There are other use cases where this might occur, though – JITs that store JITed binaries on disk. That’s rare (usually there you’d read it back in and execute in your process space), but it’d be at least a second realistic scenario.
    - 9y ago
  - DougBTX 9y ago
    The parent uses weasel words https://en.wikipedia.org/wiki/Weasel_word https://en.wikipedia.org/wiki/Weasel_word that, while technically correct, imply something false. The comment is refuting the implication. Here the implication is that there is a fundamental design flaw in the OS that may cause widespread issues, when really this is a bug in quite a narrow edge case: it may happen when building colossal projects repeatedly on very high spec computers, the article suggests that the team at Microsoft investigating the bug couldn't reproduce it since they couldn't build Chrome as quickly as the author could.
- Const-me 9y ago
  And also this only happens on multi-socked (not just multi-core) systems. So the underlying problem is likely related to cache coherency issues across NUMA nodes.
- cryptonector 9y ago
  I'm assuming that the linker exits before the program it linked is executed. I'd hope so! If so then this is clearly an OS bug.
mehrdadn 9y ago
You might as well go all the way and simplify it down to "so basically if you run Windows you might get corrupt data" to make your point clearer.
- torstenvl 9y ago
  HN Guidelines: "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."
- DiabloD3 9y ago
  You might as well go further and simplify it down to "if a computer is involved, it will corrupt your data".
CJefferson 9y ago
memmove in glibc produces wrong results in some cases (that was a fun over-Christmas debugging session). There is bugs in all software.

huhtenberg 9y ago

No, basically it's not like that. From the TFA: if a program writes a PE file (EXE or DLL) using memory mapped file I/O and if that program is then immediately executed (or loaded with LoadLibrary or LoadLibraryEx), and if the system is under very heavy disk I/O load then a necessary file-buffer flush may fail

dingo_bat 9y ago
I don't know if you're trolling. > if a program writes a PE file (EXE or DLL) using memory mapped file I/O and Write > if that program is then immediately executed (or loaded Read immediately > then a necessary file-buffer flush may fail You get bad data in memory.
- huhtenberg 9y ago
  You've abstracted very specific conditions to the point of absurdity. I don't see any reason for that except for pulling a strawman and taking a stab at Windows.
quietbritishjim 9y ago
How does your comment contradict the parent one?
- barrkel 9y ago
  Memory-mapped I/O is a lot more precise a description of "writing" and more unusual than simply writing out, and execution similarly is not a normal read path for a just-written file. The parent made it sounds like you could just write a loop with for(;;) { write_file("x"); read_file("x"); } and expect discrepancies. That's not the case and it's wilfully misleading to suggest it is.
  - quietbritishjim 9y ago
    The parent said "in some cases". I guess it could be misinterpreted, but I took that to mean "in some very specific access patterns" (rather than, say, "in any access pattern some random small proportion of the time").
    - ksk 9y ago
      Um, also, in some cases, I might win the lottery.
- narag 9y ago
  Writing a binary executable file is not a common situation, only compilers do that. If you add the unusual heavy IO, this is a fringe case.
  - mehrdadn 9y ago
    [Edit: whoops, never mind, thanks. Might be worth adding the memory-mapped part to your comment to clarify for others too.]
    - narag 9y ago
      Not the same. Notice the memory mapped file bit.
    - DougBTX 9y ago
      You're right that it is an example of a case that matches the "basic" description of the conditions to hit the bug, but it probably won't satisfy any of the three conditions when they are considered in detail: * The files being written probably won't be using memory mapped IO (I'd expect them to use the equivalent of fwrite instead) as the installer won't need to make complex changes to the binaries in the same way that a compiler/linker would * There will likely be a significant delay between writing the file and running it compared with a build process that uses its own build output as part of the build (even in the build process case, the bug went away for a year, possibly due to an additional delay between the write and execute steps) * Once the installer has run, the system will probably not be under heavy load (the author was running a highly parallel build on a 24-core machine, and this bug was still only hit in 3% of builds) Really the earlier post was just misleading, as it implies the bug is much easier to hit than it really is.
      - kuschku 9y ago
        There are other use cases where this might occur, though – JITs that store JITed binaries on disk. That’s rare (usually there you’d read it back in and execute in your process space), but it’d be at least a second realistic scenario.
  - 9y ago
- DougBTX 9y ago
  The parent uses weasel words https://en.wikipedia.org/wiki/Weasel_word https://en.wikipedia.org/wiki/Weasel_word that, while technically correct, imply something false. The comment is refuting the implication. Here the implication is that there is a fundamental design flaw in the OS that may cause widespread issues, when really this is a bug in quite a narrow edge case: it may happen when building colossal projects repeatedly on very high spec computers, the article suggests that the team at Microsoft investigating the bug couldn't reproduce it since they couldn't build Chrome as quickly as the author could.
Const-me 9y ago
And also this only happens on multi-socked (not just multi-core) systems. So the underlying problem is likely related to cache coherency issues across NUMA nodes.
cryptonector 9y ago
I'm assuming that the linker exits before the program it linked is executed. I'd hope so! If so then this is clearly an OS bug.

mehrdadn 9y ago

You might as well go all the way and simplify it down to "so basically if you run Windows you might get corrupt data" to make your point clearer.

torstenvl 9y ago
HN Guidelines: "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."
DiabloD3 9y ago
You might as well go further and simplify it down to "if a computer is involved, it will corrupt your data".

CJefferson 9y ago

memmove in glibc produces wrong results in some cases (that was a fun over-Christmas debugging session). There is bugs in all software.