1

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

FrozenTarzan
  • 834
  • 10
  • 30
  • It looks like the process id in each report is different. Possibly the reports are from forked off processes that died without exec·ing another program. – textshell Jul 28 '19 at 19:07

1 Answers1

1

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
Paul Floyd
  • 5,530
  • 5
  • 29
  • 43
  • Hi Paul, you are right, I have a leak that's why I'm using valgrind ;-) 1. I have not heard about gdbserver commands and the "triggers" you are talking about. I use valgrind in the stated version with the stated command. Why should I change that, no one mentions such options anywhere else? 2. The question is why there are multiple "summary" reports when everyone talks about "THE" summary report at "THE END"? Could you elaborate on that part? I hope that it is clear that the reports are generated within A SINGLE execution not consecutive ones :-) – FrozenTarzan Mar 07 '18 at 11:58
  • Updated my answer. – Paul Floyd Mar 07 '18 at 14:56
  • I'm sorry, but I think that we still don't talk about the same thing. The report at the end you are talking about is printed multiple times for a single valgrind run. So I get multiple "LEAK SUMMARY"s and multiple "HEAP SUMMARY"s etc. So I get multiple blocks of this report at the end each of them showing tons of tracebacks for each possibly/definitely lost message. I expect a single traceback and a single report summary at the end. Did I misunderstand your edited answer? – FrozenTarzan Mar 08 '18 at 14:36
  • 1
    I think I see. Is your application forking? I use `--memcheck:log-file=appname_valgrind.log.%p` which generates one log file per process (at least with Valgrind 3.13, though generally I compile my own from git). – Paul Floyd Mar 08 '18 at 15:14