memory problems reported by valgrind

[David Mathog]

In order to determine if new code is causing memory problems one must run inkscape in valgrind. That is painfully slow, so it would help if there weren't quite so many memory problems already in there to swamp out new ones. The intent of this bug is not to keep track of individual memory problems, as those are discovered they should be split off into their own bugs with appropriate patches to fix them. Rather, this is a place to post valgrind runs so that we can see how much progress is being made in cleaning up these memory problems in general.

The attachment is a valgrind log against branch lp988601 (merged up to r11679 by ~suv) made on Ubuntu 12.04 this way:

0. With these in valgrind's default.supp file (or these messages overwhelm everything else):
{
   <wcslen1>
   Memcheck:Addr8
   fun:__wcslen_sse2
   fun:wcscoll
}

{
   <wcslen2>
   Memcheck:Cond
   fun:__wcslen_sse2
   fun:wcscoll
}
{
   <iffyinflate>
   Memcheck:Cond
   fun:inflateReset2
   fun:inflateInit2_
   obj:*
}

1, _INKSCAPE_GC=disable valgrind --leak-check=yes --show-reachable=yes src/inkscape >/tmp/vg.log 2>&1

 once inkscape starts

2 load bounding_line5.svg
3 save it as EMF with all options checked except MSPUA and Text->Path
4. load test_libuemf_ref.emf (the test file from libUEMF)
5. quit, saving no changes.
6. gzip /tmp/vg.log

This process takes about 10 minutes. (Or longer if I don't keep the mouse away from the Inkscape windows while it is crunching at 100% CPU in valgrind).

Look down at the bottom for the biggest chunks of leaked/lost memory - it isn't pretty.

==15724== LEAK SUMMARY:
==15724== definitely lost: 1,100,761 bytes in 12,819 blocks
==15724== indirectly lost: 1,729,971 bytes in 59,944 blocks
==15724== possibly lost: 43,799,264 bytes in 645,677 blocks
==15724== still reachable: 1,659,950 bytes in 27,788 blocks
==15724== suppressed: 0 bytes in 0 blocks

Nominally this was testing the emf-inout.cpp and emf-print.cpp code which I have been working on. The problem being that not a single one of the problems associated with those two (new) files is actually caused within them - they are all pre-existing problems with the way inkscape does things. At least one of these already has people working on it as Bug #1043571. And these emf-* related problems were very minor, the big ones are elsewhere in the code but are triggered by this test.

One thing that I think would really help is if a section of the shutdown code in Inkscape (wherever that is) could be specifically delegated for cleaning up static memory. (If such a method/function already exists, please tell me where it is!) From there one would know that none of the static memory which might have been allocated by some tool or other will be needed again, so that it is OK to delete it. That is, for a pair of functions:

   somefunction_init(); // allocates a static memory structure
   somefunction_done(); // clean up static memory structure

with no other dependencies, somefunction_done() could always be safely placed in this delegated clean up area. This would
hopefully let valgrind see a much cleaner memory situation on exit, so that real memory problems would be more evident.

[Kris (kris-degussem)]

A possible memory leak fixed in revision 12052 (was not present in valgrind report in comment 1).

[David Mathog (mathog)]

While checking some changes today with valgrind (branch lp988601, rev 11717) I found a very large number of these reported:

==21335== Conditional jump or move depends on uninitialised value(s)
==21335== at 0x828C040: Inkscape::Text::Layout::Calculator::_computeFontLineHeight(font_instance*, double, SPStyle const*, Inkscape::Text::Layout::Lin
eHeight*, double*) (Layout-TNG-Compute.cpp:986)
==21335== by 0x828D0CA: Inkscape::Text::Layout::Calculator::_buildSpansForPara(Inkscape::Text::Layout::Calculator::ParagraphInfo*) const (Layout-TNG-C
ompute.cpp:1157)
==21335== by 0x828F0CA: Inkscape::Text::Layout::Calculator::calculate() (Layout-TNG-Compute.cpp:1473)
==21335== by 0xCDBBF0F: ???

line 986 is the last line in the following

    // yet another borked SPStyle member that we're going to have to fix ourselves
    for ( ; ; ) {
        if (style->line_height.set && !style->line_height.inherit) {
            if (style->line_height.normal)
                break;
            switch (style->line_height.unit) {

[Lei Zhang (thestig-google)]

The inflateReset2 error is likely http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577135