From: Jonathan Nieder <jrnieder@gmail.com>
Date: Sat, 02 Oct 2010 16:43:25 GMT
Subject: Re: [PATCH 2/7] lockfile: introduce alloc_lock_file() to avoid valgrind noise
Message-ID: <20101002164325.GA19675@burratino>
In-Reply-To: <4CA75E21.1090407@op5.se>

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.