|
From: Guilherme L. <li...@fn...> - 2003-08-05 22:44:32
|
Hi,
I am using valgrind 1.9.6 to analyse a small program:
----------------
1 #include <string>
2 using std::string;
3 int main() {
4 string leak("Does this cause a memory leak?");
5 string* ok = new string("This does not cause any memory leaks");
6 delete ok;
7 return 0;
8 }
-----------------
The commands:
> g++ -g -o test test.cpp
> valgrind --leak-check=yes --show-reachable=yes ./test
Shows:
----------------
...(removed)...
==3406== LEAK SUMMARY:
==3406== definitely lost: 0 bytes in 0 blocks.
==3406== possibly lost: 0 bytes in 0 blocks.
==3406== still reachable: 1920 bytes in 1 blocks.
==3406== suppressed: 0 bytes in 0 blocks.
----------------
The traceback points to line 4 in test.cpp source file.
The questions are:
1) Does "still reachable" report a real memory leak?
2) Do "definitely lost" and "possibly lost" reports
always mean memory leaks?
3) Are there situations when "possibly lost" does not
come from a memory leak? If so, can someone post
a code snippet where such a situation has been
isolated?
Thanks,
Guilherme
|
|
From: Jeremy F. <je...@go...> - 2003-08-06 00:15:35
|
On Tue, 2003-08-05 at 15:44, Guilherme Lima wrote: > 1) Does "still reachable" report a real memory leak? I'm pretty sure this is a FAQ. The c++ library holds onto references to things, even after you call delete on them. So it isn't really a leak (especially since there's still a reference to the memory; no reference means "definitely lost"). > 2) Do "definitely lost" and "possibly lost" reports > always mean memory leaks? "Definitely lost" means that Valgrind couldn't find a pointer to the memory. It is possible to hide references which would confuse Valgrind, but its rarely a good idea. The most notorious example is using an "optimised" doubly-linked list where the forward and back pointers are xor'd together. > 3) Are there situations when "possibly lost" does not > come from a memory leak? If so, can someone post > a code snippet where such a situation has been > isolated? "Possibly lost" means that Valgrind found a pointer into the middle of an allocated block. This may or may not mean that the program knows how to release that memory, so it may or may not be a real leak. There are plenty of legitimate uses for pointers into the middle of a block. I think the C++ compiler uses it when you're dealing with multiple inheritance. Many private allocator implementations will allocate a block, stash some info at the beginning and then return a pointer to the rest of the block. It knows how to free this because it knows the allocated block starts at ptr-N, where N is the size of its header data. J |