Re: [Interest] Memory leak problem in a Qt App

[Jason H]

 

I have seen this before in a similar type of app. Don't forget to use QObject::deleteLater() for objects that are created dynamically, and go unneeded after and event (like on socket disconnect).

 

Also while rare, but very real for long-running C/C++ processes of this nature is a memory fragmentation issue (Java and .Net don't have this as they compact their heaps) where you may end up with objects occupying partial pages, which become sparsely populated over time and expand to consume all availbile memory pages. The only work around in C/C++ is to only use dynamic memory only at start-up, and allocate a fixed number of objects which are re-used. This is what NASA does. You could also take a hybrid approach and allocate blocks of objects at a time, this won't prevent, only delay the inevitable. However if your process can eventually free all objects on the page, then you won't ever run into the problem. It's only if the lifetimes of the objects vary significantly that this happens.

 

 

Sent: Friday, October 30, 2015 at 10:08 AM
From: "Etienne Sandré-Chardonnal" <etienne.san...@m4x.org>
To: "interest@qt-project.org" <Interest@qt-project.org>
Subject: [Interest] Memory leak problem in a Qt App

Dear all,
 

I have an app which runs several days executing computation jobs (about one job every few minutes). In some cases, the memory consumption grows to several Gb unexpectedly.
 

I have run valgrind with no success. There was a few minor leaks which were fixed, but now the valgrind result is 100% clean and the issue is still there.
 

However, I'm wondering if this is not due to QObjects which have a parent but which have been forgotten. It could be anything from QThreads to QTcpSockets. As they have a parent, they are not leaked in the classical sense, and will be freed when the app quits, but still they make the program infinitely eating memory.

Some objects also have no parent (such as the root objects running a QThread event loop) but have signal/slot connections and thus are still referenced somewhere in a table, thus defeating valgrind.
 

Is there any tool for detecting this? Such as one tracking the QObject tree, or the number of QObject allocated per subclass?

I'm already trying to solve this the classical way, by displaying debug messages to ensure that objects are deleted, but so far this has been unsuccessful as the program is quite complex.
 

Thanks!

_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest

_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest