[Interest] Memory leak problem in a Qt App

[Daniel França]

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 <jhihn at gmx.com> 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" <etienne.sandre at m4x.org>
> *To:* "interest at qt-project.org" <Interest at 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20151030/1a5d7d84/attachment.html>