DBus memory leak

[Marco Nicolosi]

Hello,

I've been testing out the Quick Start Client 0 example code.

I simply added a loop to the dbus method call (MethodProxy add_proxy) and monitored the memory consumption in about 10 minutes of execution with valgrind.

The results are those in the following graph: there is an evident and constantly growing memory leak caused by the allocation/reallocation functions of the dbus layer.

I've been using different version of dbus library and the problem is always showing up. 

The graph has been produced with the latest stable version of DBus (1.10.18) and the latest trunk version of dbus-cxx (r237).

Now, since the underlying DBus problem can be hard to find out, a temporary patch could be to periodically destroy and reconstruct the instantiated DBus::Connection and DBus::Dispatcher to free the memory allocated by DBus.

I tried putting all the example code in a scope and repeating this procedure twice: this way the DBus::Dispatcher::pointer, DBus::Connection::pointer, DBus::ObjectProxy::pointer and DBus::MethodProxy instances will be destroyed on scope exit.

Unfortunately the outcome of this solution is the same: memory isn't freed on scope exit (less iterations have been executed in case).

There are two possible causes to this behaviour: either dbus-cxx library isn't correctly calling the dbus functions responsible of the deletion of the instantiated dbus objects or dbus actually leaks memory at some points.

Have you ever noticed such behaviour before or investigated on similar cases?

Thanks in advance.

You can find the code used for the test here.

Best regards,

Marco Nicolosi

[Robert Middleton]

Marco,

Thanks for the info, I'll take a look at it this weekend.  

Probably what's going on here is that dbus-cxx isn't freeing some memory that's being allocated indirectly through the dbus library.  It's not a lot of memory at least, but for long-term that's definitely not good.

Have you run it through valgrind to see where the leak is coming in at all(not just the size of the leak)?  That could give me a clue as to where the fix has to be.  There was a memory leak calling methods that was fixed with r212, my immediate suspicion is there may be similar code still in the library.

-Robert Middleton

--
You received this message because you are subscribed to the Google Groups "Dbus-cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dbus-cxx+unsubscribe@googlegroups.com.
To post to this group, send email to dbus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dbus-cxx/bf8c4d33-ad92-43a3-9901-e283cfa7a563%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Middleton]

This should now be fixed as of r238.  

I have also found a few new errors running this sample program through Valgrind, so I'm going to try and fix those as well.

-Robert Middleton

[Marco Nicolosi]

Robert,
thanks a lot! I've tested r238 and it actually fixes the leak on method calls!

As a side note I found a small leak when instantiating private connections instead of shared ones.

This is the outcome of the execution of the test code with shared connection (removing true flag from function Dispatcher::create_connection(DBus::BUS_SESSION, true) at lines 15,48):

and this is the same code with private connections:

I'll test it with callgrind later to see where the leak is coming from but, unless private connections are frequently closed and opened, that's definitely not a big issue compared to the one on method calls.

Thanks again,

Marco Nicolosi

To unsubscribe from this group and stop receiving emails from it, send an email to dbus-cxx+u...@googlegroups.com.