On Mon, 2004-08-30 at 00:59, bulia byak wrote:
Mental, please check out the patch in this bug:
https://sourceforge.net/tracker/index.php?func=detail&aid=1012874&gr...
and apply if ok. It fixes a bad memory usage crash in deleteObject.
Unfortunately sourceforge is currently in "read-only" mode, so I cannot comment in the bug itself. The patch hides the problem without really fixing it, though (and sort of breaks the intended semantics I had for successors, albeit not in a way that matters too much).
The bug is not in deleteObject, but rather that deleteObject's caller is not retaining a reference to it (by increasing the reference count) while deleteObject() does its work.
The general rule is always, always, always make sure that you have claimed a refcounted object before calling a nontrivial function (especially one that modifies the object). This holds not just for deleteObject(), or SPObjects in Inkscape, but for any software with simple refcounted objects.
[ The garbage collector relaxes this requirement slightly, but only for classes which are managed by it, which SPObject is not yet. ]
The correct fix is to modify the portion of sp_marker_prev_new():
SPObject *oldmarker = sandbox->getObjectById("sample"); if (oldmarker) oldmarker->deleteObject(false);
thusly:
SPObject *oldmarker = sandbox->getObjectById("sample"); if (oldmarker) { sp_object_ref(oldmarker, NULL); oldmarker->deleteObject(false); sp_object_unref(oldmarker, NULL); }
Probably simliar mistakes are made in other places as well (and with other functions beyond just deleteObject() -- deleteObject() is simply more likely than most to remove the remaining external refcounts on the object).
-mental