dbus glib application crashes

Simon McVittie simon.mcvittie at collabora.co.uk
Mon Aug 11 03:18:14 PDT 2014


On 08/08/14 14:34, Eckert Martin (DC-IA/EWT1) wrote:
> I have implemented  a process “A” communicating to a process “B” using
> dbus_g_proxy_begin_call and dbus_g_proxy_end_call mechanism.

I would strongly recommend not using dbus-glib. The only valid reason to
use dbus-glib in 2014 is if your project has already been using it for
several years and has not yet been able to escape (e.g. Telepathy and
NetworkManager are in this situation).

Modern GLib versions contain GDBus, which is a much better-designed API
for D-Bus in C than dbus-glib.

(dbus-glib is unmaintained; I am its unmaintainer. It is really not a
good thing to be using and I'm trying to switch Telepathy away from it.)

> Process A
> also listens to several dbus Signals from process B and other processes.
> Process A itself has one mainloop running and unfortunately crashes
> unexpected when running for a while (1 to 24 hours).

Sorry, this is nowhere near enough information to diagnose a crash.

Some wild guesses:

* If process A is multi-threaded and needs to interact with D-Bus from
  more than one thread, switch to GDBus. dbus-glib is known not to be
  thread-safe.

* If you get critical warnings, those indicate programmer error. Work
  out why they are happening, and solve them. G_DEBUG=fatal-criticals
  can help, by turning them into crashes.

* Get a backtrace for the crash and see whether that tells you anything.

> At the moment Process A calls dbus_g_proxy_begin_call not in the context
> of the gmainloop.  Can this be the problem?

If you mean "from a thread other than the main thread": yes, that could
be the problem. dbus-glib is specifically not thread-safe.

Regards,
    S



More information about the dbus mailing list