Debugging help for dbus daemons

2007-12-11

Like many KDE application, strigidaemon uses DBus to talk to other programs. Debugging inter-process communication is never very convenient and strigidaemon is no exception. So far, there are no unit tests for checking the quality of the DBus communication in Strigi. I set about to write some and found it was not so easy, so I’m documenting what I did for the benefit of all the other developers using DBus.

Here’s a summary of what is needed to start debugging DBus communication. In the tests, we will start a private dbus-daemon for handling the communication between client and server. In our examples, strigidaemon is the server and we test by sending messages from the client (libstrigiqtdbus) to the server. We will be debugging the code that has not been installed, but resides in the build directory, since this is the normal situation for unit tests.

Step 1: clear the environment

Environment variables like PATH, LD_LIBRARY_PATH, XDG_DATA_DIRS, KDEDIRS all point to your installed software. We will clear them all and use absolute paths to make sure we are debugging the right version of our code. I do not want the unit tests to go wild with my production strigi index!

Clearing the environment can be done by calling unsetenv() for each environment variable. For strigidaemon, we still need HOME to be defined at the moment, so we do not clear that variable.

Step 2: start the dbus-daemon

You can start as many dbus-daemons as you like with dbus-launch. In the unit tests, we start dbus-launch with QProcess. dbus-launch launches dbus-daemon and returns immediately. This will print something like this: