QT Memory Leaks

[tbscope]

The only issue is that it seems to have a massive amount of memory leaks (~2400), even though I delete all of the objects that I create.

Since measuring isn't only about the results but more importantly about how the measurement is done, can you give a description of how the measurement is done and how you get the number 2400?

[lukabratzi]

Sure, I'm not really sure what you mean by your question but I'll do my best to explain it.

I just use #include "vld.h" at the top of my main function and run the program in debug mode. When it finishes execution vld outputs the status of my memory leaks. Its nothing that I did, just a library that I include in the source code.

[tbscope]

Yes, that's in the direction of my question.

I don't know vld. Can you give a url please?

[lukabratzi]

Sure, here it is: VLD link

There's a post at the bottom of the page called Qt that may be relevant. Its where I'm getting my assumption that the issue lies with QT/vld integrating

[squidge]

VLD can support stack tracing of each leak, so you can see where the leaks are occuring from.

[tbscope]

The problem you can have with in place (or in the code of your program itself) memory checking tools is the Heisenberg principle. When you are part of the system and you try to measure it, you will change the system.

From onderstanding the posts on that site, the memory checking tool can be finished before the qt library is finished, resulting in false positives.

On linux there's a tool called valgrind witch is not part of your program so it can measure more accurate

[lukabratzi]

Are there any windows alternatives to valgrind? My code was written on a windows pc and I don't currently have access to a linux pc.

Also, the output from vld looks like this:
0xFEEEFEEE (File and line number not available): (Function name unavailable)

So I can't really trace the leaks and see where they're originating because vld can't tell me.

[tbscope]

If you want the stack traces to work, you also need to compile the Qt library in debug mode and link your program to the debug version of the Qt library.

[lukabratzi]

Oh okay, that explains a lot about the error messages. I'm currently compiling with visual studio 2008 using the qt plugin in debug mode. How can I compile/link to the qt library in debug mode?

[tbscope]

There's a configure option. Before you build the Qt library, you need to configure it. Use -debug (or something like that) instead of -release.
Then, when it is installed, use the qmake of the debug version of the qt library. This qmake version will link to all the qt debug libraries.

Thus:
configure qt with -debug
build it
install it to a certain directory (example: c:\qtdebug)
use qmake from this version (example: c:\qtdebug\bin\qmake c:\myproject\myproject.pro)

[tbscope]

But:
Even then the stack traces won't be useful. You get a list of thousands of lines with no real information because all those objects are actually deleted after the report from your tool is done.

[lukabratzi]

So what other options do I have to fix this? By the way, thanks everyone for all the help.

[squidge]

But:
Even then the stack traces won't be useful. You get a list of thousands of lines with no real information because all those objects are actually deleted after the report from your tool is done.

The idea behind VLD is that it starts at main, and does the output when main returns. Therefore, Qt should be fully finished by that time. Whatever is left is assumed to be leaks. Of course, it's not perfect, but when you know the limitations, it can be quite useful.

As for the stack, the trace is captured at memory allocation time (not at leak detection time), so it should still be able to point you in the right direction.

[tbscope]

Suggestion for improvement using VLD:

1. Make sure you include the VLD header as the absolute very first header of your complete program.
2. Make sure that if VLD is a library, it is loaded as the very first library of your complete program.

While I don't think Qt is free of memory leaks, I don't think it contains 2400+ leaks. That's madness.