how to avoid memory leaking

[maarten van damme]

I'll check every uint occurance, thank you. I'm on windows so I won't get
the "maximum number of clients" error you talk about. The loop I used
inside main was :
"while(true){
curtrans=generateTransformationMatrix();

for(int y=0;y<height;y++)
for(int x=0;x<width;x++)
i.data[(y*width+x)*4..y*width+x)*4+4]=colorify(applyTransformation(transformXY(x,y),curtrans)).dup[0..3]
~ 255;
 // and finally write the data to a png file
png = pngFromImage(i);
//std.file.write("images/"~toHexString(md5Of(curtrans))~".png",
writePng(png));
}"
This doesn't use simpledisplay anymore so this should work fine on linux
too?

Adam checks this thread so he'll probably read the errors about
simpledisplay. if not I'll copy paste and put in a bug report on github.
--

The new fixes from adam rupe for png and image.d actually get rid of all
memory leakages in my reduced version (without simpledisplay). Now I can
get to finetuning my functions for the best images :)

I'll see if the simpledisplay version now works too (leave it running
overnight).
--

So, do we actually know where the memory problems came from? is anyone
actually running out of memory too or am I the only one? (tested on both my
pc and my laptop so should be reproducible)


2013/5/13 Maxim Fomin <maxim at maxim-fomin.ru>

> On Friday, 10 May 2013 at 23:18:31 UTC, maarten van damme wrote:
>
>> 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>
>>
>
> 1) your code is not compilable on 64x system due to erroneous treating of
> some platform-varying types as uint, use size_t. Luckily dmd has -m32 switch
>
> 2) I encounter not out of memory exception but enforcement failure in
> simpledisplay.d:1024 "Maximum number of clients" which looks like not a
> memory error but you running out of some X server limit.
>
> 3) Segfault occures in simpledisplay.d:1058 - in destructor you call
> XDestroyImage(handle) but do not check whether handle is null. However it
> happens after enforcement failure so it doesn't looks like root of problem.
>
> 4) What really consumes memory is kernel or something which forces it to
> consume it since my task manager reports two blocks of 280 MB and 126 MB
> inside kernel part of virtual memory.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20130513/bdf0adf8/attachment.html>