Re: leaky cherry-pick

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 10, 2012 at 5:37 AM, Pete Wyckoff <pw@xxxxxxxx> wrote:
> I've got a big tree, and rebased 200 commits today using
> cherry-pick.  It ran out of memory.  Both 1.7.4 and recent
> master (eac2d83 (Git 1.7.9-rc0, 2012-01-06)) behave similarly.
>
> Here's a valgrind dump for rebasing just 9 commits, if someone is
> interested to track this down.  This was invoked as:
>
>    valgrind --log-file=/tmp/vg.out --leak-check=full \
>    /home/pw/src/git/git cherry-pick 8d535b6^..2cf53a0
>
> I can re-test if you like, or provide more detail if this seems
> unusual.
>
> Scroll to the end to see the biggest leaks.

Index entries are leaked since probably forever because we allocated
entries in bulk and could not release them individually, until debed2a
(read-cache.c: allocate index entries individually). Putting
discard_index() to read_and_refresh_cache() might help, I think.
-- 
Duy
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]