Freeing xalloc'ed array

[Paolo Carlini]

Akim Demaille wrote:

>== 72 bytes in 1 blocks are still reachable in loss record 1 of 1
>==    at 0x1B9052D9: operator new[](unsigned) (vg_replace_malloc.c:139)
>==    by 0x1B9678D3: std::ios_base::_M_grow_words(int) (in /usr/lib/libstdc++.so.5.0.7)
>==    by 0x80489F5: std::ios_base::iword(int) (in /tmp/a.out)
>==    by 0x8048850: main (in /tmp/a.out)
>==
>== LEAK SUMMARY:
>==    definitely lost: 0 bytes in 0 blocks.
>==    possibly lost:   0 bytes in 0 blocks.
>==    still reachable: 72 bytes in 1 blocks.
>==         suppressed: 0 bytes in 0 blocks.
>
>If it is not considered as a bug, what can I do to address this issue?
>
In general, consider that we are talking about **reachable** memory, which
can be easily dealt with by the OS at exit time. You will see this kind 
of ""leak""
very often, in pooled memory allocators, for instance (see a recent 
brief exchange
with Matt Austern and Benjamin about why this is a *good* thing, in general)

More specifically, there is this comment in ios_base.h that explains why you
are seeing it (note that you are calling iword on cout, a standard stream):

    // Destructor
    /**
     *  Invokes each callback with erase_event.  Destroys local storage.
     *
     *  Note that the ios_base object for the standard streams never gets
     *  destroyed.  As a result, any callbacks registered with the standard
     *  streams will not get invoked with erase_event (unless copyfmt is
     *  used).
    */
    virtual ~ios_base();

Honestly, I don't think this is a very troublesome issue...

Paolo.