how to avoid memory leaking

[Adam D. Ruppe]

On Monday, 13 May 2013 at 07:13:03 UTC, maarten van damme wrote:
> But seeing as the memory only starts growing when I put the png 
> line in

This is pretty strange because looking at the source there, the 
only time data is even referenced is here:

                 output ~= data[pos..pos+bytesPerLine];


Which makes a copy. There's no delegates or anything so shouldn't 
be a copied stack reference sticking around.... I see no reason 
why this wouldn't work.

I also tried replacing the new ubyte with malloc/free hoping it'd 
get an access violation if it was used after free, and nothing 
came up.

But my computer that i'm using right now is one of those netbooks 
so it doesn't have the cpu power to generate hte large images. I 
did a 200x100 instead which obviously uses way less memory. But 
still, if it was a bad reference I think it would show up here 
too.



The only other line that might be a problem is this one:
         auto com = cast(ubyte[]) compress(output);


output is at this point a copy of data, with other things added. 
So it'd be a very large array too.... and is created through the 
~= operator, so it is all gc managed. Could be a false positive 
pointing into this array causing the leak.


And the compress function, from std.zlib, does this:

     auto destlen = srcbuf.length + ((srcbuf.length + 1023) / 
1024) + 12;
     auto destbuf = new ubyte[destlen];
     auto err = etc.c.zlib.compress2(destbuf.ptr, &destlen, 
cast(ubyte *)srcbuf.ptr, srcbuf.length, level);
     if (err)
     {   delete destbuf;
         throw new ZlibException(err);
     }

     destbuf.length = destlen;



Which is again, destbuf being another large gc managed array. So 
my guess is either my output or std.zlib's destbuf is getting 
mistaken for still being referenced by some random number on the 
stack, so the gc is conservatively keeping it around.



A potential fix would be for my png.d to manually manage this 
memory - preallocate output[] with malloc and perhaps use its own 
compress function with its own manual buffer too. I figure this 
would be a new function, savePngFromImage, that saves the file 
itself instead of returning the array so it has complete control 
over the reference.