Wow, this fixed a lot of tests, down to only 17 lsan standalone tests failing :) (26 already passing)

@aganea Thank you very much!

@vitalybuka There seems to be a bug in MSVCs bit-field implementation, which causes the disable.c test to fail.
This reproducer (assert) passes with gcc and fails with MSVC (m.tag is 0xffffffff):

cpp
#include <stdint.h>
#include <assert.h>

@vitalybuka
I've been working on this on-off for the past months and have gotten the tests in the following state:

Unsupported: 41
Passed     : 19
Failed     : 48

There is still the bug with the tracer thread deadlocking during an allocation made in the Microsoft CRT thread setup code when using Asan+Lsan.
I hope I can get the failing tests passing.

I have now split the lsan TestCases chages into https://reviews.llvm.org/D124322
and managed to get the lsan+asan TestCases nearly to work. The current problem is,
that during the start of the RunThread in StopTheWorld, we are intercepting a call
to calloc done by the ucrt in ucrtbase!DllMainDispatch, which somehow results in a deadlock.
If someone has an idea, how we could avoid/fix this, I would be very happy to hear it.

I always forget to change the line endings, sorry :(

Since I am currently unable to intercept the ExitProcess/TerminateProcess in the ucrt (exit_or_terminate_process in Windows Kits\10\Source\10.0.22000.0\ucrt\startup\exit.cpp:143)
I inserted a call to Die in HandleLeaks (just like on Linux). This brings the passing Test up to 22

The CI seems to fail because of the parent revision? Retry

I was wrong, the Problem was, that I didn't change the exit code, when a leak gets detected.
I now intercept ExitProcess and change the exit code in there, with this there are already 12 Tests passing on Windows.

Hi,
today I found some more time to play/progress with this patch. I'm generally optimistic that most of the basic lsan stuff should already be working on Windows.
However without some help of you, I'm unable to get the tests to properly work. The main Problem I looked into today is that llvm-lit.py seems to be somehow unable to capture the stdout/err of the tests. More precisely my Debugging showed that when I insert a print(procs[-1].stdout.read()) at TestRunner.py:790 I get the correctly captured stdout of a test e.g.:

=================================================================
==25028==ERROR: LeakSanitizer: detected memory leaks

Update Patch. I reformatted but diffed the wrong commit hash, sorry :(

Update Patch. I reformatted but diffed the wrong commit hash, sorry :(

Fix Patch

Fix Patch

Wow, I was so confused... thanks!

Rebase patch

Rebase patch

Updated the Tests.
The Problem with Lsan+Asan still exists. I have just disabled them for now.
I hope anyone can help me with getting the tests to run correctly?

All the lsan tests, when run in lsan+asan mode, Deadlock in StopTheWord when creating the tracer thread...

@aganea Thanks for your help. I already did everything you wrote (I am however using the coreutils provided by Git).
check-asan works on my new computer. I still don't know why it didn't work on my older one...
I will try to get the lsan tests working (and hopefully passing 😉) on windows soon.

@vitalybuka
No check-asan doesn't work for me. It just hangs forever and does absolutely nothing. No output, nothing showing up in Task Manager with high CPU usage or anything.
However check-clang does work. Is there some documentation on running check-asan on windows.
I also saw that none of the Windows buildbots check/test anything related to sanitizers. It seems to me that none of the sanitizer stuff gets ever tested on Windows?
Do the test for sanitizers_common/asan/ubsan/etc. even work on Windows?

@vitalybuka I have now removed all LSAN_BASE occurrences.
However the invocations of the compiled test executables don't seem to work either.
This doesn't work:
// RUN: %env_lsan_opts=use_stacks=0:use_registers=0 not %run %t foo 2>&1 | FileCheck %s --check-prefix=CHECK-do
It generates this error:

[build] $ ":" "RUN: at line 3"
[build] $ "env" "LSAN_OPTIONS=:detect_leaks=1:use_stacks=0:use_registers=0" "not" "E:\git\llvm-project\llvm\build\ninja_debug\projects\compiler-rt\test\lsan\X86_64LsanConfig\TestCases\Output\leak_check_at_exit.cpp.tmp.exe" "foo"
[build] note: command had no output on stdout or stderr
[build] error: command failed with exit status: True

The problem is, that LSAN_BASE is not always use_stacks=0:use_registers=0.
Also there are many test cases, where LSAN_BASE gets used multiple times.
Removing it would result in bad repetition.

@vitalybuka could you or someone else help me get the lsan tests running on Windows?
For example lets look at compiler-rt\test\lsan\TestCases\leak_check_at_exit.cpp (and basically all other tests, this serves as an easy example)
I imagine that the following defines a variable called LSAN_BASE :
// RUN: LSAN_BASE="use_stacks=0:use_registers=0"
This doesn't seem to work on Windows.
It gives the following error message:

[build] $ ":" "RUN: at line 2"
[build] $ "LSAN_BASE=use_stacks=0:use_registers=0"
[build] # command stderr:
[build] 'LSAN_BASE=use_stacks=0:use_registers=0': command not found

Fix continue in loop.
Thanks @mstorsjo!

Fix warning

@mstorsjo probably my only option is to silence the warning locally?

Simplify Architecture checks

In D115204#3200750, @vitalybuka wrote:

@clemenswasser Please upload fixed version here and we will try again

Fix typo

@mstorsjo I hope this fixes all of your Problems.
For me all sanitizer tests pass on X64 and I386.
Could someone test if the tests also pass on ARM and ARM64?

@mstorsjo sorry for the inconveniences.
I am quite busy right now. I will probably fix this either later today or tomorrow.

In D115204#3198568, @vitalybuka wrote:

Please update the summary, in particular remove:

So I couldn't test if this port actually works
Many other SanitizerUnitTests fail to compile (look in the attached log):

I assume you have resolve the issue in the summary?

Disable SegvInCallback test on Windows

Implement ProcessGlobalRegions
Fix Interceptors for Windows

Add error handling

Split this patch up into multiple smaller ones:

• D115186
• D115204
• D115262

Catch all SEH Exceptions like EXCEPTION_ACCESS_VIOLATION during execution of the callback in StopTheWorld and report them.
This makes the last failing test SegvInCallback pass on Windows 🎉

Cleanup of the StopTheWorld implementation.
Fix the following bug:

In D115204#3176168, @clemenswasser wrote:

@vitalybuka I can now run the tests on Windows. However the SuspendThreadsAdvanced test currently fails.
I think it fails because of an issue in my implementation of StopTheWorld.
The problem is that between the call to CreateToolhelp32Snapshot and suspending the Threads, there are still new threads being created, which are then not part of the snapshot.
Because of that, new threads can't being suspended.
Do you (or someone else) have any idea how I could fix this?

clang-format :(

@vitalybuka I can now run the tests on Windows. However the SuspendThreadsAdvanced test currently fails.
I think it fails because of an issue in my implementation of StopTheWorld.
The problem is that between the call to CreateToolhelp32Snapshot and suspending the Threads, there are still new threads being created, which are then not part of the snapshot.
Because of that, new threads can't being suspended.
Do you (or someone else) have any idea how I could fix this?

In D115204#3175333, @vitalybuka wrote:

Many other SanitizerUnitTests fail to compile (look in the attached log):

Something wrong with the compiler. Can you try different revisions and compare results HEAD, HEAD~10000 etc.?
If it's broken on HEAD then you can file a bug.

Hopefully fixes test StopTheWorld.SuspendThreadsAdvanced

@vitalybuka No I don't have permissions to push. Could you please do it for me :)

Remove ASSERT_NO_THROW from StopTheWorld tests

In D115186#3174939, @vitalybuka wrote:

S

In D115186#3174798, @clemenswasser wrote:

In D115186#3174760, @vitalybuka wrote:

I assume you have no committer access?

I don't know. Is that important. Can you please explain what you mean by that? :)

If you asking then you unlikely have one. :) you can't push into git repo.
Someone else will need to commit patches for your, often reviewer.
I will do that.

In D115186#3174760, @vitalybuka wrote:

I assume you have no committer access?

Remove wrong interceptors

Use LF line endings

Apply clang-format

Move __lsan_init call inside of SANITIZER_WINDOWS ifdef

Changed to core.autocrlf=false

You should also change compiler-rt/lib/asan/asan_win.cpp like this:

diff --git a/compiler-rt/lib/asan/asan_win.cpp b/compiler-rt/lib/asan/asan_win.cpp
index 8044ae16ff9b..1577c83cf994 100644
--- a/compiler-rt/lib/asan/asan_win.cpp
+++ b/compiler-rt/lib/asan/asan_win.cpp
@@ -134,7 +134,7 @@ INTERCEPTOR(int, _except_handler4, void *a, void *b, void *c, void *d) {
 static thread_return_t THREAD_CALLING_CONV asan_thread_start(void *arg) {
   AsanThread *t = (AsanThread *)arg;
   SetCurrentThread(t);
-  return t->ThreadStart(GetTid(), /* signal_thread_is_registered */ nullptr);
+  return t->ThreadStart(GetTid());
 }