Re: [PATCH 7/7] commit-tree: free commit message before exiting

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Oct 2, 2010, 18:26 UTC
Message-ID: <20101002182600.GB24523@burratino>
In-Reply-To: <AANLkTikZ5cn8biMvMPzXz6U2J=3yg1KJXayHD-7Cx8Me@mail.gmail.com>

Sverre Rabbelier wrote:

> On Sat, Oct 2, 2010 at 10:41, Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 8 quoted lines

>> That's the end of the series.  Thanks for reading.
>
> Thanks, I've used git under valgrind a couple of times and always had
> to resort to running 'regular' git, looking at what valgrind reports
> for it, and then running my modified git, and try to make sure that I
> didn't introduce any new leaks. How does the current valgrind output
> look like, are we close to being leak free, or is this just a drop in
> (or perhaps out of :P) the bucket?

It is a drop in the bucket. With some extra suppressions[1], I am only able to run t0000 through valgrind.

Probably this series should cook outside mainline until the test suite runs without reporting any unsuppressed leaks. I still would be interested in more comments on the approach, though. If KEEP_WRAPPER were conditionally defined to be empty (so by default people _would_ find the tail calls in those sentinel functions eliminated --- i.e., no performance impact unless you ask for it), would that be more acceptable?

[1]
 {
	cache entry leak
	Memcheck:Leak
	fun:calloc
	fun:xcalloc
	fun:add_one_path
 }
 {
	cache entry leak 2
	Memcheck:Leak
	fun:calloc
	fun:xcalloc
	fun:unpack_callback
 }
 {
	nobody seems to free tree buffers
	Memcheck:Leak
	fun:malloc
	fun:xmalloc
	fun:xmallocz
	fun:unpack_sha1_file
	fun:read_object
	fun:read_sha1_file_repl
	fun:parse_object
	fun:parse_tree_indirect
 }
 {
	really, nobody seems to free tree buffers
	Memcheck:Leak
	fun:malloc
	fun:xmalloc
	fun:xmallocz
	fun:unpack_sha1_file
	fun:read_object
	fun:read_sha1_file_repl
	fun:parse_tree
 }