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 -- 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