On 3 November 2015 at 09:47, Etienne Sandré-Chardonnal <
etienne.san...@m4x.org> wrote:
> I have found this blog post:
>
> https://dragotin.wordpress.com/2014/08/14/monitor-the-qobject-tree-of-a-qt-app/
>
> I will try using these callbacks to monitor the QObject tree. They are
> absolutely undocum
I have found this blog post:
https://dragotin.wordpress.com/2014/08/14/monitor-the-qobject-tree-of-a-qt-app/
I will try using these callbacks to monitor the QObject tree. They are
absolutely undocumented (searching for the function name leads to the blog
page as first result...), are they maintain
Also, use techniques like QScopedPointer to simplify memory
management.
All this was done, especially in the QThread / QSocket part. But the app is
complex and something may have been left out.
I had a similar problem.
You need to look for places where "things" could accumulate.
Ch
l that was needed.
Sent: Friday, October 30, 2015 at 11:23 AM
From: "Daniel França"
To: "Jason H" , "Etienne Sandré-Chardonnal"
Cc: "interest@qt-project.org"
Subject: Re: [Interest] Memory leak problem in a Qt App
You can use boost::object_pool for
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 b
Thanks, I will definitely give it a try. Are these faster than memcheck?
Because the app is computationally intensive (the CPU is fully loaded) and
runs for days, so for memcheck I had to run on simpler cases in order to
make the memcheck run shorter than years... Which is not ideal.
I will also t
> If someone is still pointing at a piece of memory then it
> is not a leak as defined by programs like Purify and Valgrind.
>
That's exactly what I meant by "That's not a leak in the classical sense"
>
> The most important thing to do is to understand how the program works.
> When does it alloc
On 10/30/2015 10:08 AM, Etienne Sandré-Chardonnal wrote:
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.
If someone is still pointing at a piece of memory then
t; 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"
> *To:* "interest@qt-project.org"
> *Subject:* [Interest] Memory leak pro
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"
To: "interest@qt-project.org"
Subject: [Interest] Memory leak p
> Is there any tool for detecting this? Such as one tracking the QObject
> tree, or the number of QObject allocated per subclass?
Hi, there are valgrind massif and heaptrack (https://github.com/KDE/
heaptrack) Also there is GammaRay form KDAB (https://www.kdab.com/gammaray/)
to help you inspect
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 1
12 matches
Mail list logo
