I won’t block or approve, but I would be extraordinarily surprised if it turns out to be the culprit since the Windows team already confirmed it to only be a problem with mapped file i/o (and if it weren’t, it would probably be so common that the whole world would have blown up by now).<br><br>So probably a good idea to think about next steps (eg obtaining one of the “corrupt” files from a buildbot)<br><div class="gmail_quote"><div dir="ltr">On Tue, May 8, 2018 at 8:00 PM Bob Haarman via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">inglorion added a comment.<br>
<br>
It's a speculative fix. I'm not getting the error locally and it doesn't consistently reproduce anywhere I know of, which makes it hard to think of a way to ascertain that it actually fixed the problem. It's just that I noticed that a number of files we write when doing ThinLTO are written through raw_fd_ostream, and we then occasionally see bytes being read as 0 when they shouldn't be, which is a problem we fixed elsewhere by calling FlushFileBuffers. If we land this and the problem persists I think we should revert it (for the reasons zturner mentioned), but given the similarity to the problem we worked around with <a href="https://reviews.llvm.org/D42925" rel="noreferrer" target="_blank">https://reviews.llvm.org/D42925</a>, I would like to give this a shot and see if it helps.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D46621" rel="noreferrer" target="_blank">https://reviews.llvm.org/D46621</a><br>
<br>
<br>
<br>
</blockquote></div>