Skip to content

How to use helgrind to debug multithreaded Qt applications Finding thread race conditions in Qt4 and Qt 5

You’ve heard of valgrind before, its default tool (memcheck) is such a life saver, being able to detect memory-related bugs in your code (leaks, double deletions, use of deleted memory, use of uninitialized memory, etc.).

Well, it turns out that valgrind also comes with a tool to detect race conditions between threads, in multithreaded applications. That tool is called helgrind.

In theory, provided that you’re on a Unix platform, using helgrind is as simple as

valgrind --tool=helgrind myapplication

However, if you do just that on a Qt application, you’ll end up digging through lots of false positives, making this a rather painful experience. So I wrote a howto with all the necessary steps to debug Qt4 and Qt5 applications with helgrind.

Currently it’s a little bit involved, you need to compile your own valgrind, your own Qt, patch Qt, set up a suppression file, and define an alias. Don’t worry, it’s all doable 🙂

Over time this will be simpler, after the next release of valgrind and Qt 5 only the last two steps will be necessary.

The full details on how to set up helgrind and Qt are in my helgrind for Qt applications howto.

(I prefer to keep the actual howto as an old-style webpage rather than a blog, to be able to keep updating it as time goes by, and new issues are detected or fixed. Easier than for you to have to read through ten consecutive blogs.)

Categories: KDAB Blogs / KDAB on Qt

5 thoughts on “How to use helgrind to debug multithreaded Qt applications”

  1. Hello, I am using QT5.2.1 and was just wondering if I needed to patch anything with valgrind or qt in order to use helgrind effectively as it seems like the paper was written for <QT5.2? Currently, it seems like helgrind gives me a lot of errors that targets QT and not particularily with the code that's been written.

  2. David Faure

    Qt 5.2.1 is definitely fine. But you should make sure you’re following the steps in the howto and you’re using the latest kde.supp file from kde-dev-scripts git master. I fixed a few more things in there yesterday…

    If you still get races from within Qt, it might be that some later patches need to be backported, we keep finding and fixing races inside Qt itself 🙂

    Email me (david.faure at kdab.com) the first race detected by helgrind and I’ll be able to tell you where it comes from.

    1. Hello dfaure, I don’t see anything in the howto that applies to qt 5.2. Would I need to follow the steps for 5.1? Is that okay? After I do this, I would email you the first race! Thank you!

  3. David Faure

    The howto does mention Qt 5.2:

    “If you’re using Qt 5.2 or Qt 4.8.6 you can skip this section.”

  4. Valgrind also contains a second thread hazard detection tool, DRD. Roughly speaking the difference is that Helgrind keeps a history of memory accesses so that it can report the contexts of all threads. DRD only stores the synchronization events so you only get the context of the thread where DRD saw a conflict. Not saving all that history makes DRD faster.

    If you find any problems then please report them to https://bugs.kde.org. Fixing problems can take a long time though!

Leave a Reply

Your email address will not be published. Required fields are marked *