[PATCH] [lsan] Support ASan's stack-use-after-return mode in LSan.

Kostya Serebryany kcc at google.com
Mon Oct 14 06:36:00 PDT 2013



================
Comment at: lib/asan/asan_fake_stack.h:151
@@ -150,1 +150,3 @@
 
+  void ForEachFakeFrame(RangeIteratorCallback callback, void *arg);
+
----------------
Sergey Matveev wrote:
> Kostya Serebryany wrote:
> > maybe ForEachExtraRootChunk or similar? 
> > I don't like the ide of exposing the name "FakeFrame" in the interface that has nothing to do with fake frames 
> > 
> I share this sentiment. Unfortunately, the way we use this function already assumes that it deals with stack (i.e. we call it under "if (flags()->use_stack)", and log the range as a stack range). Perhaps ForEachExtraStackRange?
ForEachExtraStackRange --- SGTM

================
Comment at: lib/asan/asan_fake_stack.cc:146
@@ +145,3 @@
+      uptr begin = reinterpret_cast<uptr>(ff);
+      callback(begin, begin + FakeStack::BytesInSizeClass(class_id), arg);
+    }
----------------
Sergey Matveev wrote:
> Kostya Serebryany wrote:
> > Sergey Matveev wrote:
> > > Some frames might be pending garbage collection. I wonder if it would be safe to filter them out based on the stack pointer value that we have from ptrace? (I.e. the same way as in FakeStack::GC() above.)
> > Can we just call GC here? 
> > (this could be done separately)
> We can. What I'm wondering is whether it would be safe to pass the SP value as the real_stack parameter (or whether this could go wrong if we froze the threads at an unfortunate point).
OTOMH I can't see how it will break things... But this part is indeed tricky, let's not touch it for now. 


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



More information about the llvm-commits mailing list