[PATCH] [LSan] Common leak checking module.

[Sergey Matveev]

================
Comment at: lib/lsan/lsan_common.cc:266
@@ +265,3 @@
+static void PrintLeaked() {
+  Printf("\nReporting individual blocks:\n");
+  ForEachChunk(PrintLeakedCb());
----------------
Evgeniy Stepanov wrote:
> Why would anyone want this? Debugging the tool itself?
>From http://google-perftools.googlecode.com/svn/trunk/doc/heap_checker.html

> Sometimes it can be useful to not only know the exact code that allocates the leaked objects, but also the addresses of the leaked objects. Combining this e.g. with additional logging in the program one can then track which subset of the allocations made at a certain spot in the code are leaked. 

I implemented it mostly for the sake of feature parity, but I can see how it can be useful in some cases.

================
Comment at: lib/lsan/lsan_common.cc:337
@@ +336,3 @@
+  bool is_directly_leaked = (tag == TAG_DIRECTLY_LEAKED);
+  for (uptr i = 0; i < leaks_.size(); i++)
+    if (leaks_[i].stack_trace_id == stack_trace_id &&
----------------
Evgeniy Stepanov wrote:
> N^2? What if I leak a single tree with 1 million nodes?
We're fine as long as they don't have 1 million distinct stack traces.

I'll put a fixme in the code to replace this with a hashmap when we have one implemented.

================
Comment at: lib/lsan/lsan_common.cc:355
@@ +354,3 @@
+    Printf("\nThe %llu largest leaks:\n", max_leaks);
+  InternalSort(&leaks_, leaks_.size(), IsLarger);
+  max_leaks = max_leaks > 0 ? Min(max_leaks, leaks_.size()) : leaks_.size();
----------------
Evgeniy Stepanov wrote:
> N largest can be found much more efficiently than a full sort.
leaks_.size() is the number of distinct stack traces corresponding to leaked blocks. It's typically very small.

================
Comment at: lib/lsan/lsan_common_linux.cc:37
@@ +36,3 @@
+  internal_memset(linker_placeholder, 0, sizeof(linker_placeholder));
+  uptr linker_found = GetListOfModules(
+      reinterpret_cast<LoadedModule *>(linker_placeholder), 1, IsLinker);
----------------
Evgeniy Stepanov wrote:
> Not a very good name. Should be something with "find" or "filter" in it.
Keeping this name as per offline discussion.


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