Re: [Inkscape-devel] Making inkscape usable in valgrind grumble
On 03-Feb-2014 20:01, Krzysztof Kosiński wrote:
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.
Apparently the current GC does not call destructors when it
automatically removes memory. Inkscape has code in gc-finalized to tack
a destructor onto an entry, but it isn't easy to see how often it is
employed (grep shows "Finalized" in only a handful of source of files),
and gc-finalized.h lists several caveats, which say that there are lots
of situations where it might never act even if invoked.
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.
Speaking of that section, is there some debugger trick for keeping track
of the objects that that code creates and deletes? I've been trying to
follow it in gdb but since the memory pointers move around from run to
run, and just running gdb seems to change what inkscape does (probably
because mouse events are caught in strange ways, or windows overlap), it
is really tedious.
I ask because my text decoration mods blow up in style.cpp in
sp_style_paint_server_ref_modified() when a certain simple object is
selected on the drawing surface and then copied - but not if it is
cloned. That object is just this:
<text
style="font-size:40px;fill:none;stroke:url(#MyPattern);stroke-width:5;"
y="40"><tspan>A<tspan
style="text-decoration:underline">B</tspan></tspan></text>
The copy (==^C) triggers an insane amount of activity which passes in
and out of style.cpp, where signals are attached and detached,
apparently to/from the same objects much of the time, until eventually
it drops into the function mentioned above with a PaintServer server
that no longer matches the ones in style->stroke and
style->text_decoration_stroke (which match each other), which triggers
the crash. (After having previously been in that same function maybe a
dozen times without issue.) It is my impression that there is vastly
more activity for this simple copy then there is in just reading in that
section of the file in the first place. (It definitely calls
sp_style_write_string() at least 2 times for each of the styles in the
section being copied, probably because execution control is through the
setting and resetting of modified flags, rather than by doing a single
"atomic" 1:1 copy.) Conversely, this object:
<text style="font-size:40px;fill:url(#MyPattern);stroke:none"
y="40"><tspan>A<tspan
style="text-decoration:underline">B</tspan></tspan></text>
copies without issue. It too triggers a lot of activity, including
redundant sp_style_write_string() calls, but somehow it avoids whatever
pitfall the first one falls into. As far as I can tell the
implementations for style->text_decoration_fill and
style->text_decoration_stroke are symmetrical, so why one crashes, and
the other doesn't is pretty mysterious at present. It has something to
do with the paintServer href, since there are no problems with
text_decoration_stroke when it does not use a pattern or a gradient.
Tracing execution in this region is no fun since much of it is driven by
signals that trigger calls to stored references to functions. I can
watch it creating patterns, objects, and styles, but figuring out which
is which solely from their pointers, which change from run to run, is
not a lot of fun.
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech