On Sun, 2005-06-26 at 08:37 +0200, Ralf Stephan wrote:
I will try to reproduce it but first want to do the more visible ones.
OK.
ralf
==11587== 84120 bytes in 5 blocks are possibly lost in loss record 436 of 472 ==11587== at 0x3414A733: operator new(unsigned) (vg_replace_malloc.c:132) ==11587== by 0x34EAEA5A: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned, int&) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x34EAE96C: std::__default_alloc_template<true, 0>::_S_refill(unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x34EAE667: std::__default_alloc_template<true, 0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x34EB3FF7: std::string::_Rep::_S_create(unsigned, std::allocator<char> const&) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x34EB40CD: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x34EB1CEC: std::string::reserve(unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x34EB21F1: std::string::append(char const*, unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x344EB04F: Glib::ustring::operator+=(unsigned) (in /usr/lib/libglibmm-2.4.so.1.0.13) ==11587== by 0x8164DC2: sp_string_read_content(SPObject*) (sp-string.cpp:147) ==11587== by 0x8164C63: sp_string_build(SPObject*, SPDocument*, Inkscape::XML::Node*) (sp-string.cpp:106) ==11587== by 0x8151D9D: sp_object_invoke_build(SPObject*, SPDocument*, Inkscape::XML::Node*, unsigned) (sp-object.cpp:668)
This would tend to suggest that SPString::string's destructor isn't being called... but it should be... is the SPString itself getting leaked perhaps?
[ actually, if we're leaking entire documents after close like some suspect, that would do it... ]
==11587== 120616 bytes in 303 blocks are possibly lost in loss record 444 of 472 ==11587== at 0x3414A733: operator new(unsigned) (vg_replace_malloc.c:132) ==11587== by 0x34EAE5F8: std::__default_alloc_template<true, 0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x834279F: _ZNSt6vectorIN5Shape8dg_pointESaIS1_EE20_M_allocate_and_copyIN9__gnu_cxx17__normal_iteratorIPKS1_S3_EEEEPS1_jT_SB_ (stl_alloc.h:232) ==11587== by 0x833EB9C: std::vector<Shape::dg_point, std::allocatorShape::dg_point >::operator=(std::vector<Shape::dg_point, std::allocatorShape::dg_point > const&) (stl_vector.h:363) ==11587== by 0x83393DC: Shape::Copy(Shape*) (Shape.cpp:264)
AHHH... this is the livarot leak I've been suspecting for so long. I'm not quite sure of the cause yet though...
-mental