Hi
On 04/02/14 05:01, Krzysztof Kosiński wrote:
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.
As far as I understand one option could be adding a environment variable, something like DISABLE_GC or similar, then, as far as i know, to surround all the Inkscape::GC::XXX with #ifndef #endif.
Not sure if this would be a correct way to proceed and disable the garbage collector properly. I did a very small test, where i commented the calls to sp_main_gui and sp_main_console and also commented the Inkscape::GC::Init() line. Before commenting the GC init line, a few errors related to GC appeared when running valgrind, after commenting it, the errors disappeared.
Is that approach correct ? Or am i missing something here ?
Regards, Krzysztof
Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Cheers. Guiu.