How do you troubleshoot a deadlock caused by synchronous D-Bus calls?

A classic D-Bus deadlock happens when process A makes a blocking synchronous call into process B, while B, in the middle of handling that call, tries to make its own blocking synchronous call back into A, and A's thread is stuck waiting and can't service B's incoming call, so neither side ever proceeds.

1. Confirm it's actually a call cycle. Use dbus-monitor to capture traffic from both processes and check whether a method call to B was in flight when B issued its own call back toward A.
2. Check thread and main-loop state. If the synchronous call was made from a GUI or main-loop thread, confirm that thread isn't the same one needed to process incoming calls, since that's the direct cause of the hang.
3. Convert one or both calls to asynchronous. The structural fix is almost always to make at least one leg of the cycle async, so the thread making the outbound call remains free to service inbound calls while waiting.
4. Avoid synchronous calls from any code path that might be re-entered, such as a D-Bus method handler, signal handler, or property getter, since these are exactly the contexts where a callback into the caller can trigger the cycle.
5. Add call timeouts as a safety net so a genuine deadlock fails loudly with a timeout error rather than hanging indefinitely, making the underlying cycle easier to spot in logs.