| Summary: | Option to ignore leaks immediately preceding program termination | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Andrew Pennebaker <andrew.pennebaker> |
| Component: | memcheck | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | wishlist | CC: | tom |
| Priority: | NOR | ||
| Version First Reported In: | 3.12 SVN | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Andrew Pennebaker
2018-11-07 04:09:39 UTC
This is, as you say quite normal, which is why memory that is still reachable at exit is not reported as a leak. Only memory that is no longer reachable is reported by default, which effectively does what you want I think. If you have explicitly asked for it then valgrind will report every block that is still allocated. I'm not the best C/C++ programmer, but I am learning about manual memory management, and I have a small example app that I believe should not require manual free(). However, valgrind is reporting that hex_buf is lost unless I free() it, even though I immediately return from main() at this point. https://gist.github.com/mcandre/1ac317f0ee1381e8609561b2b246d6fa#file-fewer-c-L92 Am I doing this correctly? Should I perhaps use exit() instead of return to indicate this more clearly to valgrind? That is lost yes because the only pointer to it is on the stack and once you exit that pointer is no longer in scope. You're right it's not strictly necessary to free that but it's a fairly unusual thing to see in real world programs because it can only really apply to things allocated by main or trivial children of main so in a program of any size that isn't things will normally work. |