Question

I found the question “Is anyone using Valgrind and Qt?“, and while that seemed to clarify a few things, I found that the information it held could still a complimentary question. What I’d like to know is why – when I debug my application (with Qt, in particular) – I cannot see references to functions that I’ve created? Instead, I find tons and tons of information from lower APIs (such as Qt) which seem to have LOTS of memory leaks. Does this mean that my application is void of any memory leaks, or does it mean that there’s so much information regarding memory leaks that it targets the lower level APIs first, and then chooses to move on to the higher level code?

I ran my valgrind executable with the following flags:

valgrind  --leak-check=full  --show-reachable=yes -v ./HelloGL 

Also, what the hell is up with this?

ERROR SUMMARY: 925 errors from 899 contexts (suppressed: 29 from 7)

Pastebin.

Answer 1

I think that your problem is that the call tree is very deep. You can adjust the depth reported using:

--num-callers=<number> [default: 12]

Specifies the maximum number of entries shown in stack traces that identify program locations. Note that errors are commoned up using only the top four function locations (the place in the current function, and that of its three immediate callers). So this doesn’t affect the total number of errors reported.

The maximum value for this is 50. Note that higher settings will make Valgrind run a bit more slowly and take a bit more memory, but can be useful when working with programs with deeply-nested call chains.

Whether the problems are internal to Qt or are provoked by your usage of Qt is difficult to answer. However, when the call traces don’t reach back to your code, it becomes very difficult to identify where the problem really is. On the whole, you should assume it is more likely your code than Qt that is at fault.

Regarding the error summary: valgrind spotted 954 errors in total. However, 29 of those were from functions that are known to cause problems so the error messages were suppressed. In fact, those 29 problems occurred in seven locations (functions, contexts) known to cause the problems. The other 925 errors were not suppressed, meaning they either came from your code, or are newly found, never spotted before errors in system code. There were 899 separate contexts for those errors (so there were lots of different places causing trouble, with very few repeats). A context is a fragment of the calling chain (of functions making a particular error) that is recorded. So, there were lots of problems identified. You just need to be able to see which of your functions triggered those problems.