QDbus: connection fails but lastError indicates no error

brgl

Ok so the issue was spotted in a bigger Qt application, I just started reducing the problem to a couple lines to figure out what's wrong.

The above example was missing the event loop so I did this:

int main(int argc, char **argv)
{
	QApplication app(argc, argv);

	qInfo() << "Before connection";
	qInfo() << "Is connected " << QDBusConnection::systemBus().isConnected();

	Receiver receiver;

	qInfo() << "Trying to connect";
	auto ret = QDBusConnection::systemBus().connect(
		"org.veki.CloudAgent1",
		"/org/veki/CloudAgent1",
		"org.freedesktop.DBus.ObjectManager",
		"InterfacesAdded",
		&receiver,
		SLOT(InterfacesAdded(QDBusObjectPath, InterfaceList)));

	qInfo() << "connect(): " << ret;

	qInfo() << "connect() error: " << QDBusConnection::systemBus().lastError().type();

	return app.exec();
}

And with QDBUS_DEBUG enabled the output looks like this:

Before connection
QDBusConnectionPrivate(0x7f90004f50) : connected successfully
Is connected  true
Trying to connect
QDBusConnectionPrivate(0x7f90004f50) got message (signal): QDBusMessage(type=Signal, service="org.freedesktop.DBus", path="/org/freedesktop/DBus", interface="org.freedesktop.DBus", member="NameAcquired", signature="s", contents=(":1.27") )
connect():  false
QDBusConnectionPrivate(0x7f90004f50) delivery is suspended
connect() error:  QDBusError::NoError
QDBusConnectionPrivate(0x7f90004f50) dequeueing message QDBusMessage(type=Signal, service="org.freedesktop.DBus", path="/org/freedesktop/DBus", interface="org.freedesktop.DBus", member="NameAcquired", signature="s", contents=(":1.27") )

This delivery is suspended message is emitted from src/dbus/qdbusintegrator.cpp from this method:

bool QDBusConnectionPrivate::handleMessage(const QDBusMessage &amsg)
{
    if (!ref.loadRelaxed())
        return false;

    // local message are always delivered, regardless of filtering
    // or whether the dispatcher is enabled
    bool isLocal = QDBusMessagePrivate::isLocal(amsg);

    if (!dispatchEnabled && !isLocal) {
        // queue messages only, we'll handle them later
        qDBusDebug() << this << "delivery is suspended";
        pendingMessages << amsg;
        return amsg.type() == QDBusMessage::MethodCallMessage;
    }

I need to figure out what this dispatchEnabled field is about.

SGaist

Are you sure your slot signature is correct ?

brgl

Yes,

The slot function is:

void Receiver::InterfacesAdded(QDBusObjectPath object_path, QMap<QString, QVariantMap> interfaces_and_properties)

The SLOT expansion is:

SLOT(InterfacesAdded(QDBusObjectPath, QMap<QString, QVariantMap>)

brgl

I tried using the extended variant of the connect() method:

	auto ret = QDBusConnection::systemBus().connect(
		"org.veki.CloudAgent1",
		"/org/veki/CloudAgent1",
		"org.freedesktop.DBus.ObjectManager",
		"InterfacesAdded",
		"a{sa{sv}}",
		&receiver,
		SLOT(InterfacesAdded(QDBusObjectPath, QMap<QString, QVariantMap>)));

Same (lack of) effect.

brgl

This delivery is suspended message and the subsequent dequeueing the message one are part of the normal flow it seems. It dequeues the message once the main loop is running. Still not sure why I can't connect to the signal. I checked with gdbus monitor and a bit of python code using pydbus and the provider of this signal works just fine, I can connect to it and be notified when it's triggered.

SGaist

Are you using the Qt version of your distribution ?

brgl

I tried this on qt5 & qt6 from the distro (ubuntu 22.04). I tried the same on a yocto based OS with meta-qt5 and meta-qt6 respectively. Qt6 version is 6.4.1. I tried switching to session bus (but that shouldn't matter as gdbus monitor works fine as does pydbus, no issues with dbus config).

I created a very minimal example with a pydbus provider that after 5 seconds adds an interface:

#!/usr/bin/env python3

import pydbus
import pydbus_manager

from gi.repository import GLib
from functools import partial

class Provider:
    """
    <node>
        <interface name='org.dupa.Provider1'>
            <property name='Dupa' type='s' access='read'/>
        </interface>
    </node>
    """

    @property
    def Dupa(self):
        return "dupa dupa"

def add_interface(manager):
    print("Adding object")
    manager.register_object("/org/dupa/Provider1/Dupa", Provider(), None);
    return GLib.SOURCE_REMOVE

if __name__ == "__main__":
    loop = GLib.MainLoop()
    bus = pydbus.SessionBus()
    manager = pydbus_manager.Manager(bus, "org.dupa.Provider1")

    GLib.timeout_add_seconds(5, partial(add_interface, manager))

    loop.run()

And the minimal Qt example doesn't work with it all the same. It seems to me that if connect() returns false but no error is set, then it's a bug in the library?

It's probably something stupid but I cannot figure it out.

SGaist

To make things simple to test:

Can you provide a requirement.txt for your example script ?
Can you provide a minimal C++ example that uses your provider for testing as well ?
That way it will be easier to reproduce your issue in similar conditions.

brgl

Hi @SGaist !

Here's a repo with a functional example: https://github.com/brgl/qdbus-signal-example

Inside you'll find a requirements.txt file for the python scripts, a functional python signal provider and receiver and a qt6 receiver that doesn't work.

For simplicity it uses the session bus. You need to run python-provider/provider.py and then within 5 seconds run the python-receiver/receiver.py script and observe that it correctly receives the signal. You can then run qmake6 and make inside the qt6-receiver directory and do the same for the qt receiver program. It will fail to connect and not receive the signal as well as not indicate any error.

Let me know if that's clear and thanks for helping!

n1k0

Hi @SGaist, were you able to male any progress on this? Thank you for your help!

SGaist

I am suspecting that there's an issue with the signature of the slot but I haven't been able to pinpoint it.

The D-Bus type is a{sa{sv}} So it's a dictionary with string as key and as value a dictionary with string as key and variant as values. The variant is mapped to QDBusVariant based on D-Bus type system so I would check in that direction.

brgl

How would I debug any such issues with signal-to-slot signatures?

brgl

https://doc.qt.io/qt-6/qdbustypesystem.html#the-type-system-in-use Does this:

Warning: You may not use any type that is not on the list above, including typedefs to the types listed. This also includes QList<QVariant> and QMap<QString,QVariant>.

Mean I cannot receive signals passing dicts as arguments?

QDbusViewer is telling me:

Error: Unable to connect to service org.foobar.Provider1, path /org/foobar/Provider1, interface org.freedesktop.DBus.ObjectManager, signal InterfacesAdded

brgl

I've been browsing the KDE Udisks code that uses qt AND connects to the InterfacesAdded signal. I added some bits that were missing from my code:

typedef QMap<QString, QVariantMap> QVariantMapMap;
Q_DECLARE_METATYPE(QVariantMapMap)

and

qDBusRegisterMetaType<QVariantMapMap>();

but that didn't fix it.

SGaist

Can you point me to code in question ?

Did you try with QDBusVariant in place of QVariant ?

brgl

The code's here: https://src.fedoraproject.org/rpms/kdelibs/blob/f94c05b3732a163d5bf76a9dc52d51688339b812/f/kdelibs-udisks2-backend.patch

And yes, I did try to use QDBusVariant with no effect.

brgl

After some more trial and error I finally figured it out.

Basically I need to use QDBusVariant AND also register both the single map and the "mapmap" type:

typedef QMap<QString, QDBusVariant> QDBusVariantMap;
Q_DECLARE_METATYPE(QDBusVariantMap);
typedef QMap<QString, QDBusVariantMap> QDBusVariantMapMap;
Q_DECLARE_METATYPE(QDBusVariantMapMap);

and

qDBusRegisterMetaType<QDBusVariantMap>();
qDBusRegisterMetaType<QDBusVariantMapMap>();

and

	auto ret = bus.connect(
		"org.foobar.Provider1",
		"/org/foobar/Provider1",
		"org.freedesktop.DBus.ObjectManager",
		"InterfacesAdded",
		&receiver,
		SLOT(InterfacesAdded(QDBusObjectPath, QDBusVariantMapMap))
	);

Honestly the error reporting on this thing could use some more work. :)

SGaist

Nice !

I agree with your suggestion. Did you already check the bug report system about that matter ? If there's nothing there, you could open a feature request to improve that message.