ACBR Proxy Caller/ Memory Leak problem

[bspoka]

I am having a memory leak issue in my AF program. Basically my code is composed of a user interface actor, controller actor and a number of actors corresponding to my instruments. I have been getting this issue where If i run my program for some time I get an error saying "Not enough memory to complete this operation" - no idea what operation since a bunch of instruments are running at the same time. The whole program then freezes and I basically have to restart labview to continue. I managed to catch the time the error occured with my desktop execution wizard, but I can't make sense of the process that seems to initiate the memory leak. I attached a screenshot.

     The function that is called right before the error is "Take frame". It is a CCD camera vi which acquires a 20 megabyte image roughly 2-3 times per second. It then creates a data value reference from the acquired 2D array and passes it to the UI through the controller by firing a user event (standard) - all other instruments pass around much smaller pieces of data.  I'm thinking that somewhere in the acquire frame - create reference- fire user event- extract data from reference - display data chain something funky happens. Can anyone tell me what this ACBRproxycaller process is? Why does it call the "vi stop execution" event? Which vi is it stopping?

Any help is appreciated!

bspoka

[AristosQueue (NI)]

It is panick stopping whichever VI has run out of memory to execute.

I suspect your problem is that you are never deleting that data value reference when you're finished with it. Figure out where your Delete Data Value Reference node is located and make sure that it is called by the Actor that owns that DVR -- and if you send that DVR as a message to another Actor, make sure that other actor is properly "taking ownership" of the DVR, by which I mean that it is now responsible for calling Delete when it is done working with the DVR.

[bspoka]

Yeah, I actually delete the DVR inside my user interface actor core as soon as the user interface receives this message from my camera actor. Do you think it is better to delete the reference inside the camera actor that is generating it? Or it doesn't matter a s long as it gets deleted?

Thanks a lot!

[drjdpowell]

How many size 22118408 memory handles are released after the VI Stop Execution?  Those are your frames.

Other suggestions:

-- probe the reference going into the release DVR primitive to make sure it is getting all the references (not "0" from a reference being lost)

-- could it be something else delaying the UI reading the frames (causing the queue the back up with unprocessed frames)?

-- James

BTW, if you were starting from scratch I would suggest that, since you don't mind sharing a reference between actors, why not just share an IMAQ image reference (assuming you are using IMAQ)?

[AristosQueue (NI)]

bspoka:

I just thought of something... You are sending a message containing a DVR. This means that you are handing off ownership of the DVR from the sending Actor to the receiving Actor. It was the job of the sending actor to destroy the DVR until it sent that DVR to the receiving Actor, at which point it becomes the job of the receiving Actor.

I'm assuming from your post that you have those bases covered.

But there is a small window when the message is sitting in the queue where neither Actor has that responsibility. And if the receiving actor quits before it ever receives the message, the message never gets received so the DVR never becomes owned.

It is cases like this that we designed "Drop Message Core.vi" on the Message.lvclass. You should override Drop Message Core.vi on your message class that contains the DVR and delete the DVR in that VI. Drop Message Core.vi is called ONLY if the message is dropped because the receiver stopped before receiving the message, but it would close one potential leak. This may not be the leak that you're having problems with, but it is one that might bite you down the road, so it would be good to close it now.

[bspoka]

Thanks AQ, I'll try this. I have a related question... If my UI user event which is responsible for displaying acquired data gets fired by my camera actor, faster than the speed with which the UI processes the event, what happens to the DVRs stored in those "extra events"? Does the event structure in my UI,  queue the incoming user events somehow? Or does it simply drop any incoming events if it is busy?

Thanks!

[AristosQueue (NI)]

They queue up.

[bspoka · Accepted solution]

To anyone who is interested - the memory leak came from storing a large array in the actor's private data control. Don't do it. Basically in my program, everytime my image parameters would be changed by the user, I would allocate a new buffer array for the output image, store it in my actor and then access the preallocated array when populating the buffer with camera data. However everytime my class wire got split I would create an extra 2560x2160 array since it was in the private data - this eventually screwed everything up. Passing the buffer array through a message instead (global variable also worked), got rid of all memory leaks.

Again to any newbs like me out there!

bspoka

[David_Staab]

There is no problem with putting a large array inside an object property. This is why the In Place Element Structure exists. There are also other wiring patterns you can follow to minimize data copies...you don't have to put it in a GV.

[AristosQueue (NI)]

Glad you found your memory issue.

You're now sending the large array using a message, which should definitely work better. I think I can make it work with even fewer data copies. Try modifying the message class that sends your large array to look like the images shown below. This should cut down on another layer of copying. I know the code looks a bit non-standard and it may not be entirely obvious what's going on, but I'd like you to try it and let me know if you see an improvment, either in peak memory usage or in performance. It should be better, and I've been contemplating changing the way that the VIs get generated to use a style more like this one (I've also been chatting with the compiler team to see if the compiler can recognize cases where this applies and just do it itself).

-- AQ