Re: [PATCH] commit-graph: fix memory leak

[Jeff King <peff@peff.net>]

On Tue, May 07, 2019 at 11:49:41AM +0200, Ævar Arnfjörð Bjarmason wrote:

> I wonder in general if there's a more sustainable solution to these
> one-at-a-time memory leak fixes we're doing to these
> libraries. E.g. marking some tests in the test suite as passing cleanly
> with valgrind's leak checker, and adding a test mode to run those tests.

I'd recommend going with the LeakSanitizer, since the resulting tests
run a lot faster.  We made some progress a while ago, and some tests do
pass, but there's a lot of manual inspection (and either fixing leaks,
or annotating with UNLEAK as appropriate) still to do.

Running "make SANITIZE=leak test" shows our current state.

If we just want to stop the bleeding, so to speak, I suspect that rather
than marking individual tests as "clean", we'd do better to collect all
of the results, sort and remove duplicates, and then just compare the
result before and after certain branches. That would tell us the new
leaks being added.

Something like:

  export LSAN_OPTIONS=exitcode=0:log_path=/tmp/lsan
  make SANITIZE=leak test

should dump a bunch of files in /tmp. (Note that when we tried this in
late 2017, log_path did not seem to work in pure-LSan mode, but I think
this was a bug; it works fine for me now).

Collating the results is a little tricky, because the top of the stack
when the leak was allocated is usually uninteresting (it's almost always
xmalloc).

There's some discussion and some scripts in:

  https://public-inbox.org/git/20170923163817.7ltmkav2ytk7n43k@sigill.intra.peff.net/

and

  https://public-inbox.org/git/20170925160835.aoomjaqrn2o2aosi@sigill.intra.peff.net/

I think just pumping the results of the second one through "sort -u"
would get you a starting point that you could use for before/after
diffs.

-Peff