Memory leak with dynamic array

[Steven Schveighoffer]

On Tue, 13 Apr 2010 08:24:57 -0400, Joseph Wakeling  
<joseph.wakeling at webdrake.net> wrote:

> Steven Schveighoffer wrote:
>> This should work as you expect.  Can you produce a full code example?
>> Are you reserving space in x before-hand?
>
> Weird; now it works.  I wonder if because I upgraded to 2.043 ... ?  I
> understand there was a fix in there for array append.

2.043 has fixed a corruption bug, one which you are unlikely to have  
triggered with a simple program like you wrote.  However, 2.041 had a  
severe corruption bug, which any array could fall victim to.  If you  
upgraded from 2.041, it's quite possible that fixed the problem.  If you  
just upgraded from 2.042, I think this may be a case of stale  
object/binary files ;)

>
> On the other hand, if the assumeSafeAppend takes place outside the loops
> entirely, blow-up occurs -- because the command is not issued after the
> array resize to zero?  I've attached examples.

Yes, assumeSafeAppend must be called every time you want to overwrite  
memory.  The runtime cannot tell if you still have references to the  
memory that was in use you don't want to be changed by appending to the  
header.  So it makes a conservative decision, "hey, this memory was in  
use, I'm not sure if it's in use anymore, so I'll reallocate rather than  
stomp on it."  assumeSafeAppend tells the runtime "yes, it was in use, but  
I'm no longer using it, so it is safe to stomp on it."  However, you only  
have to call it once per loop, because a single assumeSafeAppend assumes  
the remainder of the memory block after the array you pass as an argument  
to assumeSafeAppend is ok to stomp on.

-Steve