-
Notifications
You must be signed in to change notification settings - Fork 838
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ASAN doesn't work #121
Comments
Thanks for reporting this. Could you grab a strace here to figure out what part is failing? |
Looks related to #120.
It keeps reading |
Entry for same bug in asan bug tracker: google/sanitizers#708 Still occurs on Windows 14393.105 |
Some information about the issue. ASAN expects procmaps to be formatted as follows Can we expect this to be fixed? Seems like not a big bug to fix. Mapping need to be either private or shared so showing Example of output on Windows:
|
I changed ASAN to accept Window's proc maps format. But it is still unusable. ASAN maps 20TB of virtual memory and it kills WSL. It is so slow that asan init code takes hours. Probably the same issue as #1671 |
Would be great, if we could run ASAN (and the other sanitizers) on WSL. |
Using 16299 it seems to get further now. My code
Using the following command-line
Reports this
The strange output: Seems like the interesting part
The same issue seems to apply using MemorySanitizer with clang:
Using
Both of these return immediately. The problem with the long start-up because of mapping memory still seems to happen when using ThreadSanitizer (GCC and clang) though. Using
Or
|
Looking into this a bit, the behavior of mmap for large regions with MAP_NORESERVE is somewhat odd. This code fails on my system with
As far as I can tell the memory mapped is completely usable after mprotect; it might be a reasonable workaround for asan even though it takes close to a minute to start up. This is on Windows 10 build 16299.19 |
Hey all - suggestion from one of our devs: For the memory issue, try setting And do let us know if this helps! /cc @MikeGitb |
@bitcrazed Thanks! This fixes the mmap error and lets me run asan. At the end of the run (at least with my test program) I get this output: "LeakSanitizer has encountered a fatal error", but that's at exit so it's not as pressing. A more significant issue now that asan startup is unblocked is performance; for my test program, ASAN run takes 19m30s and non-ASAN run takes 150ms. Valgrind run of a non-ASAN build takes 3 seconds. |
Curiously, most of the time seems to be spent reading /proc/self/maps, not doing actual mmap; attaching strace output. |
It's the mmap after the reading of /proc/self/maps for me - so MSAN and ASAN binaries now start up and behave like TSAN ones. I only tested it with GCC. |
Like I said few months ago, ASAN is affected by #1671 like many other tools that maps large amount of memory. Until that's fixed I doubt it will be usable. |
FYI. From issue #1671
This should significantly help sanitizers performance too. |
With build 17063, the performance issues with asan seem to have been resolved - I still need to set There's still one issue at the end of execution:
|
Running the program under strace (yeah I know the hint says "LeakSanitizer does not work under ptrace" :D) produces this syscall right before the fatal error:
Since errno 22 is EINVAL this might be the cause. |
They fixed issues with both CLONE and EINVAL in previous Insider builds. I would submit a ticket to the package developer and get their input on it. Edit: Unless something regressed due to the huge changes to 17063. |
This program does reproduce the behavior (printing -1 on WSL, and a non-negative id on regular Linux):
So I would guess that this is a WSL issue with clone. I will file a separate issue for this. |
I filed |
FYI I have to wait for it to hit the Slow Ring and will do so when it does. |
Using 17115 and my previous example now works
I also tested it with TSAN and MSAN as well as clang and well were fine. It was also fast in all cases without doing any changes to the system. So I think this can now be closed. This is truly a great achievement. |
Thanks. Calling this fixedinsiders 17093. |
LeakSanitizer still fails for me in 17115 (in any program compiled with asan); the problem used to be in clone() - now clone() succeeds but prctl call after it fails:
The actual program output from Hello, world compiled with -fsanitize=address is:
LeakSanitizer log:
|
I would recommend opening a new issue for the PR_SET_PTRACER problem. If you set /proc/sys/kernel/yama/ptrace_scope to 0 does it start working? Looks like it is also mentioned in #2258 but not as a blocker. |
Setting /proc/sys/kernel/yama/ptrace_scope to 0 works around the issue; I've filed #3053. |
Fixed in Insiders Build 17093 |
17134.81 and still not fixed as tara-raj claimed, but suggestion from zeux works. echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope This is using: gcc -fsanitize=address -g ./leaky.c && ./a.out Edit: @therealkenc I just said it is not fixed in 1803, still need workaround. The tag "fixedin1803" is untrue. |
must run |
Note that the ASAN printouts would have kept printing if I hadn't aborted with Ctrl-C.
The text was updated successfully, but these errors were encountered: