I get a LOT of these messages: =3D=3D16866=3D=3D 14692 bytes in 386 blocks are possibly lost in loss = record 22 of 22 =3D=3D16866=3D=3D at 0x400291E7: __builtin_new = (vg_replace_malloc.c:172) =3D=3D16866=3D=3D by 0x4002923E: operator new(unsigned) (vg_replace_malloc.c:185) =3D=3D16866=3D=3D by 0x40779242: std::__default_alloc_template<true, 0>::allocate(unsigned) in /usr/lib/libstdc++.so.5.0.3) =3D=3D16866=3D=3D by 0x4077F2A7: = std::string::_Rep::_S_create(unsigned, std::allocator<char>=20 const&) (in /usr/lib/libstdc++.so.5.0.3) That is the entirety of the stack trace. this is (obviously) a C++ program using the STL G++ version 3.2.2 Is this a real leak? if so, can I do anything about it? Thanks -- jack |
|
From: Dirk M. <dm...@gm...> - 2003-07-24 19:01:27
|
On Don, 24 Jul 2003, Jack Tavares wrote: > That is the entirety of the stack trace. No, its not. For reasons beyond me valgrind is by default limiting the stack trace to 4 levels. Thats by far too short for any nontrivial program, so better use $ export VALGRIND_OPTS=--num-callers=16 -- Dirk |
|
From: Scott H. <he...@di...> - 2003-07-24 19:13:45
|
On Thu, 24 Jul 2003, Jack Tavares wrote: > I get a LOT of these messages: > > ==16866== 14692 bytes in 386 blocks are possibly lost in loss record 22 > of 22 > ==16866== at 0x400291E7: __builtin_new (vg_replace_malloc.c:172) > ==16866== by 0x4002923E: operator new(unsigned) > (vg_replace_malloc.c:185) > ==16866== by 0x40779242: std::__default_alloc_template<true, > 0>::allocate(unsigned) in /usr/lib/libstdc++.so.5.0.3) > ==16866== by 0x4077F2A7: std::string::_Rep::_S_create(unsigned, > std::allocator<char> > const&) (in /usr/lib/libstdc++.so.5.0.3) > > this is (obviously) a C++ program using the STL > G++ version 3.2.2 > > Is this a real leak? > if so, can I do anything about it? Most likely not. Check Julian's notes in http://developer.kde.org/~sewardj/docs-1.9.5/FAQ.txt Question 14. The STL uses its on memory pool which annoys valgrind. There are some suggestions in the FAQ for stopping that behavior, but my suggestion is just to grep it away. Let's just hope that the answer is the same for Xerces' implementation of DOMStrings. :-O > Thanks > -- > jack Scott |