Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-55971

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

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Reported
    • Priority: P3: Somewhat important
    • Resolution: Unresolved
    • Affects Version/s: 5.8.0 Alpha
    • Fix Version/s: None
    • Component/s: D-Bus
    • Labels:
      None
    • Environment:
      CentOS 7.2.1511, /lib64/libdbus-1.so.3 provided by dbus-libs-1.6.12-14.el7_2.x86_64

      Description

      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).

        Attachments

          Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

            Activity

              People

              • Assignee:
                thiago Thiago Macieira
                Reporter:
                fitzsim Thomas Fitzsimmons
              • Votes:
                1 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:

                  Gerrit Reviews

                  There are no open Gerrit changes