Re: [PATCH] memory leak reported by valgrind

Junio C Hamano wrote:

Thanks, but doesn't it essentially sit at the end of main(), only for _exit(2)
to clean after us?

Right.  This is the case for many leaks reported by valgrind for git; it
is hard to separate the ones the matter.

Example: the lockfile records.  There are so few per process as not to
matter except for the sake of valgrind, and they cannot be removed
before exiting because the list they are inserted in is singly-linked.
I am cooking a patch to free them at exit optionally, somewhat like
Pierre’s leaky()[1].  Could something like leaky() be used to insert
an artificial stack frame at allocation time to make suppressions
simpler to write?

Well, that’s a separate story.  Here are a few run-of-the-mill leaks.

Jonathan Nieder (3):
  core: Stop leaking ondisk_cache_entrys
  write-tree: Avoid leak when index refers to an invalid object
  read-tree: stop leaking tree objects

 cache-tree.c   |    4 +++-
 read-cache.c   |    5 ++++-
 unpack-trees.c |    7 ++++++-
 3 files changed, 13 insertions(+), 3 deletions(-)

[1] http://thread.gmane.org/gmane.comp.version-control.git/86138