On 02/27/2012 04:40 PM, Peter Hutterer wrote:
The test case was: valgrind --leak-check=full --show-reachable=yes Xvfb forcing two server regenerations by running xterm against it 3 times. Before: ==31654== LEAK SUMMARY: ==31654== definitely lost: 3,720 bytes in 11 blocks ==31654== indirectly lost: 287,964 bytes in 2,273 blocks ==31654== possibly lost: 0 bytes in 0 blocks ==31654== still reachable: 136,104 bytes in 1,733 blocks ==31654== suppressed: 0 bytes in 0 blocks After: ==13190== LEAK SUMMARY: ==13190== definitely lost: 960 bytes in 8 blocks ==13190== indirectly lost: 123,552 bytes in 572 blocks ==13190== possibly lost: 0 bytes in 0 blocks ==13190== still reachable: 27,724 bytes in 77 blocks ==13190== suppressed: 0 bytes in 0 blocks The majority of the indirectly lost are in glx, but afaict they are false positives: ==13190== 61,344 bytes in 284 blocks are indirectly lost in loss record 52 of 54 ==13190== at 0x4A074CD: malloc (vg_replace_malloc.c:236) ==13190== by 0x4E1478: createModeFromConfig (glxdricommon.c:131) ==13190== by 0x4E16B1: glxConvertConfigs (glxdricommon.c:187) ==13190== by 0x4E12D7: __glXDRIscreenProbe (glxdriswrast.c:472) ==13190== by 0x4E0220: GlxExtensionInit (glxext.c:328) ==13190== by 0x41CA14: InitExtensions (miinitext.c:471) ==13190== by 0x5ACBC8: main (main.c:208)
I understand enough to review the following without diving in further than I'm able right now: 1, 2, 4, 7. For those:
Reviewed-by: Chase Douglas <[email protected]> _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
