[Interest] Memory leak problem in a Qt App

[Etienne Sandré-Chardonnal]

The app was written by taking care of this, and the effectiveness of
deleteLater connections was checked by printing debug messages in
constructors and destructors. But something may have been left out.

Fragmentation is a dreaded issue. I don't think this is the culprit here,
the computation job build heavy trees upon initialization, which are prone
to fragmenting, but the computing part is not allocating much memory and
only reads the trees, and the whole tree is destroyed at the end of each
job. So I would not expect to have 8Gb of fragmented heap after only
1000-2000 jobs. I should be using a custom allocator for building the trees
in and avoiding this issue, though.

2015-10-30 16:10 GMT+01:00 Jason H <jhihn at gmx.com>:

>
> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20151030/b5f4b92e/attachment.html>