I tried using gc.malloc and gc.free but got an invalidmemoryoperation exception when doing gc.free(data.ptr);

Simply using gc.malloc like you proposed, the memory keeps growing. Is this a bug in the d garbage collector?

What's really strange though, is that the destructor of trueimagecolor (the class allocating the buffer) is getting called everytime...

Does this mean that a destructor getting called still is no garantee that all data is getting free'd?

2013/5/12 Benjamin Thaut <code@benjamin-thaut.de>

Am 11.05.2013 01:18, schrieb maarten van damme:

I'm trying to generate images and after displaying them I want to save
them to a png file. I use parallelism to generate them asynchronously
with the gui-thread to avoid blocking (don't know if this is really
relevant).

If I add a single line in the method where I generate the image that
creates a class which allocates a pretty big array, slowly but surely
the memory starts to rise until it ends in a spectacular out of memory
exception. I always thought the garbage collector would deal with it.

I tried reducing it but failed. Maybe I should let dustmite bite in it a
bit later.
How can I manually fix this? Is this a known bug in the garbage collector?

btw, this code also caused segfaults on my 64 bit laptop on linux.
How can I avoid this?

main class:
https://dl.dropboxusercontent.com/u/15024434/picturegenerator/generalised.d

zip file with everything ready to go to compile:
https://dl.dropboxusercontent.com/u/15024434/picturegenerator/picturegenerator.zip

Try allocating the big array with:

import core.memory;

size_t imageSize = 1024*1024*3;
auto imageData[] = (cast(ubyte*)GC.malloc(imageSize , GC.BlkAttr.NO_SCAN)[0..imageSize];

Which will result in the big memory block not beeing scanned by the GC which should reduce the number of false positives during collection.

If this doesn't work, use malloc / free of the c standard library to allocate and free the image data.

Kind Regards
Benjamin Thaut