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