Re: [PATCH v2 0/6] reroll ma/plugleaks; more `object_array`-fixes

From: Jeff King <peff@peff.net>
Date: Sep 23, 2017, 16:13 UTC
Message-ID: <20170923161316.yntnccqrhv5d3jza@sigill.intra.peff.net>
In-Reply-To: <CAN0heSrPBDi4q9fqr=qoTbjRHpFS_VEL0O8=MFFJ4DLCuJwahA@mail.gmail.com>

On Sat, Sep 23, 2017 at 11:54:31AM +0200, Martin Ågren wrote:

Show 16 quoted lines

> Unfortunately, I have not figured out how to get LSan to simply report
> the leaks and continue. Its default behavior is to abort if there are
> leaks. That's useful for finding the first leaking test, but not much
> else. (Later tests might depend on that test doing everything it should,
> so now those later tests will start failing and/or executing different
> code paths.)
> 
> I can tell LeakSanitizer to exit with an exit code instead, but then all
> leaking git-processes exit with the same exit code. That also interferes
> with the tests.
> 
> What I would like is for the git-process to exit with the same exit
> status it would have had without the leak-checking. That would make it
> possible to run the whole test suite, collect all leaks, identify
> duplicates, sort them, categorize them, prioritize them, track how we
> are progressing...

Doesn't:

  LSAN_OPTIONS=abort_on_error=0:exitcode=0

do what you want? I get:

  $ export LSAN_OPTIONS=abort_on_error=0:exitcode=0

  [no leaks, no error]
  $ ./git rev-parse HEAD; echo $?
  0

  [no leaks, error]
  $ ./git rev-parse broken; echo $?
  ...
  128

  [leaks, no error]
  $ ./git --no-pager show; echo $?
  ...
  SUMMARY: LeakSanitizer: 40 byte(s) leaked in 4 allocation(s).
  0

  [leaks, error]
  $ ./git --no-pager show broken; echo $?
  ...
  SUMMARY: LeakSanitizer: 35 byte(s) leaked in 3 allocation(s).
  128

In theory you should be able to just add "log_path=/tmp/lsan/output" to that, which should put all the logs in a convenient place (and stop the extra output from confusing any tests which capture stderr). But I can't seem to get log_path to do anything, contrary to the documentation.

Doing log_to_syslog=1 does work for me. I'm not sure if it's a bug or I'm holding it wrong. But it does seem like it should be possible to do what you want.

-Peff