[Interest] valgrind

[Jonathan Greig]

Thiago,
Show reachable is typically considered not a problem in most cases but it's
still good to know it's there. In the case of the unicode stuff it is
reporting, I do not want to see it and would be a possible candidate for
suppression. An example of what I am interested in seeing is this: I had
found that a destructor on one of my classes was not being run before the
application exited and it showed up in still reachable. I was able to fix
this and valgrind was happy even though the memory should be reclaimed upon
exit.

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.

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.

Running on the same attached minimal example:

> valgrind --leak-check=full --show-reachable=yes --error-limit=no
> --gen-suppressions=all --log-file=_memleak.txt -v ./leaktest


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
file is absolutely necessary:

> ==8255==    definitely lost: 1,552 bytes in 13 blocks
> ==8255==    indirectly lost: 14,646 bytes in 160 blocks
> ==8255==      possibly lost: 7,124 bytes in 90 blocks
> ==8255==    still reachable: 250,459 bytes in 2,587 blocks
> ==8255==         suppressed: 0 bytes in 0 blocks




On Mon, Jul 8, 2013 at 3:42 PM, Thiago Macieira
<thiago.macieira at intel.com>wrote:

> On segunda-feira, 8 de julho de 2013 10.55.02, Jonathan Greig wrote:
> > ==25878== LEAK SUMMARY:
> > > ==25878== definitely lost: 40 bytes in 1 blocks
> > > ==25878== indirectly lost: 40 bytes in 1 blocks
> > > ==25878== possibly lost: 0 bytes in 0 blocks
> > > ==25878== still reachable: 3,424 bytes in 5 blocks
> >
> > It also shows me that there are about 3.5 kilobytes that are still
> > reachable due to unicode stuff that I really has nothing to do with the
> > minimal example at all.
>
> And what's the problem? If you don't want to see the reachable stuff, don't
> pass --show-reachable=yes.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> 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/20130709/1889222a/attachment.html>