@poljak181 I'm no longer on the ASan team at Microsoft so I can't really comment on where things stand. The last thing I saw was that we were still running into issues where Rtl* functions were getting called during process teardown. The RAII lock destructors wouldn't get called before teardown so locks would be held by threads that no longer existed and then we would deadlock. Windows gets around this with the Heap locks by walking through all existing heaps on teardown and essentially unlocking all of the locks before proceeding to call Rtl* functions. I had proposed hooking the function that does that in order to effectively do the same thing with the ASan internal locks but I don't know if it was ever implemented. @stwish_msft

Imo I agree that this shouldn’t be merged until the debug variants of the asan runtime are getting built publicly.

Hi Javier,

I've followed up with people more knowledgeable than myself. The unknown leading bytes in the padding region are XFG hashes and can be safely overwritten as long as XFG is not enabled for the process. (XFG is an eXtension of CFG, control flow guard)
I can't imagine many people will have both ASan and XFG enabled at the same time so I think the interception logic should just always assume there is padding before Windows OS functions.

Note that we should get in contact with the Windows maintainers about this. Windows OS dlls are built with /HOTPATCH and should all be hotpatchable. It's unclear what the leading junk in the hotpatch padding is.

Hi Reid,

Hi Daniel,

Looks like I found the problem. It's pretty dumb :( . The issue is that at
the top of RtlDestroyHeap I destroy the instance of the AsanHeap associated
with the HeapHandle but anywhere that calls GetAsanHeap will just recreate
it, leading to the race condition. This is a pretty easy fix but I'm kind
of backlogged and won't be able to get something in for the next couple of
weeks.

Hi Javier,

Hi Javier,

Fixup headers.

Fixups

It can be found here. It was based loosely off of the old libcxx test format. I'm probably going to submit a pretty significant re-working of it and/or see if I can adapt the new format to our needs whenever I have a free minute.

Yes, we have a custom test format which considers the configured target architecture and the set of flags the test will be compiled with.