On Sunday, 12 May 2013 at 11:27:15 UTC, maarten van damme wrote:
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?
Calling GC.free should not be neccessary as the data will still
be collected. The destructor of TrueImageColor beeing called
does not mean the Array with the Image Data gets collected. Are
you Sure that TrueColorImage is the only class holding a
reference to the data? Do you take a slice of the data somewhere?
2013/5/12 Benjamin Thaut <c...@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<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<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
