Sverre Rabbelier wrote:
> On Sat, Oct 2, 2010 at 10:41, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
>> 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
}
--
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