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é -- 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