kuckuck's picture

CLOO 0.7 Memory Leaking

Hello everyone!

First of all I'd like to say "thank you !!!" for creating Cloo which I just started to use for the Creation of Voigt-Profiles (e.g. relevant for the absorption spectroscopy).
Unfortunately my program has a major memory leak (quickly growing to infinity) and unfortunately again that memory leak is present even in the VectorAdd example. It becomes obvious by just introducing a for-loop:

/////taken from VectorAdd
 
for (int i = 0; i < 1000; i++)
{
                commands.Execute(kernel, null, new long[] { count }, null, events);
 
                arrC = new float[count];
                GCHandle arrCHandle = GCHandle.Alloc(arrC, GCHandleType.Pinned);
 
                commands.Read(c, false, 0, count, arrCHandle.AddrOfPinnedObject(), events);
                commands.Finish();
 
                arrCHandle.Free();
 }

Executing the program stepwise and looking in the Task Manager I find That cammands.Finish() is the step where memory is lost (between a few kb and up to 2MB).
I'm running this using 64bit Windows 7 with Ati Stream (newest version) on a Corei5, Hd5850.

Has anyone a idea what's causing the trouble?

Thank's a lot,
Jan


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kuckuck's picture

UPDATE 1:

I've meanwhile tryed using the updated Cloo Version from the recent Thread http://www.opentk.com/node/1541 .
Using that version I can confirm, that there is no memory leak present using my Voigt-Profile Code.

UPDATE2:

Using Cloo with Cuda drivers on my Macbook running Windows 7 32bit, CLOO 0.7 is running just fine, no memory leak present.

nythrix's picture

That's a feature :)
You are constantly collecting events inside the loop. Yes memory usage goes up, but that's because the events list is growing bigger.
If you're not into complex computations with many command queues synchronizing the world then omit the event list (pass null).
Or clean that up from time to time.

kuckuck's picture

Hi Nythrix!

Thank you very much for your reply! It's a feature indeed, if you know how to use it!!
Funny though, that the feature's side effects didn't show up using a nVidia drivers ;).

Jan

nythrix's picture
Quote:

Funny though, that the feature's side effects didn't show up using a nVidia drivers ;).

Are you definitely sure it's the same code? I know it sounds stupid but you might be editing a piece of code and running another one. Happens to me from time to time.

Glad to hear it's working on Mac too. I had no such feedback until now!

kuckuck's picture
nythrix wrote:

Are you definitely sure it's the same code? I know it sounds stupid but you might be editing a piece of code and running another one. Happens to me from time to time.

Glad to hear it's working on Mac too. I had no such feedback until now!

Sorry for not responding immediately. I doublechecked everything and can confirm positively that I use the same code with both drivers.
I am not quite sure how to use those events and therefore cannot present any testing, yet. But shouldn't this indicate, that event callbacks may not work properly using nVidia drivers? At least it seems like something is getting "lost".

Anyway, this does rather looks like there's something going wrong in the openCl implementation on either AMD's or nVidia's side and not like a Cloo problem, as the OpenCL.dll's should behave equivalently and as far as I know, that's all that's being used by Cloo.

douglas125's picture

Maybe ATI Drivers leak memory?

I have this memory leak issue too with my ATI card.

nythrix's picture

douglas can you be more specific? Are you refering to the original post?
Memory usage for the original code is supposed to grow because the list is collecting event objects.

douglas125's picture

Yes I am referring to the original post.

I use Cloo sometimes and sometimes I use direct API calls.

When I allocate and destroy very large memory objects in the GPU the program eventually crashes. I ensured I was calling the commands to destroy the objects and even then it kept crashing after a few 100+ Mb allocation and destruction.

I ended up allocating a chunk of memory and using only it.

This is why I think there might be some problem with the ATI drivers.

nythrix's picture

Well yes. The drivers are quite lacking so far. They're error prone even under light operation, let alone heavy load. But I think the weakest parts are the compilers. They sometimes crash (I mean acess violation, not a CL exception) taking the app with them or even successfully compile a bad program (!) which can blow kernel creation (if you're lucky) or block the whole system upon execution (if you're not).

You might want to check http://sourceforge.net/projects/cloo/forums/forum/1048266/topic/3656879 a quite interesting discussion about stress testing the memory manager of OpenCL with Cloo.