Andreas Ericsson wrote: > So we're basically increasing runtime to shut up a leakchecking tool > and also making that leakchecking tool falsely not report positives. Yep, nice summary. Probably I should have also mentioned: - An extra stack frame with no locals is not a lot of overhead, but in any case these are by design not in performance-critical places. - By using a special function like this, we make instances nicely grep-able and give the leak prominence in t/valgrind/default.supp. So a person can discover, for example, that writing a lot of trees in a single process (like cherry-pick -n foo..bar currently does) is going to be leaky. - valgrind would be most useful if it can be used to identify _regressions_ by running the test suite with --valgrind. git is deliberately leaky in a lot of places; it is not useful to record that. - valgrind does have the ability to turn suppressions off if you want. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html