Issues with ASAN in Windows 10 Ubuntu subsystem

[ztdwu]

The output of a C++ program built with -fsanitize=address in the new Windows 10 Ubuntu subsystem:

==6089==Sanitizer CHECK failed: /build/llvm-toolchain-3.8-mC_dbv/llvm-toolchain-3.8-3.8/projects/compiler-rt/lib/sanitizer_common/sanitizer_procmaps_linux.cc:57 ((IsOneOf(*current_, 's', 'p'))) != (0) (0, 0)

The program:

int main() { }

Tested with gcc4.8, gcc5, gcc6, clang3.7, clang3.8

[kcc]

Ouch. I am sorry for that.
You are the first asan user I know who cares about the "Windows 10 Ubuntu subsystem".
This particular assertion tells us that procmaps on Windows10/Ubuntu are not as good as on the real Ubuntu.

[kasper93]

Some information about the issue. ASAN expects procmaps to be formatted as follows
08048000-08056000 r-xp 00000000 03:0c 64593 /foo/bar
It fails on the last char of permissions part. It expects either s or p. On Windows information whether mapping is shared or private is not available and - is shown instead, which triggers assert here https://github.com/llvm-mirror/compiler-rt/blob/74c8f498fa128f0cd4eb97d603c017f250dd3694/lib/sanitizer_common/sanitizer_procmaps_linux.cc#L59

Example of output on Windows:

$ cat /proc/self/maps
00400000-0040c000 r-x- 00000000 00:00 7623                       /bin/cat
0060b000-0060c000 r--- 0000b000 00:00 7623                       /bin/cat
0060c000-0060d000 rw-- 0000c000 00:00 7623                       /bin/cat
00bcb000-00bec000 rw-- 00000000 00:00 0                          [heap]
7f1976a30000-7f1976bef000 r-x- 00000000 00:00 202985             /lib/x86_64-linux-gnu/libc-2.23.so
7f1976bef000-7f1976bf8000 ---- 001bf000 00:00 202985             /lib/x86_64-linux-gnu/libc-2.23.so
7f1976bf8000-7f1976def000 ---- 00000000 00:00 0
7f1976def000-7f1976df3000 r--- 001bf000 00:00 202985             /lib/x86_64-linux-gnu/libc-2.23.so
7f1976df3000-7f1976df5000 rw-- 001c3000 00:00 202985             /lib/x86_64-linux-gnu/libc-2.23.so
7f1976df5000-7f1976df9000 rw-- 00000000 00:00 0
7f1976e00000-7f1976e26000 r-x- 00000000 00:00 203030             /lib/x86_64-linux-gnu/ld-2.23.so
7f1977000000-7f1977022000 rw-- 00000000 00:00 0
7f1977025000-7f1977026000 r--- 00025000 00:00 203030             /lib/x86_64-linux-gnu/ld-2.23.so
7f1977026000-7f1977027000 rw-- 00026000 00:00 203030             /lib/x86_64-linux-gnu/ld-2.23.so
7f1977027000-7f1977028000 rw-- 00000000 00:00 0
7f1977028000-7f19771c0000 r--- 00000000 00:00 22408              /usr/lib/locale/locale-archive
7f19771c0000-7f19771c1000 rw-- 00000000 00:00 0
7f19771d0000-7f19771d1000 rw-- 00000000 00:00 0
7f19771e0000-7f19771e1000 rw-- 00000000 00:00 0
7f19771f0000-7f19771f2000 rw-- 00000000 00:00 0
7ffffe41e000-7ffffec1e000 rw-- 00000000 00:00 0                  [stack]
7fffff2d8000-7fffff2d9000 r-x- 00000000 00:00 0                  [vdso]

[kcc]

The problem seems pretty minor and we could accept a patch, but we have no way to test it :(

[eugenis]

We can totally test it. Just give MemoryMappingLayout a test-only constructor that accepts a text buffer, and pass a saved copy of /proc/self/maps from Windows.

…

On Thu, Apr 20, 2017 at 4:31 PM, Kostya Serebryany ***@***.*** > wrote: The problem seems pretty minor and we could accept, but we have no way to test it :( — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#708 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZuShwhpvY6je69uWUAN3lCUJk2cbI3ks5rx-rmgaJpZM4JeKvn> .

[kasper93]

Not worth until they fix performance issues with large memory mappings. It is just so slow that I can't even run empty main, because it takes forever to init everything. I left it for an hour and it was still in asan init code. ASAN maps 20TB and it kills current WSL. See microsoft/WSL#1671 which seems to be the same issue with large mmap.

[kcc]

performance issues with large memory mappings

Sounds like the same problem that we have with native asan-on-windows, where we can't mmap the shadow properly and instead need to mmap it partially in SEGV handler. This sucks utterly. @rnk FYI

[rnk]

Makes sense. I think we need to investigate how control flow guard maps massive amounts of virtual memory efficiently.

I agree with @kcc, if your app is portable, for now you'll get better mileage running it natively on Windows or Linux, and not using the Windows subsystem for Linux.

[MikeGitb]

Just wanted to drop by to say that I'm also very interested in running thread sanitizer on WSL. But from the comments it sounds as if there is not a lot you can do about it.

[retep998]

@kcc How exactly is the memory being mapped in the native windows version? Are you memory mapping an actual file, are you creating a shared mapping to be shared with other processes, or are you just allocating virtual memory? If it is the third option, then the efficient option is to use VirtualAlloc. According to some local benchmarks, reserving 16TB of address space with VirtualAlloc only takes 10 milliseconds.

[rnk]

@retep998 Yes, we use VirtualAlloc to reserve 1/8 the address space. However, if we try to commit that much address space, the kernel usually returns an error. Instead, on Windows, we effectively do our own page fault handling for shadow memory with a vectored exception handler.

I suspect that the Windows subsystem for Linux will also fail or perform poorly if you ask it to mmap 1/8 the address space.

[WSLUser]

@kcc @rnk See Release Notes You "may" be able to further increase interop and performance now. Also see WSL/121

[WSLUser]

ASAN should work now as of Insider build 17093, see above link for Release Notes and WSL issue for more details. If there are any failings, perform an strace and provide in WSL/121 as linked above.

@rnk @kcc

we effectively do our own page fault handling for shadow memory with a vectored exception handler

With AF_Unix on Windows and now has interop with WSL, are you able to take advantage of this capability to change your current page fault handling configuration? If so, I'd recommend making the change but still make the current implementation available in case it proves too buggy until there's more support in AF_Unix for Windows.

Also, since we're mentioning performance, the Meltdown fix has slowed it down to a noticeable point (but not noticeable enough for normal users), (it was significantly faster after the release that came out at the time my post above was made).

[WSLUser]

Confirmed as fixed as of 17093 by another person so this can be marked closed.

[morehouse]

Sounds fixed. Please re-open if not.