QT Memory Leaks

[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.

[SixDegrees]

I'm fairly sure that Qt does a lot of it's own memory management, bypassing malloc and new. This is certainly true for QStrings, which do a lot of referencing to avoid unnecessary data copies. Unfortunately, this sort of optimization hoses most leak checkers; a lot of them simply match calls to malloc/free or new/delete and note when there's an imbalance.

Since the number of leaks appears to be constant, rather than increasing with program load, I'd guess this is the case. See if your program actually consumes an increasing amount of memory over time and with increasing program load. If not, these reports can probably be safely ignored. I don't know what sort of tools are available for this under Windows; the Task Manager is notorious for giving bogus memory usage reports.

Note, too, that you may have to build Qt in debug mode in order to get the most useful information out of these tools; in release mode, they'll tend to be accurate, but not precise.