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 <jh...@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.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 >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
