Hi, 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 http://code.qt.io/cgit/qt/qtbase.git/commit/?h=5.6.1&id=adf85c09b46eaf55dab362e17e3b0828fb509750), 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 somewhere. 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(): <quote> 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 used). 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. </quote> ( https://dbus.freedesktop.org/doc/api/html/group__DBusThreads.html#ga33b6cf3b8f1e41bad5508f84758818a7 ) 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: https://lists.freedesktop.org/archives/dbus/2012-May/015126.html 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 thread). 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 reproduce. 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
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development