This should be an expected consequence of disabling garbage collection.
A shame I had to be told this ;)
You will simply have to ignore leaks where you see an allocator taking Inkscape::GC::ScanPolicy or Inkscape::GC::CollectionPolicy in the call chain. It should be possible to write a suppression profile to do this.
That would be this one: { GC_malloc Addrcheck:Leak fun:malloc fun:_ZnwjN8Inkscape2GC10ScanPolicyENS0_16CollectionPolicyEPFvPvS3_ES3_ }
Note that most Inkscape subsystems do not use the garbage-collected heap, so you can still get useful results for other memory.
So I did. The two most leaky blocks are appended below. I still have to get more familiar with the code to send a patch for these.
Incidentally, while it's good to solve memory leaks, the problem I've been trying to diagnose is the one in this bug: http://sourceforge.net/tracker/index.php?func=detail&atid=604306&aid... The problem, if you can track it down, should manifest (unfortunately probably only very intermittently) as an invalid write to freed memory.
I will try to reproduce it but first want to do the more visible ones.
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) ==11587== ==11587== ==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) ==11587== by 0x82B16DB: nr_arena_shape_update_stroke(NRArenaShape*, NRGC*) (nr-arena-shape.cpp:564) ==11587== by 0x82B202A: nr_arena_shape_render(NRArenaItem*, NRRectL*, NRPixBlock*, unsigned) (nr-arena-shape.cpp:660) ==11587== by 0x82AD103: nr_arena_item_invoke_render(NRArenaItem*, NRRectL const*, NRPixBlock*, unsigned) (nr-arena-item.cpp:658) ==11587== by 0x82AEEF6: nr_arena_group_render(NRArenaItem*, NRRectL*, NRPixBlock*, unsigned) (nr-arena-group.cpp:198) ==11587== by 0x82AD103: nr_arena_item_invoke_render(NRArenaItem*, NRRectL const*, NRPixBlock*, unsigned) (nr-arena-item.cpp:658) ==11587== by 0x82AEEF6: nr_arena_group_render(NRArenaItem*, NRRectL*, NRPixBlock*, unsigned) (nr-arena-group.cpp:198) ==11587== by 0x82AD103: nr_arena_item_invoke_render(NRArenaItem*, NRRectL const*, NRPixBlock*, unsigned) (nr-arena-item.cpp:658)