Jeff King <peff@xxxxxxxx> writes: > I don't think that's true at all. The annotations you showed in that > message, for example, are pointing at add_rev_cmdline(). But that is > _not_ the source of the leak, nor where it should be fixed. It is a > necessary part of how rev_info works. The leak is when the rev_info goes > out of scope without anybody cleaning it up. True. >> Hrm, now that I think about it I think that the cases where I had to >> resort to valgrind to get around such crappy stacktraces (when that was >> all I got, even without suppressions) were probably all because there >> was an UNLEAK() in play... > > I don't see how UNLEAK() would impact stack traces. It should either > make something not-leaked-at-all (in which case LSan will no longer > mention it), or it does nothing (it throws some wasted memory into a > structure which is itself not leaked). I'd prefer to see judicious use of UNLEAK() over LSAN suppressions that lists things that are not the source of the problem. The list being kept in the tests that are far away from the actual source does not help, either. Thanks.
