memory problems reported by valgrind
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Inkscape |
Triaged
|
Medium
|
Unassigned |
Bug Description
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:
fun:wcscoll
}
{
<wcslen2>
Memcheck:Cond
fun:
fun:wcscoll
}
{
<iffyinflate>
Memcheck:Cond
fun:
fun:
obj:*
}
1, _INKSCAPE_
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_
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
somefunction
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.
summary: |
- QC issue: too many memory problems seen with valgrind + memory problems reported by valgrind |
tags: | added: performance |
Changed in inkscape: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
assignee: | nobody → Kris (kris-degussem) |
Changed in inkscape: | |
status: | Confirmed → In Progress |
Changed in inkscape: | |
assignee: | Kris (kris-degussem) → nobody |
Changed in inkscape: | |
status: | In Progress → Triaged |
A possible memory leak fixed in revision 12052 (was not present in valgrind report in comment 1).