CODEWITHSUNDEEP
qtmemory-leaksvalgrindmemcheck
FrozenTarzan
FrozenTarzan

Reputation: 884

Why does valgrind produce multiple (almost) similar leak summaries?

I run valgrind version 3.12.0 from the console like this:

valgrind --log-file="valgrind.log" --leak-check=yes ./application -param

The log seems to be polluted while the application is running which is interesting already because I don't think that a memory leak can be detected with 100% certainty while the application is still running. I guess that in some scenarios (maybe threads) this is not true and valgrind is clever enough to catch those early on?

What really bothers me is that there are multiple "leak summaries" which contain more or less the same information. It seems to me that summaries logged at later stages contain more information.

Below you will find an output of valgrind executed on my Qt application. I used Notepad to list all "definitely" lost entries. You can see that there are tons of leak summaries and I don't know why the contained information is almost the same. Especially the 15 bytes leaked from the constructor of the QApplication is very strange since it is contained in every summary again and again. How does valgrind decide when to create such a summary?

enter image description here

Upvotes: 1

Views: 912

Answers (1)

Paul Floyd
Paul Floyd

Reputation: 6936

One of the design goals of Valgrind is to not produce false positives (i.e., never incorrectly indicate a problem). On the whole it comes very close to this. Almost certainly you have a leak. I recommend that you do a debug build and look at the source code backreferences to debug the issue.

Leak detection is normally done when the application terminates. There are ways of triggering leak reports earlier:

  • Using the gdbserver commands, you can trigger leak_check
  • Using Valgrind client commands you can trigger VALGRIND_DO_LEAK_CHECK (there are several similar commands)

Possibly you are using the second of these.

Lastly, 'almost the same' means that they are different. You could reduce the stack depth, which would make it more likely that callstacks will be grouped together.

During execution, Valgrind will output non-leak errors as they occur.

On termination, Valgrind outputs:

  1. Unloaded shared libraries (verbose mode)
  2. HEAP SUMMARY - how much memory still in use, allocated and freed
  3. LEAK SUMMARY - details on leaks found
  4. ERROR SUMMARY
  5. Callstacks of errors. For non-leak errors this will duplicate the previous messages, though contexts get aggregated with the occurrence count.
  6. Used suppressions (verbose mode again I think)
  7. ERROR SUMMARY again

Upvotes: 1

Related Questions