On Wed, Jan 11, 2012 at 02:30:16PM +0530, Ramkumar Ramachandra wrote: > > I somehow have a feeling that you did not read the conclusion in Peff's > > message correctly. The code only keeps data from one active path of > > per-directory .gitattributes files to the leaf of a working tree and > > releases unneeded data (IOW, it "pops" the attr_stack elements) when it > > goes on to look at the next path, so my understanding is that there is > > nothing to "try implementing" here. > > My bad- I thought the current implementation doesn't release the > unneeded data. So, does the entire 7 KB of leaked data come from one > active path? Hmm. Actually, I think there is a leak. Because the strategy I described leaves the memory reachable from the global attr_stack variable, which means valgrind will only show it if "--show-reachable" is turned on. Maybe this? diff --git a/attr.c b/attr.c index 76b079f..1656db4 100644 --- a/attr.c +++ b/attr.c @@ -301,6 +301,7 @@ static void free_attr_elem(struct attr_stack *e) } free(a); } + free(e->attrs); free(e); } -Peff -- 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