Multithreaded use of QtDBus (post-5.6 redesign) causes heap corruption, rarely

We have a highly multi-threaded embedded application, running on a multicore ARM target, that uses QtDBus (headless Qt, currently version 4.8.6) from multiple threads. From time to time, we were seeing heap corruption in QtDBus code paths – usually reported by glibc's memory management functions upon them noticing invalid heap management data structures – resulting in the process crashing. For now, we've worked around the crash by setting thread affinity for all threads in the process to the same core, and haven't seen a crash since doing so, after running long enough that we would have expeted a crash in the absence of thread affinity.

We reduced the crashing QtDBus usage pattern to a minimal test case consisting of two processes communicating on a session bus. To rule out architecture effects and any pre-5.6 QtDBus multithreading issues, we are running the same test case on x86_64 on a recent Qt 5 qtbase (git commit f510a51dace0cb39a93b057b8fcbcbdda33a956e), and we're getting similar heap corruption signatures.

I'm attaching the test case and an example backtrace from a coredump, produced by the "A" process crashing. "qmake; make" from the extraction directory should be enough to build the test case on GNU/Linux.

The test case tarball includes a wrapper script (invoked in the extraction directory as ./run-a-b-x86_64) that restarts the test every hour, in case the corruption happens at start up and eventually gets tripped over. It usually takes a long time to get any crashes, sometimes up to 24-48 hours.

I'm open to other debugging suggestions, e.g. how to run helgrind while avoiding false-positives. Ideally I would like to do all QtDBus accesses from only one thread, but our application isn't written like that, and I believe the QtDBus usage pattern in the test case is a valid use of the API (i.e., should be thread-safe).