LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Memory leak when cloning VIs

(LabVIEW 7, Windows XP Prof.)

In an application under development I generate graph displays during run-time by cloning a graph.vi. One problem I have run into though is that whenever a clone has been created the application allocates additional memory and not all of this extra memory is deallocated when the clone is destroyed. So - everytime a clone has been created the memory footprint
growns...and destroying the clones does not reduce it back to the original size....there is a memory leak that eventually will cause a problem.

To illustrate the problem I have made a simple clonemaker application and a clone. Launch the clonemaker and start monitoring it's memory use (using e.g. task manager). Now create a clone by pressing the cr
eate clone button. The memory increases, so far everything as expected. Now close the clone...you would now expect the memory to drop back to what it was before the clone was created, but no..it has increased slightly.

Now try creating e.g. 100 clones and then
close them all again. On my computer the memory footprint has now increased by 2MB, even though
all the clones have/should have been released from memory!

The clones allocate a block of memory by initializing an array just to better visualize that
that memory is in fact released when the clone is destroyed...but for some reason not all memory. As far as I can see this should not be a VI reference related leakage, I think all references are disposed of correctly.

Can anyone explain this / modify the main or clone so that the memory leak disappears?
0 Kudos
Message 1 of 6
(3,427 Views)
Mads,
Thats an interesting one. I took a look at it and I also saw the memory increase, however I had one question. Why are you cloning the VIs as copies, rather than using a VI template? Does the same behavior occur with the templates? Either way I would suggest e-mailing NI at ni.com/ask.
0 Kudos
Message 2 of 6
(3,427 Views)
I have sent it twice to NI from the support -> e-mail an NI engineer page, but that does not seem to work from Norway. I was then asked by web support to e-mail it from the ni.com/ask page...just did:-)

To your question; in the real application I at one point chose to copy the VIs to better have control over the names of the clones (and at the time I started doing this some people also questioned whether the .vit trick would be supported in future LV versions...). I put the input data to the clone in a global and the clone gets it's data from that global by requesting it using it's name as reference...(the set control value property is unfortunately not supported in built applications so I have to use a global).

I could make a solution using templates
(just have to tweak the way I track the clone names slightly), I have not checked whether that is free from the memory leak.I'll do that and post the result here...

Using copies should still be possible without having leaks though...
0 Kudos
Message 3 of 6
(3,427 Views)
When talking about globals I really mean a functional global...it has the input data to each clone linked to the name of the clones. I use it also to have control of how many and what active clones there are at any given time.
0 Kudos
Message 4 of 6
(3,427 Views)
Now I've tested it using the template technique and there is no difference, there is a huge memory leak when calling VIs dynamically like this. As the attached graph shows the leakage seems to stop after 200 calls. With the simple example VIs the memory increase is a couple of MB...with a bigger VI the leakage is much bigger too, in my real application the leakage is about 14 MB before things start to settle down.

I've included the test application (the one the graph is based on) and the source of it as well.

Still have not heard from NI support (sent a request on ni.com/ask yesterday).
Download All
0 Kudos
Message 5 of 6
(3,427 Views)
Just to inform those interested;

NI tested this and could not narrow down the cause. It has been reported to R&D for further investigation.

If you do dynamic calls like this in your application, be aware...
0 Kudos
Message 6 of 6
(3,427 Views)