2014-02-04 mathog <mathog@...1176...>:
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/inkscapeThere 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.
In the long term, I think the consensus is that we should move away from garbage collection and towards explicit memory management with smart pointers. In the short term, I'm afraid there is little we can do about this. The initial pieces of the puzzle are already in place with the C++ification work on the SP tree.
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.)
GC is mainly used in code related to XML and undo handling. Removing GC there requires modifying every piece of code that creates or deletes XML nodes - at least 277 places according to grep.
Regards, Krzysztof