I don't think that implementation addresses the issue I wrote about. It says nothing about moving objects around to be memory contiguous. In .Net, they had to introduce handles (^ operator) to work around the .Net GC compaction. I don't think MS would have done that if a library was all that was needed.
Sent: Friday, October 30, 2015 at 11:23 AM
From: "Daniel França" <[email protected]>
To: "Jason H" <[email protected]>, "Etienne Sandré-Chardonnal" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [Interest] Memory leak problem in a Qt App
From: "Daniel França" <[email protected]>
To: "Jason H" <[email protected]>, "Etienne Sandré-Chardonnal" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [Interest] Memory leak problem in a Qt App
You can use boost::object_pool for that purpose: http://www.boost.org/doc/libs/1_42_0/libs/pool/doc/interfaces/object_pool.html
Em sex, 30 de out de 2015 às 16:10, Jason H <[email protected]> escreveu:
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" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [Interest] Memory leak problem in a Qt App______________________________________________________________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interestThanks!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.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.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.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.
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?
Interest mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
