Re: git rev-list | git cherry-pick --stdin is leaky

[Stephen Boyd <sboyd@codeaurora.org>]

On 05/09/13 08:10, René Scharfe wrote:
> Am 06.05.2013 22:16, schrieb Stephen Boyd:
>> Ok. I tested it and it definitely helps.
>>
>> ==10728== LEAK SUMMARY:
>> ==10728==    definitely lost: 316,355,458 bytes in 8,652 blocks
>> ==10728==    indirectly lost: 1,327,251,588 bytes in 16,180,628 blocks
>> ==10728==      possibly lost: 677,049,918 bytes in 7,381,801 blocks
>> ==10728==    still reachable: 9,238,039 bytes in 63,947 blocks
>> ==10728==         suppressed: 0 bytes in 0 blocks
>>
>> vs.
>>
>> ==27614== LEAK SUMMARY:
>> ==27614==    definitely lost: 2,369,692,222 bytes in 20,005,707 blocks
>> ==27614==    indirectly lost: 829,151,786 bytes in 9,594,715 blocks
>> ==27614==      possibly lost: 658,069,373 bytes in 6,345,172 blocks
>> ==27614==    still reachable: 8,806,386 bytes in 50,199 blocks
>> ==27614==         suppressed: 0 bytes in 0 blocks
>
> Thanks, Stephen.  I'm going to prepare a series around that patch
> which will (hopefully) show that freeing these entries is safe by
> passing only const pointers down to the callbacks.  It's too late for
> 1.8.3, of course, but it shouldn't take another year as most of that
> series is done already. :)

Yes I started trying to throw const around everywhere but then I just
sent out the email in hopes someone had already solved this problem.

>
> We still have an impressive amount of leakage here.  I wonder why
> "indirectly lost" increased so much.  Do you perhaps still have the
> full output of valgrind for the run with the patch applied?

I think it increased because the first one ran to completion while the
second one failed half way through so it's not an apples to apples
comparison. I can re-run with a certain range that is known not to fail
if you're interested, but I think you got the idea that the patch helps.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation