LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is this evidence of a memory leak?

Solved!
Go to solution

LabView is running an example VI supplied by the hardware manufacturing NHR for a battery simulator. After about 10 minuts of runing the memory usage is increasing at a steady rate. In the attached picutre, the black circle is memory usage at startup and the red cicle is the memory usage after 10 minutes. After about an hour the memory usage is over 500k. 

nhr memory leak.PNG

 

I bit more on the background of this project. The NHR code was originally part of a much larger project. The issue would arise after the code was running for approximetly 36 hours and then crash. Troublshooting showed that RAM and SWAP usage was high before crashing. Then through trial and error it was found that removing the NHR code fixed the crashing issue. The above is from Isolating the issue further. By running the supplied NHR example labview code and it shows the memory usage is increasing. 

 

I would like to reach out to NHR about the issue, but I want to get an expert optinion on the situation. Is there anything we can do about it? I buitl the sample vi code into a source distribution. Let me know if this would help and i can attach as needed. 

 

Thanks in advance. 

Damian
0 Kudos
Message 1 of 11
(4,211 Views)

Evidence? Maybe.

 

Proof? Not neccesarily.

 

If the example has a Chart with a large history buffer, the chart can be filling up as new data comes in.

 

Now if it nver stops eating up memory and you eventually get a "Memory is full" error messsage... that would smell a lot like a leak to me.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 2 of 11
(4,202 Views)

It is a suggestion of a possible memory build-up, but be careful because this could be by design. Maybe the program is storing some sort of history or data that it doesn't want to lose. I've also seen code where the developer continuously built an array when a new line of info came in, but never capped the array, so it grew indefinitely and ate up all the memory.

 

Can you share the code that's doing this? A simple solution could be to perform a reinitialization every 12 hours or so.

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 3 of 11
(4,201 Views)

Attached is the source distribution of the code. It will require having the hardware to run. The folder contains a lot of different VI's, but the mian VI is named "NHR Sample.vi". 

 

I let the code run on the test stand overnight and attached a screen shot of the memor usage. (approximately 18 hours of running)

nhr memory leak 18hrs.PNG

Damian
0 Kudos
Message 4 of 11
(4,147 Views)

I would recommend you to use the Desktop Execution Trace Toolkit which is an excellent tool to find where exactly the memory leak happens. Try running it and see if you can narrow down the issue.

-----

The best solution is the one you find it by yourself
Message 5 of 11
(4,143 Views)

Yikes, 

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 6 of 11
(4,138 Views)

I downloaded the desktop execution trace toolkit demo. This might be a good VI to learn on. 

 

The dll's are supplied by the hardware manufacturer. I'll send them a message to let them know about the issue. As of now, I'm having the users restart the application before running tests. We're fortunate enought that we don't have any tests that last longer than 24 hours. 

 

James.Morris, that's good work around to reinitialize. I ran a test that closed the dll's and reintialized. This reset the memory usage. So maybe, the application should be designed to watch memory usage, wait for a dwell period and then reinitialize. This would at lest allow us to use the test stand until the dll's are fixed. 

Damian
0 Kudos
Message 7 of 11
(4,130 Views)
Solution
Accepted by topic author Damian_S

Yeah, with DLLs from a third party, workarounds like reinitialization are sometimes the easiest option. I don't know what your most important data collection or testing criteria is, but it might be best to reinitialize at a specific time interval, so that if you look back you can easily decipher the gaps in your runtime. If it's based on memory usage, you may have an unpredictable reinitialization rate.

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


Message 8 of 11
(4,117 Views)

@James.M wrote:

Yikes, 


I assumed from the OPs post that the attachement contains a big application (from the file size), I should have checked :). 

-----

The best solution is the one you find it by yourself
0 Kudos
Message 9 of 11
(4,105 Views)

9 times out of 10 the Desktop Execution Trace Toolkit is the way to figure out this issue.

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


Message 10 of 11
(4,100 Views)