[PATCH] [asan] Fix a deadlock between asan's allocator and lsan

[Alexey Samsonov]

================
Comment at: lib/sanitizer_common/sanitizer_allocator.h:1310
@@ +1309,3 @@
+  void AssertLockHeld() {
+    secondary_.AssertLockHeld();
+  }
----------------
Kostya Serebryany wrote:
> Alexey Samsonov wrote:
> > The absence of "primary_.AssertLockHeld()" kind of breaks the pattern. Maybe we should implement it as "return true;" for lock-free allocators?
> dunno. OTOH  primary_.AssertLockHeld() may confuse because the reader will assume there is a lock.
But we have non-trivial ForceLock() implementations in primary allocators, that lock a bunch of mutexes. If checking that each of these mutexes is locked is too slow, we may add a bool flag, set/unset it in ForceLock/ForceUnlock and check it in AssertLockHeld.

================
Comment at: lib/asan/asan_allocator2.cc:219
@@ -218,1 +218,3 @@
   }
+  // Must be called when holding the allocator lock.
+  void *AllocBegLocked() {
----------------
Kostya Serebryany wrote:
> Alexey Samsonov wrote:
> > Why not make "Locked" a parameter (m.b. with default value =false) of AllocBeg(), UsedSize(), AddrIsInside() instead of duplicating code? I think inlining will help us to avoid slowdown.
> These are actually a bit different.
> allocator.GetBlockBeginFastLocked is a completely different code than allocator.GetBlockBegin
The implementation of locked/normal functions may be different, but they have common interface. I don't see difference between AllocBegLocked and AllocBeg functions except that they call different methods (GetBlockBegin and GetBlockBeginFastLocked) of the allocator. Same for UsedSize and AddrIsInside.


http://llvm-reviews.chandlerc.com/D1957