[PATCH] D46621: [Support] call FlushFileBuffers when closing raw_fd_ostream on Windows

[Zachary Turner via llvm-commits]

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

So probably a good idea to think about next steps (eg obtaining one of the
“corrupt” files from a buildbot)
On Tue, May 8, 2018 at 8:00 PM Bob Haarman via Phabricator <
reviews at reviews.llvm.org> wrote:

> inglorion added a comment.
>
> 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
> https://reviews.llvm.org/D42925, I would like to give this a shot and see
> if it helps.
>
>
> https://reviews.llvm.org/D46621
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180509/d99deb93/attachment.html>