Re: [Chicken-users] dbus egg memory leak fixes

[rivo]

Hi, Shawn Rutledge

My first attempt to automate the DBusMessageIter memory management has failed cause sub-iterator saves the reference to the parent iterator. Using finalizer maybe a good idea but introduce unnecessary gc penalty (not sure,need to be proofed), DBusMessage reference-counted with explicit life scope, so as for me there is no shame to unref message each time in the library code.

To reproduce memory leak i use sligtly changed car example, one script send complex message in the endless loop, another receive.

On 21 January 2015 at 10:37, rivo <address@hidden> wrote:

Hello

This batch of patches fixes multiple memory leaks in the dbus egg, especially freaky variant/dictionary exchange format that connman network manager uses alot.

Thanks.

These patches add more manual memory management though, and ideally I don't think that should be necessary in a garbage-collected language.  When anything that is a Scheme wrapper around a C object that your application created is garbage-collected, I think it should also free whatever memory that its construction caused to be allocated in C.  But I procrastinated doing it.  Now the latest svn trunk has an attempt to define the finalizer by calling set-finalizer! in a lambda which is the last argument to define-foreign-type (RETCONVERT); the idea came from how the SDL egg does it.  So I'm hoping that a DBusMessage will be garbage-collected regardless how it got constructed, whenever its wrapper object is collected.

The D-Bus docs say that a DBusMessageIter does not need to be freed:

http://dbus.freedesktop.org/doc/api/html/group__DBusMessage.html#ga9f98b47c84f0e401ea985e681de4e963

and it's copyable.  So maybe I shouldn't malloc it, but pass it into Scheme as a blob?  Then we wouldn't have to worry about freeing it.

So you can test the svn trunk version if you like.  How are you detecting leaks, BTW?

If you come up with improvements to the connman examples, it wouldn't hurt to make them better.  Some of them don't work anymore, although I think they did when I wrote them.  I tested with connman-services-changed.scm since it still works, but it is only handling signals, not calling methods.

carrecv.scm
Description: Text document

carsend.scm
Description: Text document