CODEWITHSUNDEEP
memory-leaksvalgrind
Martin G
Martin G

Reputation: 18119

Valgrind possibly lost memory

When running valgrind with --leak-check=full the generated reports include information about memory "possibly lost".

There is some information on this in the valgrind manual, as well as some example reports.

http://valgrind.org/docs/manual/mc-manual.html

LEAK SUMMARY:
   definitely lost: 4 bytes in 1 blocks
   indirectly lost: 0 bytes in 0 blocks
     possibly lost: 0 bytes in 0 blocks
   still reachable: 95 bytes in 6 blocks
                      of which reachable via heuristic:
                        stdstring          : 56 bytes in 2 blocks
                        length64           : 16 bytes in 1 blocks
                        newarray           : 7 bytes in 1 blocks
                        multipleinheritance: 8 bytes in 1 blocks
        suppressed: 0 bytes in 0 blocks

In my own system, i get plenty of "possibly" lost memory when executing my multi-threaded test binary with valgrind.

What exactly does it mean that valgrind reports memory as "possibly lost"? Was it lost or wasn't it in this particular execution. Memory leakage should be more black and white than "possibly lost" in my opinion.

Upvotes: 0

Views: 2675

Answers (1)

Paul Floyd
Paul Floyd

Reputation: 6946

Roughly the categories are

  • Still in use = there is a live pointer to the memory at exit
  • Definitely lost = there are no live pointers to the memory
  • Indirectly lost = there are pointers to the memory but the pointers themselves are in "definitely lost" memory.
  • Possibly lost = there is a pointer but not the start of the memory.

The main reasons that Valgrind will detect possibly lost are either

  1. Some junk pointer that accidentally points into the block. You should consider this as a definite loss.
  2. A memory manager that allocates sub-blocks or guard bands.

So as a rule, if you are not using a memory manager, consider your possible losses as definite ones.

Upvotes: 2

Related Questions