|
From: Alex B. <ker...@be...> - 2007-10-02 13:01:07
|
Hi, I'm not sure if this is a known limitation for Valgrind but... I've been trying to track down some memory leaks Valgrind seems upset about. One of them is a block that is referenced by a statically allocated C++ object. If I changed the container object from: -static ObjectFileMap objectFileMap; +static ObjectFileMap *objectFileMap=0; And then dynamically allocate it when it's first referenced all the warnings about leaks for the "unreachable" blocks objectFileMap contains disappear. Is this expected behaviour? As I understand it Valgrind checks though all memory to see if any pointers (and pointers to pointers etc) exist to the allocated block. Does this include the static global variable space? -- Alex, homepage: http://www.bennee.com/~alex/ Keep out of the sunlight. |
|
From: Nicholas N. <nj...@cs...> - 2007-10-03 23:40:42
|
On Tue, 2 Oct 2007, Alex Bennee wrote: > I've been trying to track down some memory leaks Valgrind seems upset > about. One of them is a block that is referenced by a statically > allocated C++ object. If I changed the container object from: > > -static ObjectFileMap objectFileMap; > +static ObjectFileMap *objectFileMap=0; > > And then dynamically allocate it when it's first referenced all the > warnings about leaks for the "unreachable" blocks objectFileMap contains > disappear. > > Is this expected behaviour? > > As I understand it Valgrind checks though all memory to see if any > pointers (and pointers to pointers etc) exist to the allocated block. > Does this include the static global variable space? I believe it does. It's hard to know what's going on from the C++ code, because Valgrind does everything at the binary level. Presumably the C++ compiler is compiling the two versions differently, but it's hard to know if Valgrind is doing something incorrect or not. Nick |