[llvm-bugs] [Bug 24554] New: Windows sanitizer tests are flaky due to LNK1104, when the linker cannot overwrite the last executable

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=24554

            Bug ID: 24554
           Summary: Windows sanitizer tests are flaky due to LNK1104, when
                    the linker cannot overwrite the last executable
           Product: compiler-rt
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: compiler-rt
          Assignee: unassignedbugs at nondot.org
          Reporter: rnk at google.com
                CC: aaron at aaronballman.com, llvm-bugs at lists.llvm.org,
                    peter at pcc.me.uk
    Classification: Unclassified

The sanitizer tests (asan, ubsan, etc) often have RUN lines like the following:

// RUN: %clangxx -fsanitize=integer-divide-by-zero -DDIVIDEND=0 %s -o %t &&
%run %t 2>&1 | FileCheck %s
// RUN: %clangxx -fsanitize=integer-divide-by-zero -DDIVIDEND=1U %s -o %t &&
%run %t 2>&1 | FileCheck %s
// RUN: %clangxx -fsanitize=float-divide-by-zero -DDIVIDEND=1.5 %s -o %t &&
%run %t 2>&1 | FileCheck %s

This repeatedly compiles the test with different settings, links it, and runs
it in place. This pattern fails every so often on Windows for reasons that
aren't fully understood. It seems like the %t process is still alive when the
next linker command is running, and Windows doesn't let you overwrite EXEs or
DLLs that are in use.

It's possible that this is a Python/lit bug. If the lit process isn't closing
it's process handle before running the next command, that might be the cause.

It's possible that this is caused by anti-virus software that is still scanning
the executable, but unlikely, since the sanitizer-windows buildbot doesn't have
any third-party AV on it.

Regardless, we should fix it.

One workaround is to not reuse %t over and over in tests, but this will be
difficult to enforce, since it works on Linux.

Another workaround is to make '%run' on Windows expand to a wrapper program
that waits for the child process to really exit.

If the theory about 'lit' is correct, the best fix would be to use the Popen
object to explicitly close the handle before running the next process.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150824/f68e1c08/attachment.html>