Re: Freeing xalloc'ed array

[Paolo Carlini <pcarlini at suse dot de>]

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.