[Development] D-Bus minimum version for Qt 5.6

Romain Pokrzywka romain.pokrzywka at gmail.com
Wed May 25 21:42:31 CEST 2016


I'm writing this both as a question to the QtDBus maintainers and as a PSA
for people using QtDBus and possibly experiencing instability after
upgrading to Qt 5.6. I'm afraid some important piece of information may
have been left out for users who are not building their own dbus libraries
or running the latest linux distros: that using QtDBus in 5.6.0 or later
requires you to use at least dbus 1.8.0 to be stable.

I've started experiencing random crashes inside malloc()/free() after
upgrading to almost-tip-of 5.6.1 (qtbase hash
specifically for processes that are exposing dbus services and objects.
These crashes were during normal execution in totally random and seemingly
innocent places, like when allocating the QArrayData for a QString (which I
could confirm had valid content), or creating a QList node, etc, and
complaining that malloc() had detected a memory corruption. But it always
occurred either in the QDBusConnectionManager thread, or when processing a
dbus method call for one of the exposed objects.

I've tried running my processes under valgrind/memcheck, running clang
analysis tools, etc., and couldn't find anything wrong with my code or the
QtDBus code. All the instability disappeared if I reverted to Qt 5.5 using
the same code, and it would also become unreproducible as I tried adding
more debugging output or running it under valgrind or gdb. So this was a
pretty clear sign of some sort of threading issue or race condition

I eventually tracked it down to the version of dbus used: our system runs
on Ubuntu 12.04 LTS, using the package-provided libdbus which is version
1.4.8. Looking at the documentation about threading support, there's a very
clear warning in the docs for dbus_threads_init_default():


Since D-Bus 1.7 it is safe to call this function from any thread, any
number of times (but it must be called before any other libdbus API is

In D-Bus 1.6 or older, this function must be called in the main thread
before any other thread starts. As a result, it is not sufficient to call
this function in a library or plugin, unless the library or plugin imposes
a similar requirement on its callers.


There's also several threads on the dbus ml archives mentionning that
versions under 1.5.10 are completely unsafe to use in a multi-threaded
environment, for example:

So I think the problem with QtDBus in 5.6 is that now all connection
handling always happens in a background thread (QDBusConnectionManager), so
even if your application runs all in a single thread, there's still going
to be multi-threading by QtDBus itself. And to make things worse, QtDBus
does exactly what the dbus documentation warns not to do for versions
before 1.7: it calls dbus_threads_init_default() in a thread that is not
the main thread (it's called at the beginning of the QDBusConnectionManager

Note that we've also seen similar crashes with dbus 1.6.18, which is the
version that Ubuntu 14.04 ships, even though they're much harder to

Since then I've added dbus 1.10.8 into our dependencies built from source
instead of the using the system one, and so far I haven't experienced
instability anymore.

So I wonder if anybody else has experienced something similar. Maybe
there's something specific to our platform and/or code that makes this more
prominent, but in any case it does look like the change of implementation
in QtDBus with 5.6 is incompatible with dbus <1.7 according to the dbus
docs themselves. Am I correct? If so, I think the bare minimum would be to
have this mentionned prominently somewhere in the documentation. I've also
noticed that qtbase/configure has a MIN_DBUS_1_VERSION variable that is
currently set to 1.2, maybe this should be bumped to 1.8 as well.

I'm also curious how widespread this issue could be, especially for
embedded platforms where it's less likely that the OS and dependencies get
updated often. And given that 12.04 LTS is still supported until 2017 it's
not unreasonable to expect customers to still be using it.

Thanks for your feedback,
Romain Pokrzywka
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160525/9cda4e50/attachment.html>

More information about the Development mailing list