Huge memory leak related to Waveform Chart

[Jenso]

Hello guys,

I desperately need help to fix a weird memory bug of one of our production machines. The related test software basically loads vis containing test steps in sequential order into a subpanel to test our products. Each test step contains diagrams and indicators and performs hardware interaction.

Now everything runs fine, until at a random number of executions (roughly all 25 executions) execution of some test step parts rises from 0,01 s to up to 30 s. The memory consumption of the application or the development system (same problem occurs in build as in development environment) rises extremely. In development system the memory rises within 1-2 seconds from 500 MB to 2000..3000 MB or even higher. When loading the next test step, the execution time drops again. Executing the same test step vi in the next sequence makes everything run normal again.

I have tracked down the issue to some reference problems that I have been able to get rid off. Everything got better but memory still keeps rising to 1500 MB. It seems to be caused by the Waveform Graph property nodes or its references in the following screenshots. Unfortunately I am not able to post the whole project, so I hope you can give me a hint what I am doing wrong or where I can start searching.

I am using Labview 2014 32 Bit SP1 on Windows 10.

Unfortunately Production is not possible right now with these bugs, so I would be very grateful if you could help me!

Thanks in advance!

Best Regards

[thols]

If you are certain that the leak happens there, you could try doing one property at a time to see which one leaks. Then disable that property node and see if the leak persists.

You don't need to close that reference to the control, although I understand you do if you have a leak and am searching for it. See http://www.ni.com/tutorial/14393/en/.

Perhaps DETT can show something.

[Henrik_Volkers]

I'm not shure how the history length is handled.

If the history length is set to 1024 and you feed with parts of wfrms (say each 500 points type DBL) .. maybe 1024 times 500 points will be stored?  

Put in your numbers ... maybe that is an explanation?

[thols]

If you use DETT, those huge (or many) memory allocations should be able to filter on.

[Jenso]

Thanks for the quick replies!

The waveform chart is only fed with three points at each sample. Also the memory does not rise significantly during normal process (plus minus 1 MB). So I doubt that this is the root cause.

I will try to split up those property nodes to find the exact property causing this issue. Hopefully I will know more then..

[RTSLVU]

I know it's not the cause but you don't need those single frame Flat Sequence structures around your property nodes.

Remember, nothing can execute until all input conditions are met.

So the Error Cluster is all you need in this instance to force sequential operation.

[Jenso]

Yeah I know. That frame was only added during debugging, to ensure the point of time when the reference is generated. Just to make this simple and sequential...

Edit: Sorry I accidentially hit the "Accept solution" button instead of the "Reply" button...

[crabman]

Hi Jens

just a guess but does the leak persist, if you use a graph instead of a chart?

[natasftw]

Given you're creating a reference to a control in that same VI, wiring it into 1 or 2 property nodes, and closing the reference, it doesn't appear you have any immediate desire to port this to a subVI and work on references from other VIs.

If you replace the references by creating a property node with a right-click->create->property node, do you see the same behavior?

With what you've shown, it's unlikely anyone can help.  There's potentially something here or it could be a red herring.  Without being able to run it, we won't be able to do much other than provide the suggestions you already have here (disable properties one at a time, change the property node type in order to eliminate one input/output pair)

[Jenso]

Thanks for all the answers. Unfortunately I cannot provide any news so far. I am currently fighting to tame the desktop execution trace toolkit, which absolutely blows my mind with all the information recorded. But it looks like the DETT does not record VIs that are loaded into the subpanels... Or am I doing something wrong?

Unfortunately testing is hard, because the bug can appear after 50 units or even later... everytime I am happy that I made it, I get disappointed. One unit test takes about 2-3 minutes 8). I will keep you up to date as soon as I know more.