On 28 February 2018 at 19:10, Bruce Dawson ***@***.***> wrote: For more details on this bug see this blog post: https://randomascii.wordpress.com/2018/02/25/compiler-bug- linker-bug-windows-kernel-bug/ The Windows kernel has a rare bug which sometimes leads to recently created binaries crashing due to lack of a FlushFileBuffers call in the kernel. This happens when a PE file (DLL or EXE) is created using a file mapping and then is executed shortly afterwards (or LoadLibrary for a DLL). The symptom is that pages of zeroes get mapped in to some of the pages instead of valid code. This is rare and only happens during periods of very high disk activity, but it was seen on about 3-4% of Chrome builds on my workstation when using goma. It shows up when we generate a binary as part of the build (perhaps protoc.exe) and then run it immediately afterwards - occasionally the freshly generated binary crashes. This bug was confirmed with Microsoft who are working on a fix. The interim workaround is to call FlushFileBuffers on the output file when finished linking it. This workaround was implemented in Chromium using a Python wrapper and this has been 100% effective. The change can be seen here: https://chromium-review.googlesource.com/c/chromium/src/+/876683/10/ The tracking bug (20+ months in the making) can be found here: https://bugs.chromium.org/p/chromium/issues/detail?id=644525#c42 A request for the VS team to add this workaround to their linker is tracked in this link - apparently they have added the workaround and it will ship later this year. https://developercommunity.visualstudio.com/content/ problem/191590/linker-needs-workaround-for-windows-kernel-bug.html It's a nasty bug. Luckily it is quite rare. Luckily it is also quite easy to work around. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#24169>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA_p-HSLeL6VWXtQcaQk6FSsCwgX7ks5tZQn1gaJpZM4SWPBA> .