LabVIEW
File IO Memory Leak
Hi,
I'm trying to stream data to disk on a cRIO 9034 but I'm running into difficulties with what appears to be a memory leak when writing data. As I'm writing data to file, free physical memory decreases at the same rate that I'm writing data. The memory does not return after closing the file reference, even when using the Flush File vi. Every time I start a new file memory continues to deplete until I hit a floor when either file write speeds slow to a crawl or file write operations stop working entirely. The memory does not return until I either reboot the cRIO or delete the files from disk.
Below is some test code I'm using to replicate the problem. I am using LabVIEW 2017 SP1. This post seems to have the same problem and they said that upgrading to LabVIEW 2019 fixed the problem, however none of the release notes I can find for 2019 or other newer version of LabVIEW mention anything about fixing a memory leak problem. I would like to confirm that this is the most likely fix before I go through the process of upgrading.
Hi ml,
@ml_12345 wrote:
I'm trying to stream data to disk on a cRIO 9034 but …
Below is some test code I'm using to replicate the problem.
In your image you don't "stream data to disk", but you write about 12kB of zeros to the file whenever the message queue has a certain condition.
The queue isn't read/emptied in your image!
There also is no "code" in your message, there is just an "image of parts of code"! How should we help you with an image?
The thread you reference is a bit confusing.
It talks about myRIO and later sbRIO-9637 boards. They are both using an ARM CPU, which might or might not be relevant.
Your device is a cRIO-9034 which is an Intel Dual Core CPU.
There might be a chance that it is affected too, BUT!
I worked extensively on projects running on various cRIO-9034 and other variants of the cRIO-903x series controllers in the past. In various versions of LabVIEW including 2016, 2017, 2018 and 2019 and those applications were rather elaborate and used a lot of file IO to store log files, measurement data and more. And while we run into quite a few problems in the course of that, this particular error I absolutely can't remember to ever having seen.
However, considering all the ifs, whens and maybes in this context, the by far easiest solution is actually to try to upgrade to 2019 or newer. Make a backup of what you have now (you are using Version Control, right???? in which case the easiest would be to create an explicit new branch) and then go to install this newer LabVIEW version into a separate Virtual Machine and try it out with your little sample VI.
If you do any serious development in LabVIEW you should:
- Not install LabVIEW on your computer directly but use a separate Virtual Machine for every LabVIEW version you want to use
- use a Version Control system of some sort (Github or Gitlab both lets you set repositories to be private even for the free accounts). If you are concerned about anyone outside your organization being able to access your super secret code, you can also run your own repository. SVN used to be fairly simple to setup locally. GIT is a bit more complicated but also doesn't require a rocket science degree. Any decent NAS device comes with an easy way to install either of the two.
I understand that this is just some testing code, but it is impossible to see the full picture (sic) from an image.
- What is in the FALSE case and how often does each case execute?
- Why is there a wait inside the case structure?
- Why are there two error terminals, one deep inside structures.
- Since the message queue is a terminal, I assume this is a SubVI? How does it get called? What is on the connector pane?
