author | Linus Torvalds <torvalds@linux-foundation.org> | |
Fri, 7 Mar 2008 21:48:40 +0000 (13:48 -0800) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Sun, 9 Mar 2008 09:03:45 +0000 (01:03 -0800) | ||
commit | 1caeacc1f2973cecf7919a141adc4759acae94d0 | |
tree | 0f06940126d686e7270c3f21c2dfcc9d1357fcc0 | tree | snapshot |
parent | 34110cd4e394e3f92c01a4709689b384c34645d8 | commit | diff |
unpack_trees(): minor memory leak fix in unused destination index
This adds a "discard_index(&o->result)" to the failure path, to reclaim
memory from an in-core index we built but ended up not using.
The *big* memory leak comes from the fact that we leak the cache_entry
things left and right. That's a very traditional and deliberate 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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds a "discard_index(&o->result)" to the failure path, to reclaim
memory from an in-core index we built but ended up not using.
The *big* memory leak comes from the fact that we leak the cache_entry
things left and right. That's a very traditional and deliberate 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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
unpack-trees.c | diff | blob | history |