memory leaks from OnlineAccounts::Manager

So looking at the Qt code, the QDBusPendingCallPrivate class is ref counted, where most references will be owned by a QDBusPendingCall instance (or a subclass). It has one additional reference that is managed manually in the QDBusConnectionPrivate code.

I suspect it is this last reference that is getting lost somewhere, but I've got no idea why I haven't noticed something similar in other pieces of code invoking asynchronous methods with QtDBus.

Here's a log captured on vivid/amd64 (Qt 5.6.1). I can see the same QDBusPendingCallPrivate leaks.

Oops. That should read yakkety/amd64. I'll add a vivid trace shortly.

I'm seeing loads of complaints from valgrind when running the online-accounts-api tests.

For tst_daemon: http://pastebin.ubuntu.com/23657421/

For tst_qml_module: http://pastebin.ubuntu.com/23657424/

For functional_tests: http://pastebin.ubuntu.com/23657435/

Thanks for the logs.

I quickly investigated the issue, and the leaks from the functional_tests (that is, from the client library) are happening because the tests don't iterate the main loop, and therefore some cleanup methods which were queued in the main loop are never executed. I'll fix that when convenient (the bug is in the tests, so your app should not be affected).

When running the tst_daemon, I get the same leaks you reported, plus this error, near the beginning of the tests:

==6662== Syscall param pselect6(sig) points to unaddressable byte(s)
==6662== at 0x6011FCC: pselect (pselect.c:69)
==6662== by 0x532CBD9: qt_safe_select(int, fd_set*, fd_set*, fd_set*, timespec const*) (qcore_unix.cpp:86)
==6662== by 0x532CD87: qt_select_msecs(int, fd_set*, fd_set*, int) (qcore_unix.cpp:113)
==6662== by 0x526F254: QProcessPrivate::waitForFinished(int) (qprocess_unix.cpp:899)
==6662== by 0x520E3DA: QProcess::waitForFinished(int) (qprocess.cpp:1876)
==6662== by 0x5771255: QtDBusTest::SuicidalProcess::~SuicidalProcess() (in /usr/lib/x86_64-linux-gnu/libqtdbustest.so.1.0.0)
==6662== by 0x576EF68: QtDBusTest::QProcessDBusService::~QProcessDBusService() (in /usr/lib/x86_64-linux-gnu/libqtdbustest.so.1.0.0)
==6662== by 0x576EFC8: QtDBusTest::QProcessDBusService::~QProcessDBusService() (in /usr/lib/x86_64-linux-gnu/libqtdbustest.so.1.0.0)
==6662== by 0x576D0F8: ??? (in /usr/lib/x86_64-linux-gnu/libqtdbustest.so.1.0.0)
==6662== by 0x576E2B4: QtDBusTest::DBusTestRunner::~DBusTestRunner() (in /usr/lib/x86_64-linux-gnu/libqtdbustest.so.1.0.0)
==6662== by 0x12F523: ~DBusService (functional_tests.cpp:176)
==6662== by 0x12F523: DBusService::~DBusService() (functional_tests.cpp:176)
==6662== by 0x52E638D: QMetaMethod::invoke(QObject*, Qt::ConnectionType, QGenericReturnArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument) const (qmetaobject.cpp:2211)
==6662== Address 0x802001670 is 0 bytes inside a block of size 32 in arena "core"
==6662==

Did you get it as well? Anyway, the leaks reported in this test are not that important, given that they do not refer to the daemon library (which is executed within another process) but to the tests themselves.

I'm seeing the pselect error in the SF tests suite. From memory, it's non-deterministic though.

I'm concerned about the sendWithReplyAsync() leak. That's a big leak, and we are seeing this all over the place in storage framework. That one really needs fixing.

Which one exactly? I don't see a leak with that function name in the stack, in the logs you posted.

I'll try to reproduce tomorrow. As I said, it's non-deterministic.