On Fri, 7 Mar 2008, Daniel Barkalow wrote:
>
> It looks to me like it's leaking stuff stored in the index it creates if
> it ends up failing.
Yes, adding a "discard_index(&o->result)" to the failure path sounds like
a good idea. Patch appended.
> I'm not entirely sure of the index lifecycle stuff,
> but it seems like it would be necessary.
Well, "necessary" may not be the right word, because it's a purely
internal index thing, so all that happens is a memory leak. But it's
certainly easy to do and correct.
That said, the *big* memory leak comes from the fact that we leak the
cache_entry things left and right. That's a very traditional leak: because
we used to build up the cache entries by just mapping them directly in
from the index file (and we emulate that in modern times by allocating
them from one big array), we can't actually free them one-by-one.
So doing the "discard_index()" will free the hash tables etc, which is
good, and it will free the "istate->alloc" but that is never set on the
result because we don't get the result from the index read. So we don't
actually free the individual cache entries themselves that got created
from the trees.
That's not something new, btw. We never did. But some day we should just
add a flag to the cache_entry() that it's a "free one by one" kind, and
then we could/should do it. In the meantime, this one-liner will fix
*some* of the memory leaks, but not that old traditional one.
Linus
---
unpack-trees.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 0cdf198..da68557 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -315,6 +315,7 @@ static int unpack_callback(int n, unsigned long mask, unsigned long dirmask, str
static int unpack_failed(struct unpack_trees_options *o, const char *message)
{
+ discard_index(&o->result);
if (!o->gently) {
if (message)
return error(message);
--
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
