When registering a name, zbus will deadlock if it receives many messages before the RequestName reply. This occurs because:
The RequestName() call means the dbus server can send messages for that name before it sends the RequestName() reply.
While name registration is in progress the registered names lock is held.
These messages are queued on a sender channel.
The queued messages are not dispatched because the object server task blocks waiting for the registered names lock (see 2 above).
This sender channel can become full, blocking the receiver task when it attempts to enqueue on a full channel.
If the receiver task blocks it does not receive the RequestName() reply and name registration.
Since name registration never completes the registered names lock is never released, none of the pending messages are dispatched, the sender remains full and the receiver never receives any more messages.
This deadlock is most likely to occur if the dbus service is a dbus-activated systemd service. The dbus server will hold calls while the service is starting, releasing them when RequestName() is called but before the RequestName() reply is sent.
Avoid this deadlock by not attempting to take the registered names lock in the object server task. The check that the destination is a registered name is unnecessary as the dbus server will not send messages for unregistered names.
This allows the object server to dispatch messages while name registration is in progress so the sender does not become full and thus the receiver does not block.
When registering a name, zbus will deadlock if it receives many messages before the RequestName reply. This occurs because:
The RequestName() call means the dbus server can send messages for that name before it sends the RequestName() reply.
While name registration is in progress the registered names lock is held.
These messages are queued on a sender channel.
The queued messages are not dispatched because the object server task blocks waiting for the registered names lock (see 2 above).
This sender channel can become full, blocking the receiver task when it attempts to enqueue on a full channel.
If the receiver task blocks it does not receive the RequestName() reply and name registration.
Since name registration never completes the registered names lock is never released, none of the pending messages are dispatched, the sender remains full and the receiver never receives any more messages.
This deadlock is most likely to occur if the dbus service is a dbus-activated systemd service. The dbus server will hold calls while the service is starting, releasing them when RequestName() is called but before the RequestName() reply is sent.
Avoid this deadlock by not attempting to take the registered names lock in the object server task. The check that the destination is a registered name is unnecessary as the dbus server will not send messages for unregistered names.
This allows the object server to dispatch messages while name registration is in progress so the sender does not become full and thus the receiver does not block.