Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Memory leak in a QThread
Hi there and thx for reading and answering this post if you can.
I'm dealing with a memory leak in a slot executed by a QThread connected as a Qt::QueuedConnection.
Of course, I've tried -fsanitize=thread, then -sanitize=address without success. Either the program crashes before it runs the thread (whereas it runs fine without sanitize) or I get pointless returns.
Do you have an idea about how to deal with such an issue ?
Maybe share the slot code incriminated ?
Ok I could but it is long, complex and the thread crashes at different places, but this is not the point.
In such a case, how to isolate in this case the memory leak with tools like sanitize or valgrind. I have of course already tried but got disappointing results.
What make you think it's a leak ?
Are you sure you're not accessing an invalid pointer ?
Did you check your allocations/deallocations ?
Are you getting data from another library ?
If so, who owns that data and thus who's responsible for freeing it ?
Another problem is that when I run my program with one of those tools, the program may run flawlessly, and without it crashes...
good questions, when my app crashes, I get: free(): invalid next size (normal): 0x00007f5f7006fff0 ***
Abandon (core dumped)
my ptr is correctly allocated, but something pollutes the malloc structure so that it can't free cleanly.
You're using C style memory allocation ?
no, a classical ptr = new myclass.
@skylendar Before suspecting QThread of having a memory leak you should post your code here or at least crash dump, else people here can only guess...
VRonin last edited by
Another problem is that when I run my program with one of those tools, the program may run flawlessly, and without it crashes
This clearly points to a race condition.
in a slot executed by a QThread connected as a Qt::QueuedConnection
If you are subclassing
QThreadand adding a slot you are falling in one of the most common misconceptions about
QThread: it is not the thread, it's a wrapper around it. Slots of the
QThreadwill be executed by the event loop that created the thread, not the one spawned by the thread. See https://mayaposch.wordpress.com/2011/11/01/how-to-really-truly-use-qthreads-the-full-explanation/
Buckwheat last edited by
uspecting QThread of having a memory leak you should post your code here or at least crash dump, else people here can only guess
Yes, it would be nice to see your code a little. One trick I have started using when passing pointers across signals is to use QSharedPointer.
typedef QSharedPointer <Type> PType; // Also works with QSharedDataPointer and QExplicitlySharedDataPointer
slot would be:
void doSomething (const PType& value);
PType type (new Type);
Q_EMIT doSomething (type);
This allows for cleanup and a little safety on the pointer since it is reference counted. You can pass it along and know it will get there. If the event queue ends, the copy is destroyed. When the slot is finished, the copy is destroyed (if reference is 0). When the caller exits, the pointer is destroyed if the reference is 0. There is a little more overhead than a straight pointer, but you do not have to worry about who is the current owner of the pointer or synchronize a return. For me, it is useful in callbacks.
You will, however, have to register PType so the signal/slot mechanism works happily. I use with both the old SIGNAL()/SLOT() and new method of function pointers equally well.
typedef QSharedPointer <LogInfo> PLogInfo;
qRegisterMetaType <PLogInfo> ("PLogInfo");
Experiment. For my app, I use a lot of QSharedData and I have not seen a huge performance hit but I only run 20Hz and 50Hz sensor data. But no memory leaks from threading or messaging.