I saw that valgrind classifies memory leaks into:
- definitely lost
- indirectly lost
- possibly lost
- still reachable
- suppressed
I just fixed a leak where the “possibly lost” was the main problem.
The documentation says: “possibly lost means your program is leaking memory, unless you’re doing unusual things with pointers that could cause them to point into the middle of an allocated block; see the user manual for some possible causes“
May I please know an example of “doing unusual things with pointers that could cause them to point into the middle of an allocated block” ?
I mean an example where “possibly lost” can be ignored although it is reported by valgrind. An example in which the use of pointers makes valgrind complain but at the same time the use of the pointers in that way is somehow legitimate
Thank you
Some examples of what the documentation are different libraries that have their own allocators and for which the memory returned is not directly the pointer returned by the underlying OS allocator (malloc/sbrk), but a pointer after an offset. Consider for example, an allocator that obtained some extra memory and stored meta information (maybe type information for a garbage collector…). The process of allocation and deallocation would be similar to:
When valgrind is tracking the memory, it remembers the original pointer that was returned by
malloc, and that pointer is not stored anywhere in the program. But that does not mean that the memory has been leaked, it only means that the pointer is not directly available in the program. In particularmemorystill holds the returned pointer, anddeallocatecan be called to release it, butvalgrinddoes not see the original returned pointer at location(char*)memory - sizeof(metadata_t)anywhere in the program and warns.