| Showing reachable and possibly lost blocks for Valgrind Memcheck [message #1741526] |
Thu, 25 August 2016 11:54  |
Eclipse User |
|
|
|
Hi,
I'm trying to understand some of the UI fields in the Memcheck tab for Valgrind Memcheck. Your 'show reachable blocks' description states:
"Configures whether or not Memcheck should report blocks it could not find a pointer to during leak detection. This is disabled by default (i.e. do not report blocks with undetermined pointers)."
First, does the checkbox map to the 'show-reachable' command-line argument or does it do something different?
Second, the description sounds more like *un*reachable blocks, which are those for which no pointers are left (although I'm not sure what's meant by "undetermined pointers"). This is based on my understanding of section 4.2.8 of the Valgrind User Guide, found on the Valgrind website. (For some reason, I can't post the link to valgrind.org here.)
Also, in the version of Eclipse I'm using, the Memcheck tab has additional fields that aren't shown in the wiki screenshot. One such field is 'show possibly lost blocks in leak check'. Does this map to the 'show-possibly-lost' option?
Thanks.
|
|
|
| Re: Showing reachable and possibly lost blocks for Valgrind Memcheck [message #1741549 is a reply to message #1741526] |
Thu, 25 August 2016 14:40  |
| Eclipse User |
|
|
|
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 16:35 |
| Eclipse User |
|
|
|
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.03915 seconds
Home