If you are using QMutex, you are probably writing threaded applications, and thus want to use helgrind (part of valgrind).
helgrind has some support for threading and mutexes in Qt, but not fully.
If you try to run a app using a QMutex subclass in helgrind, it fails with
|
1 |
<appname>: hg_intercepts.c:2124: _vgwZU_libQtCoreZdsoZa__ZN6QMutexC2ENS_13RecursionModeE: Assertion `0‘ failed. |
Basically, it is the handler for the _ZN6QMutexC2ENS_13RecursionModeE symbol that is implemented as assert(0);. The demangled symbol is QMutex::QMutex(QMutex::RecursionMode), which looks very much like the constructor for QMutex:
|
1 2 3 |
$ objdump –T /usr/lib/libQtCore.so | grep _ZN6QMutexC 00068840 g DF .text 0000005b Base _ZN6QMutexC2ENS_13RecursionModeE 000687e0 g DF .text 0000005b Base _ZN6QMutexC1ENS_13RecursionModeE |
which both demangles into the same QMutex::QMutex(QMutex::RecursionMode)
The important difference is the C1 vs C2 in the mangled symbol name. The C1 symbol is used for creating QMutex objects (complete object constructor), wheras the C2 symbol is used for creating subclasses of QMutex (base object constructor).
And the C2 handler in helgrind is as said implemented as assert(0);.
So until helgrind is fixed here, please be careful to not subclass QMutex. (the destructor handler for subclasses is also implemented the same way)
QMutex has no virtual base class, so even in case of subclassing, I think the helgrind handlers should be implemented the same way in the base object constructor as in the base complete object constructor.
I guess I should file a bug against helgrind.
A test app if anyone is curious:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
#include <QtCore> class mymutex : public QMutex { public: mymutex(QMutex::RecursionMode=QMutex::NonRecursive); }; mymutex::mymutex(QMutex::RecursionMode mode) : QMutex(mode) { } int main(int, char**) { mymutex m; QMutexLocker lock(&m); return 0; } |
Update 1: Bug filed.
Update 2: Better understanding of virtual base classes. Thanks Thiago
