Margarita, I am not a Debian developer, but do have some advice about your leak report.
I am only familiar with valgrind, not leaktracer or ccmalloc. However, reading the valgrind results, the report indicates reachable memory, not a leak: >==19195== LEAK SUMMARY: >==19195== definitely lost: 0 bytes in 0 blocks. >==19195== possibly lost: 0 bytes in 0 blocks. >==19195== still reachable: 1280 bytes in 1 blocks. Reading the valgrind FAQ[1], Q14, you'll see that (quoting)... Q14. My program uses the C++ STL and string classes. Valgrind reports 'still reachable' memory leaks involving these classes at the exit of the program, but there should be none. A14. First of all: relax, it's probably not a bug, but a feature. Many implementations of the C++ standard libraries use their own memory pool allocators. Memory for quite a number of destructed objects is not immediately freed and given back to the OS, but kept in the pool(s) for later re-use. The fact that the pools are not freed at the exit() of the program cause valgrind to report this memory as still reachable. So, you aren't seeing anything unusual at all. The valgrind FAQ (and indeed, the GCC manual[2]) describe memory pooling and how you can disable it. I suggest that you consult them for more information, and close this bug if you are satisfied with this response. Thanks, - Jeremy [1] http://valgrind.kde.org/faq.html [2] http://gcc.gnu.org/onlinedocs/libstdc++/20_util/allocator.html#forcenew