Memory leak in a QThread

skylendar

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 ?

SGaist

Hi,

Maybe share the slot code incriminated ?

skylendar

@SGaist

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.

SGaist

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 ?

skylendar

@skylendar

Another problem is that when I run my program with one of those tools, the program may run flawlessly, and without it crashes...

skylendar

@SGaist

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.

SGaist

You're using C style memory allocation ?

skylendar

@SGaist

no, a classical ptr = new myclass.

jsulm

@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

@skylendar said in Memory leak in a QThread:

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 QThread and 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 QThread will 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

@jsulm said in Memory leak in a QThread:

uspecting QThread of having a memory leak you should post your code here or at least crash dump, else people here can only guess

Hi @skylendar
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);

calling conv:
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.