Avoid Windows kernel bug using Python hack

On about 3-4% of Chrome builds on my workstation one of the executables
generated and then used during the build will crash. The binary on disk
is always fine but the loader sometimes maps in pages of zeroes where it
should be mapping in pages from the just-generated binary. Having a page
of zeroes where you are expecting useful instructions tends to lead to
crashes.

This appears to be a bug in the OS disk cache. My suspicion is that this
kernel bug only happens on multi-socket systems, but this is
speculation.

This bug happens regardless of which compiler or linker is used, and
appears to happen on multiple Windows versions. The best reproes have
been on Windows 10 Creators Update, or at least that is where I have
done most of my testing.

Extensive testing - hundreds of overnight builds - has shown that the
problem goes away if FlushFileBuffers is called on the output file
after linking is finished. Eventually this fix/hack will be coded into
lld-link.exe, but for now it is put in tool_wrapper.py to fix the bug
for both link.exe and lld-link.exe.

Earlier versions of this fix only applied it to files with .exe
extensions. However the bug is believed to have happened with DLLs, and
may also affect .lib files created by the linkers, so now it is done
always. The belief is that the performance impact will be negligible.

Importing of win32file required some trickiness because in the context
of ninja builds of Chrome the depot_tools python.bat file is apparently
not called. This means that the python directory is not added to the
system path. The python runtime correctly finds win32file.pyd and calls
LoadLibrary on it but the OS then finds its dependencies in another
version of python installed on the system and the DLL load fails if
those are 64-bit instead of 32-bit.

Bug: 644525
Change-Id: I71d63b47050385e2e5ba46ced9c8018220370ba7
Reviewed-on: https://chromium-review.googlesource.com/876683
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Zachary Turner <zturner@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533137}

build/toolchain/win/tool_wrapper.py

@@ -16,6 +16,16 @@ import stat
 import string
 import sys
 
+# tool_wrapper.py doesn't get invoked through python.bat so the Python bin
+# directory doesn't get added to the path. The Python module search logic
+# handles this fine and finds win32file.pyd. However the Windows module
+# search logic then looks for pywintypes27.dll and other DLLs in the path and
+# if it finds versions with a different bitness first then win32file.pyd will
+# fail to load with a cryptic error:
+#     ImportError: DLL load failed: %1 is not a valid Win32 application.
+os.environ['path'] = os.path.dirname(sys.executable) + ';' + os.environ['path']
+import win32file    # pylint: disable=import-error
+
 BASE_DIR = os.path.dirname(os.path.abspath(__file__))
 
 # A regex matching an argument corresponding to the output filename passed to
@@ -141,10 +151,14 @@ class WinTool(object):
     # For that reason, since going through the shell doesn't seem necessary on
     # non-Windows don't do that there.
     pdb_name = None
+    pe_name = None
     for arg in args:
       m = _LINK_PDB_OUT_ARG.match(arg)
       if m:
         pdb_name = m.group('out')
+      m = _LINK_EXE_OUT_ARG.match(arg)
+      if m:
+        pe_name = m.group('out')
     for retry_count in range(_LINKER_RETRIES):
       retry = False
       link = subprocess.Popen(args, shell=sys.platform == 'win32', env=env,
@@ -167,6 +181,13 @@ class WinTool(object):
       result = link.wait()
       if not retry:
         break
+    if result == 0:
+      # Flush the file buffers to try to work around a Windows 10 kernel bug,
+      # https://crbug.com/644525
+      output_handle = win32file.CreateFile(pe_name, win32file.GENERIC_WRITE,
+                                      0, None, win32file.OPEN_EXISTING, 0, 0)
+      win32file.FlushFileBuffers(output_handle)
+      output_handle.Close()
     return result
 
   def ExecAsmWrapper(self, arch, *args):