Re: leaky cherry-pick
- From
Jeff King <peff@peff.net>
- Date
- Jan 11, 2012, 19:56 UTC
- Message-ID
- <20120111195605.GB12333@sigill.intra.peff.net>
- In-Reply-To
- <CALkWK0m+okqJk05BMQAEMww6FNLxaLVhAM92WmUDeA_J-drOdg@mail.gmail.com>
On Wed, Jan 11, 2012 at 02:30:16PM +0530, Ramkumar Ramachandra wrote:
Show 10 quoted lines
> > 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