This seems to be caused by updating my machine to the latest Windows 10 Pro, version 1703. I was previously running 1607 without any issues.

Tried this locally with the build from taskcluster but substituting my own-built clang_rt_asan_dynamic_x86_64 so that I can resolve symbols. The asan runtime is asserting at 00 clang_rt_asan_dynamic_x86_64!__interception::InterceptionFailed 01 clang_rt_asan_dynamic_x86_64!__interception::GetInstructionSize 02 clang_rt_asan_dynamic_x86_64!__interception::OverrideFunctionWithHotPatch 03 clang_rt_asan_dynamic_x86_64!__interception::OverrideFunction 04 clang_rt_asan_dynamic_x86_64!__interception::OverrideFunction 05 clang_rt_asan_dynamic_x86_64!InitializeCommonInterceptors Its disassembler falls over on ucrtbase!strnlen which in Win10 build 1703 looks like: 00007ffc`5a334a10 8b052a0a0c00 mov eax,dword ptr [ucrtbase!_isa_available (00007ffc`5a3f5440)] 00007ffc`5a334a16 4c8bc9 mov r9,rcx 00007ffc`5a334a19 83f805 cmp eax,5 00007ffc`5a334a1c 0f8c91000000 jl ucrtbase!strnlen+0xa3 (00007ffc`5a334ab3) This will need an LLVM bug and a patch to https://github.com/llvm-mirror/compiler-rt/blob/master/lib/interception/interception_win.cc#L404

Actually, I'm not sure if their setup gracefully handles the relocation of IP-relative addresses...

So there's this `rel_offset` variable that will take care of the relative addresses, but there's another problem. When hooking an API, the interceptors go through a list of `InterestingDLLsAvailable()` and patch any function with a matching name, but in build 1703, ucrtbase!strnlen and ntdll!strnlen are distinct functions. ASan ends up detouring them both to the same place, meaning they both use the same return pointer at `__interception::real_strnlen`, which causes problems.

(For anyone curious, the distinction is that ntdll!strnlen is a straightforward "dumb" implementation, while ucrtbase!strnlen will use SSE if available.)

With the patch at https://bugs.llvm.org/show_bug.cgi?id=32895#c2, I was able to get around this. But I then hit an unrelated crash in ICU/strlen, for which I filed bug 1373763.

Hey any updates?

Sorry, I completely lost track of this bug. I just tried a build and it still crashes, in a new way. I'd like to get bug 1412952 landed before investigating further just so I'm not chasing a moving target.

This is a pain to debug without bug 1360650, which is stalled waiting on review. I'll try to get some movement there.

Let's check back when the blocking bugs are resolved.

(In reply to David Major [:dmajor] from comment #10) > Let's check back when the blocking bugs are resolved. Should be good now. Want to give it a try?

(In reply to David Major [:dmajor] from comment #11) > Should be good now. Want to give it a try? TC builds are still out of date and I don't have a Windows environment setup to build this atm. https://public-artifacts.taskcluster.net/TwR5llu2QzOugZi7D_xTLw/0/public/build/target.txt 20170722021023 If there are builds available somewhere I'd be happy to give them a try.

It works! Thank you.