3 ms·

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.

by narag 9y ago

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.
vardump 9y ago
> Writing a binary executable file is not a common situation, only compilers do that. Not only compilers. Decompressors (.zip, etc.), installers and auto-updaters. There are more use cases for writing out executables than just compilers. Although these cases probably write sequentially and don't need to memory map the file and update sections in a random access fashion.
- narag 9y ago
  Look, there are a handful of details in the description that, for the right person, clearly and right away indicates that it's a very very specific, even fringe case. Saying that "basically it means..." as if it was a general case is terribly misguided because it's not. There are already a few comments explaining just that. Insisting in a misunderstanding is not very useful.
quietbritishjim 9y ago
I agree. But the comment I was referring to said "in some cases"; it never claimed it was a common case.

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.

by 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.

vardump 9y ago

> Writing a binary executable file is not a common situation, only compilers do that. Not only compilers. Decompressors (.zip, etc.), installers and auto-updaters. There are more use cases for writing out executables than just compilers. Although these cases probably write sequentially and don't need to memory map the file and update sections in a random access fashion.

narag 9y ago
Look, there are a handful of details in the description that, for the right person, clearly and right away indicates that it's a very very specific, even fringe case. Saying that "basically it means..." as if it was a general case is terribly misguided because it's not. There are already a few comments explaining just that. Insisting in a misunderstanding is not very useful.

quietbritishjim 9y ago

I agree. But the comment I was referring to said "in some cases"; it never claimed it was a common case.