Crash while merge sp_object_ref (refCount) into 0.48.1 code

[suresh]

Hello,

I am using Inkscape version 0.48.1, As it has some memory leak issue. I have reported some behaviour here which appears to me while using inkscape.

https://bugs.launchpad.net/inkscape/+bug/1194871
https://bugs.launchpad.net/inkscape/+bug/1093560
https://bugs.launchpad.net/ubuntu/+source/inkscape/+bug/1019147
https://bugs.launchpad.net/inkscape/+bug/1204343

Today I come across the revision http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/11608.1.65, In that revision g_object_ref replaced via sp_object_ref and one refCount variable value increase or decrease upon operation on object.

Here is the latest version (12945) of sp-object.cpp file
object->refCount--;
    if (object->refCount <= 0) {
        delete object;
    }

which delete the object when refCount reaches to 0, I applied this patch http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12727#src/sp-object.cpp along with 11608.1.65 (in which g_object_ref replaced by sp_object_ref), inkscape compile without any error, but when I try to delete the object it crash at 'delete object' line.

If i remove the condition with ( object->refCount < 0) it works well, but that will not free the memory.

So I just wanted to free the memory which inkscape eats when any operation performed on object, but it crash. Can you please fix the problem so that people who is using 0.48 branch can have stable version of inkscape?

Or is there any other work around to fix the problem of crashing with the latest sp_object_ref implementation? please let me know.

Thanks.
Suresh

[suresh (suresh-meetsme)]

with this when I close the inkscape it also crash.

here are some frame of gdb log.
#0 0x0012d422 in __kernel_vsyscall ()
#1 0x018c4651 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0x018c7a82 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x018fb49d in ?? () from /lib/tls/i686/cmov/libc.so.6
#4 0x01905591 in ?? () from /lib/tls/i686/cmov/libc.so.6
#5 0x01906de8 in ?? () from /lib/tls/i686/cmov/libc.so.6
#6 0x01909ecd in free () from /lib/tls/i686/cmov/libc.so.6
#7 0x01801741 in operator delete(void*) () from /usr/lib/libstdc++.so.6
#8 0x08125e5d in sp_object_unref (object=0x8b62570, owner=0x8cf0098) at sp-object.cpp:336
#9 0x08126154 in sp_object_release (object=0x8cf0098) at sp-object.cpp:788
#10 0x0810c421 in sp_item_release (object=0x8cf0098) at sp-item.cpp:468
#11 0x0812577d in SPObject::releaseReferences (this=0x8cf0098) at sp-object.cpp:933
#12 0x080957bb in ~SPDocument (this=0x8dbaf60, __in_chrg=<value optimized out>) at document.cpp:167

[Alvin Penner (apenner)]

- not reproduced on Windows XP, Inkscape rev 12936
- could you provide detailed steps to reproduce the crash?
- also, I get the impression that you have done partial updates of some selected code, could you do a complete update to a recent rev?

[Markus Engel (engelmarkus)]

Until r12532, objects are ref-counted using gobject.
You *must not* call delete on these objects as they have not been created by calling new, but by g_new. Increasing and decreasing the counter is done by calling g_object_ref and g_object_unref. sp_object_ref and sp_object_unref are simply wrappers for these functions.
In r >= 12532, gobject is not used anymore and ref-counting is done manually. This explains this "if (refCount <= 0) { delete object; }".
When the old reference counting-code really causes memory leaks, current trunk probably still has this issue somewhere.

[suresh (suresh-meetsme)]

@Alvin,

Yes I am doing partial update, I have merged @Markus patch bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/11608.1.65 with my code (0.84.1).

@Markus,

I have applied the patch and it works perfectly fine, now could you please let me know in which file I need to make changes for creating object using new instead of g_new.

Apart from you patch what are the other necessary changes I need to make into the code to overcome the memory leak issue. I guess with new and delete method inkscape will eat less memory than g_object_ref/unref.

with g_object_ref/unref method used by inksape and memory leak, so it is a bug of glib or gtk? As per the gtk docs when there is ref. count became 0 it will automatically remove from the memory but this is not the case with Inkscape.

Please let me know the solution for old code(i.e. 0.48.1) to implement delete the object when ref count became 0.

[suresh (suresh-meetsme)]

@Markus,

Ok. I found in recent sp-object.cpp file new object is created using below statement
 SPObject* child = SPFactory::instance().createObject(typeString);

where in createObject function it return new SPObject(), however in old sp-object.cpp file object creating using
SPObject *child = SP_OBJECT(g_object_new(type, 0));
which later free by g_object_unref.

I studied this https://wiki.gnome.org/Projects/Vala/Ownership#Ownership_in_GLib and according when we call g_object_unref memory destroy, but in our case memory leak. I still not sure about memory leak by g_object_unref or something else as already there are patch available to fix some memory leak.

Is there any way to convert SPObject *child = SP_OBJECT(g_object_new(type, 0)); into SPObject* child = SPFactory::instance().createObject(typeString); as my c++ is not so strong.