User Details
- User Since
- Jan 5 2021, 2:49 PM (108 w, 6 d)
Wed, Feb 1
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>
Dec 7 2022
@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.
Jul 16 2022
Apr 23 2022
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.
Apr 10 2022
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.
Apr 9 2022
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
Feb 20 2022
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
Jan 13 2022
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?
Jan 7 2022
All the lsan tests, when run in lsan+asan mode, Deadlock in StopTheWord when creating the tracer thread...
-> check-lsan gets stuck, due to all the deadlocking tests :(
@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.
Dec 24 2021
@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?
Dec 23 2021
@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
Dec 22 2021
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
Dec 18 2021
Fix continue in loop.
Thanks @mstorsjo!
Fix warning
Dec 17 2021
@mstorsjo probably my only option is to silence the warning locally?
Simplify Architecture checks
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.
Dec 16 2021
Dec 14 2021
Disable SegvInCallback test on Windows
Dec 12 2021
Implement ProcessGlobalRegions
Fix Interceptors for Windows
Dec 11 2021
Dec 10 2021
Dec 8 2021
Add error handling
Dec 7 2021
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:
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?
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
Dec 6 2021
Remove wrong interceptors
Dec 4 2021
Use LF line endings
Apply clang-format
Move __lsan_init call inside of SANITIZER_WINDOWS ifdef
Changed to core.autocrlf=false
Jan 23 2021
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()); }