|
| Re: Showing reachable and possibly lost blocks for Valgrind Memcheck [message #1741549 is a reply to message #1741526] |
Thu, 25 August 2016 18:40   |
 Jeff Johnston
Messages: 215
Registered: July 2009 |
Senior Member |
|
|
Yes, the checkbox maps to --show-reachable and the 2nd one does map to --show-possibly-lost.
While I did not write the passage, I believe the description when referring to "a pointer" means finding a start-pointer or chain of start-pointers to the block. See the Still reachable leak kind below which would be set for --show-reachable enabled but not for the option disabled.
From the manual for --leak-kinds:
"Still reachable". This covers cases 1 and 2 (for the BBB blocks) above. A start-pointer or chain of start-pointers to the block is found. Since the block is still pointed at, the programmer could, at least in principle, have freed it before program exit. "Still reachable" blocks are very common and arguably not a problem. So, by default, Memcheck won't report such blocks individually.
"Definitely lost". This covers case 3 (for the BBB blocks) above. This means that no pointer to the block can be found. The block is classified as "lost", because the programmer could not possibly have freed it at program exit, since no pointer to it exists. This is likely a symptom of having lost the pointer at some earlier point in the program. Such cases should be fixed by the programmer.
"Indirectly lost". This covers cases 4 and 9 (for the BBB blocks) above. This means that the block is lost, not because there are no pointers to it, but rather because all the blocks that point to it are themselves lost. For example, if you have a binary tree and the root node is lost, all its children nodes will be indirectly lost. Because the problem will disappear if the definitely lost block that caused the indirect leak is fixed, Memcheck won't report such blocks individually by default.
"Possibly lost". This covers cases 5--8 (for the BBB blocks) above. This means that a chain of one or more pointers to the block has been found, but at least one of the pointers is an interior-pointer. This could just be a random value in memory that happens to point into a block, and so you shouldn't consider this ok unless you know you have interior-pointers.
|
|
|
|
| Re: Showing reachable and possibly lost blocks for Valgrind Memcheck [message #1741818 is a reply to message #1741558] |
Mon, 29 August 2016 20:35 |
Jeff Johnston
Messages: 215
Registered: July 2009 |
Senior Member |
|
|
Nicholas Lamb wrote on Thu, 25 August 2016 15:58Yes, I had the same interpretation about the term 'pointer' meaning a start-pointer or chain of pointers. But I'm still confused by the second sentence in their definition for the 'show reachable blocks' UI field: "This is disabled by default (i.e. do not report blocks with undetermined pointers)."
When the box is unchecked, we should NOT see reachable pointers, meaning 'do not report blocks with start-pointers or chains of pointers". It's the "undetermined" term that's throwing me. That particular wiki page hasn't been updated since 2013, so perhaps one of the authors would know?
Now, the Valgrind User Manual states that by default, definite and possible leaks are reported. But in the UI, the "Show possibly lost blocks" is unchecked by default. This suggests that when invoked through Eclipse, Memcheck does default leak-reporting differently than when invoked from the command-line--is this so?
Looking at the code, I found a problem. Seems there was an old bug for this problem already:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=383516
There is an issue with the show-possibly-lost default. The show-possibly-lost value is only specified when different from the default so right now, it is not specified if the check-box is unchecked and only specified to yes if the check-box is checked.
I have taken the bug and will fix the default to be true. I will also fix the documentation which currently doesn't mention the show possibly lost option. I will make it match the valgrind user guide.
|
|
|
|
Powered by
FUDForum. Page generated in 0.01781 seconds
] 
Search
Help
Register
Login
Home
