Re:Compiler bug? Linker bug? Windows Kernel bug
by blattimwind on Monday February 26, 2018 @05:35AM
(#16464382)
Since it's only observed by execution, its entirely possible that the PE loader has been optimized in a low-level fashion leading to bugs that are not exposed in general I/O facilities.
Re:Compiler bug? Linker bug? Windows Kernel bug
by gmueckl on Monday February 26, 2018 @07:27AM
(#16464802)
My reading is that PE images are memory mapped into RAM instead of being read from disk. This is why they require write locks on the files during execution: the program image is backed from the corresponding file instead of the normal page file.
So my speculation is that this bug is a race condition between the cleanup of a dirty memory mapped section of a file and the reading of the same file contents in a separate mapping.
Re:Compiler bug? Linker bug? Windows Kernel bug
by ChrisSD on Monday February 26, 2018 @05:31AM
(#16464367)
Indeed but being loaded as code seems important as well. It sounds like the two used together, in certain extreme conditions, causes the issue.
Re:Compiler bug? Linker bug? Windows Kernel bug
by brucedawson on Monday February 26, 2018 @05:35PM
(#16469608)
Both parts are special. As the post says, there are three conditions:
1) Write the file with memory-mapped I/O
2) Read the file as a PE file (CreateProcess, LoadLibrary, etc., I'm not positive of the exact requirements but it's something special that I believe only PE files can hit)
3) Very heavy load
Re:Compiler bug? Linker bug? Windows Kernel bug
by vardump on Monday February 26, 2018 @06:20AM
(#16464558)
> memory-mapped (which isn't normal I/O)
Memory mapped I/O is very much normal I/O. Normal, as in "common" or "usual".
Re:Compiler bug? Linker bug? Windows Kernel bug
by mehrdadn on Monday February 26, 2018 @06:25AM
(#16464574)
>> memory-mapped (which isn't normal I/O)
> Memory mapped I/O is very much normal I/O. Normal, as in "common" or "usual".
You know well what I meant.
Re:Compiler bug? Linker bug? Windows Kernel bug
by vardump on Monday February 26, 2018 @02:17PM
(#16468096)
What you said left an impression memory mapped I/O is somehow unusual or special, while it's actually a fairly common type of I/O.
So while I did know what you meant, I found your comment misleading to someone who isn't familiar with the subject.
Too many programmers misunderstand and are scared of memory mapping as it is.
Edit (in response to comments): Actually, I don't think it has anything to do with PE files being optimized in some special fashion, because they say loading via LoadLibrary(Ex) can cause this issue too, and those are very much user-mode constructs, and hence can't mess with the caching/paging behavior (which are lower, in the kernel). AFAIK the only kernel-mode component to them is to just create a file mapping (NtCreateSection) and after that all they do is a bunch of user-mode juggling (fixing up relocations, loading other libraries that are depended on, calling entrypoints, etc.).