I'm pretty sure your example won't repro for me, but I'll check when I get into work. Ettiene has encountered the same crash stack when using newer dbghelp.dll versions. I want to do two things:

1. Write a test that deterministically reproduces these results across Windows installations
2. Study it to see if we can get asan to initialize earlier than ucrtbase.dll so we don't miss these allocations

If 2 fails, then we can start trying to handle missed allocations, but I want to convince myself that we can't initialize earlier before going down that road.

I agree that dealing with missed allocations is unfortunate, but I couldn't see any way around it. The allocation stack in comment 0 happens while the NT loader is traversing the dependency graph; ucrtbase.dll initializes before we even reach the entry point of clang_rt.asan_dynamic-i386.dll.

To run code any earlier would require either: (1) removing clang_rt.asan_dynamic-i386.dll's dependency on ucrtbase.dll, or (2) adding some new DLL that loads before clang_rt.asan_dynamic-i386.dll. Neither of those seem particularly great.

That said, if you can think of an option that I've overlooked, I'd be happy to hear it!

My asan runtime doesn't depend on ucrtbase.dll directly:

$ dumpbin -dependents lib/clang/4.0.0/lib/windows/clang_rt.asan_dynamic-x86_64.dll
...
Image has the following dependencies:

KERNEL32.dll
dbghelp.dll

...

But if dbghelp.dll does, then we have a problem. That's what Etienne is running into.

Ah, right. dbghelp depends on api-ms-win-crt-runtime-l1-1-0, which redirects to ucrtbase.

With /delayload:dbghelp.dll, the error messages went away.

I'm facing the exact same bug.

Some allocations are done by ucrt before dynamic hooking (malloc/free interception). Which lead to an error when a free of an unknown object is done.

This is a fix:
https://reviews.llvm.org/D25946

Can you guys apply https://reviews.llvm.org/D26473 and test if that fixes your issues?

I wonder if we need to worry the static ASan runtime, too. If we do, then I think we should use LoadLibrary so that users don't need to change their build to delay load dbghelp. Either that or maybe '#pragma comment(linker)' can solve it.

I wonder if we need to worry the static ASan runtime, too. If we do, then I
think we should use LoadLibrary so that users don't need to change their
build to delay load dbghelp. Either that or maybe '#pragma comment(linker)'
can solve it.

Answering my own question, the test I added failed with the static CRT, so the patch is no good as is.

With r286848 (and with my local patch reverted), I'm no longer getting any complaints from free(). Thanks for the fix!

Great, fixed in r286848.

We also discussed improving the "attempting free on address which was not malloc()-ed" report to indicate that the pointer comes from the system heap, and indicate that the user should try to debug why heap interception didn't work.

It's fixing the first occurrence of the bug.
But, when building chrome, there is other cases.

I'm gonna dig to see which dependency is present.

C:\src\chrome\src>ninja -C out\Asan64 chrome
ninja: Entering directory `out\Asan64'
[1/1] Regenerating ninja files
[16249/27244] ACTION //v8:run_mkpeephole(//build/toolchain/win:clang_x64)
FAILED: gen/v8/bytecode-peephole-table.cc
c:/src/depot_tools/python276_bin/python.exe ../../v8/tools/run.py ./mkpeephole gen/v8/bytecode-peephole-table.cc

==700==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x02bfa8ccf640 in thread T0
#​0 0x7ff69892cfd4 in free c:\src\llvm\src\projects\compiler-rt\lib\asan\asan_malloc_win.cc:45
#​1 0x7ffc665db7fb in qsort+0x46b (C:\Windows\System32\ucrtbase.dll+0x18000b7fb)
#​2 0x7ffc69167ec7 in RtlProcessFlsData+0x117 (C:\Windows\SYSTEM32\ntdll.dll+0x180007ec7)
#​3 0x7ffc69167fb5 in LdrShutdownProcess+0x95 (C:\Windows\SYSTEM32\ntdll.dll+0x180007fb5)
#​4 0x7ffc69167d93 in RtlExitUserProcess+0xb3 (C:\Windows\SYSTEM32\ntdll.dll+0x180007d93)
#​5 0x7ffc66d8ce69 in ExitProcess+0x9 (C:\Windows\System32\KERNEL32.DLL+0x18001ce69)
#​6 0x7ff69899aa07 in exit_or_terminate_process d:\th\minkernel\crts\ucrt\src\appcrt\startup\exit.cpp:129
#​7 0x7ff69899a9a3 in common_exit d:\th\minkernel\crts\ucrt\src\appcrt\startup\exit.cpp:269
#​8 0x7ff698951a36 in __scrt_common_main_seh f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:260
#​9 0x7ffc66d78363 in BaseThreadInitThunk+0x13 (C:\Windows\System32\KERNEL32.DLL+0x180008363)
#​10 0x7ffc691c5e90 in RtlUserThreadStart+0x20 (C:\Windows\SYSTEM32\ntdll.dll+0x180065e90)

Address 0x02bfa8ccf640 is a wild pointer.
SUMMARY: AddressSanitizer: bad-free c:\src\llvm\src\projects\compiler-rt\lib\asan\asan_malloc_win.cc:45 in free
==700==ABORTING
[16254/27244] CXX obj/v8/src/inspector/inspector/Debugger.obj
ninja: build stopped: subcommand failed.