[PATCH] D35173: [lsan] Add _os_trace into LSan's suppression list

[Kuba (Brecka) Mracek via Phabricator via llvm-commits]

kubamracek added inline comments.


================
Comment at: compiler-rt/trunk/lib/lsan/lsan_common.cc:81
+  // For Darwin and os_log/os_trace.
+  "leak:*_os_trace*\n";
 
----------------
kubamracek wrote:
> alekseyshl wrote:
> > Minor, but I'd love to know a bit more of the context (is it a bug in some versions or design decision, is it going to be fixed or we're stuck with it forever etc.) and add #if SANITIZER_MAC around it?
> Oh, I'm sorry for not explaning more, I only to talked to @fjricci (who's the primary person for LSan on Darwin) in a private email about this.
> 
> I'm seeing multiple test failures in ASan tests, all of which are due to this LSan false positive.  It only affects 10.12 systems, because it's specific to the new "unified logging" mechanism on 10.12, but the leak is only reported in specific versions of the OS.  This is not a "real" solution, and I believe @fjricci is going to investigate if there's a better way of handling this.  But since I'm having multiple test failures (not on public bots, though, they are all on 10.11), I wanted to land a "fix" even if means using the suppression list.
> 
> Here's some details about the problem:
> > Hi, these seem to be because again, some pointer(s) to a heap block is stored
> > in an unusal mmap'd piece of memory.  This time, it's the "voucher" and
> > "firehose" features of xnu/libdispatch that support the new unified logging
> > mechanism on 10.12+.  I think they interoperate with the kernel in a way that
> > the kernel maps a piece of memory and hands it over to libdispatch, which then
> > uses it to store some data, including a pointer to this heap block.
> 
> I will add a `#if SANITIZER_MAC`.
Added the #if in r307567.


Repository:
  rL LLVM

https://reviews.llvm.org/D35173