Hi all,

In order to find memory leaks, some types of access violations, and the use of uninitialized variables I depend on valgrind. The problem is that valgrind is barely usable with Inkscape. The output on even the most minimal session (open, type a few letters, format them, close) runs to just under 500K lines and takes 5 minutes to complete. Some of this may be because garbage collection must be turned off in order to use valgrind. That is:

export _INKSCAPE_GC=disable; valgrind .... src/inkscape

There is no choice in that though, because if it is not done valgrind crashes when it tries to run inkscape. (Ubuntu 12.10.4, 32 bit, current Trunk). There is a libgc.supp in the top of the distribution, but it cannot be used on my system, since it does not suppress valgrind's crash when it tries to run inkscape with GC enabled.

Here is the damage seen on a normal exit for a minimal run:

==16527== LEAK SUMMARY: ==16527== definitely lost: 567,697 bytes in 17,670 blocks ==16527== indirectly lost: 2,167,402 bytes in 73,234 blocks ==16527== possibly lost: 21,940,610 bytes in 282,461 blocks ==16527== still reachable: 21,470,100 bytes in 360,304 blocks

What can be done so that Inkscape makes a better effort at cleaning up its enormous memory tangle when it exits while running in valgrind? Some of the memory Inksape allocates is cleaned up, but it seems like a very high percentage of memory allocations are tacked into this complex memory structure, and inside valgrind the whole ball of yarn is just dropped on the floor when the program reaches the final exit(), rather than being unwound in an orderly fashion. (In theory GC may be cleaning this up better, but I'm not sure how we can really know, since valgrind cannot tell us.)

Could somebody who understands these parts of Inkscape PLEASE clean up this mess, so that in future when "_INKSCAPE_GC==disable" Inkscape will unwind its memory structures before exiting? At the very least we will learn after this unwinding what memory is still left, and that will be the result of existing bugs in the code. Once we obtain a baseline inkscape that is usable once again in valgrind, we can reasonably expect that by using valgrind developers will be able to catch the memory problems they may introduce. Sadly that is far from true now, what with so many thousands of lines of background noise in the log files to slog through.

Admittedly some of the lines in valgrind's log file do come from valgrind issues, but the ones I know about can be removed with:

cat >wcslen_sse2.supp <<EOD { wcslen1 Memcheck:Addr8 fun:__wcslen_sse2 fun:* } { wcslen2 Memcheck:Cond fun:__wcslen_sse2 fun:* } { iffyinflate Memcheck:Cond fun:inflateReset2 fun:inflateInit2_ obj:* } EOD valgrind -v --leak-check=yes --leak-resolution=high --num-callers=15 --show-reachable=yes --suppressions=./wcslen_sse2.supp --log-file=/tmp/vgfi.log src/inkscape

which improves the output to: --16527-- used_suppression: 208319 wcslen1 --16527-- used_suppression: 142 wcslen2 --16527-- used_suppression: 330 iffyinflate ==16527== ==16527== ERROR SUMMARY: 97190 errors from 13437 contexts (suppressed: 208791 from 656)

I understand that there may be other problems in some libraries which are called, but from the contents of the log file it looks like the majority of the loose ends were directly created in Inkscape. (And we can use valgrind suppression files, as above, to silence the unfixable library problems.)

Thanks,

David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech