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

["René Scharfe" <rene.scharfe@lsrfire.ath.cx>]

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. :)

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?

Thanks,
René