Bug#224735: not a leak

[Jeremy Nimmer <jwnimmer@alum.mit.edu>]

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