[Interest] valgrind

[Thiago Macieira]

On terça-feira, 9 de julho de 2013 15.13.55, Jonathan Greig wrote:
> Off of the top of my head, Qt typically doesn't allocate memory that the
> programmer is then explicitly required to free as long as the object is
> assigned a parent. If it does allocate memory that the programmer needs to
> free, then it should be listed in the documentation. If one of my slots I
> created allocates memory and I don't free it later, valgrind still reports
> the problem even though I am using the suppression. Can you show me an
> actual piece of code which demonstrates the suppression file missing an
> intentional leak? I'm certainly listening and willing to learn if there is
> a better way.

I can't think of any at this point. It really depends on how memcheck tracks 
the dependencies.

For example, QList, QVector, QMap allocate memory inside Qt code, whereas 
QLinkedList allocates it via new in an inline function. If you have an object 
that leaks and that object has a QList, have a leak in memory allocated by Qt.

Similarly, any class that has a private member usually allocates that private 
inside the Qt libraries. Imagine that the destructor for that is not run but 
the memory for the object is freed manually (contrived example: deleting a 
forward-declared class -- it produces a warning). In this case, there's a 
definite leak caused by your code, of memory allocated in Qt.

> The Qt suppression file is meant for someone using the Qt API in their
> project, not someone developing Qt itself. Someone trying to find memory
> leaks in Qt definitely wouldn't want to use it. If you are looking at it
> from a Qt developer perspective, then I can see why it's not desirable.

Ok, then I agree we should produce a suppression file that hides the "benign" 
reachables, those that are usually caused global statics.

> results in almost as many (13) definitely lost leaks as there are lines in
> the program. I didn't cause these exept 1 block, which is why a suppression

My guess is that you *did* cause those leaks, by leaking in your application.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130709/cee4a178/attachment.sig>