RT-Linux memory - Shared Variables?

[ProbablyPete]

Hello,

I am somewhat new to real-time development and have an application that will be running on a cRIO-9040. It uses network shared variables to communicate to HMIs over a network. I'm having an issue where over the course of about 24 hours, the real-time application eats up all the memory on the cRIO and it crashes out. Right now the only thing that stands out to me in the application is that it currently uses shared variable "Nodes" instead of programmatic reads and writes. Is that a likely culprit for creating a memory leak? I haven't found any clear documentation telling me not to use shared variable nodes in a loop. I'm currently going through and replacing those nodes with programmatic reads and shift registers to hold the variable refnums. Am I on the right track, or should I be looking at something different?

[rolfk]

---

@ProbablyPete wrote:

Hello,

I am somewhat new to real-time development and have an application that will be running on a cRIO-9040. It uses network shared variables to communicate to HMIs over a network. I'm having an issue where over the course of about 24 hours, the real-time application eats up all the memory on the cRIO and it crashes out. Right now the only thing that stands out to me in the application is that it currently uses shared variable "Nodes" instead of programmatic reads and writes. Is that a likely culprit for creating a memory leak? I haven't found any clear documentation telling me not to use shared variable nodes in a loop. I'm currently going through and replacing those nodes with programmatic reads and shift registers to hold the variable refnums. Am I on the right track, or should I be looking at something different?

---

Personally I don't think so. But you do not mention what chassis, LabVIEW version, NI-RIO version and NI-Scan Engine version you are using. If that is a very old version things would be difficult to asses nowadays about what could and what couldn't be an inherent memory leak in one of these components.

But the most trivial way of creating a memory hog is to use shift registers that accumulate over time a longer and longer string or array. Don't say it is so obvious that nobody does it, I have seen such hogs over and over again and not always by LabVIEW beginners only. Have you checked your program for such issues?

[ProbablyPete]

Ok, thank you. I'm using 2x cDAQ 9185 Ethernet chassis, using DAQmx for data acquisition. 

After my most recent 2-day run, I noticed that I got an error "11" out of an "open cfg" call, which appears to be "too many files open". I'm now thinking it may have something to do with the way we are calling "TDMS In Memory", maybe we aren't disposing of a reference properly. 

Thanks also for the point about shift registers. I don't believe that is the case, but I will take a look. 

[ProbablyPete]

To make an update and close this thread, I spent a lot of time switching shared variable nodes to programmatic-style calls, which in the end only broke my program further due to, from my understanding, the use of property nodes without a front panel as discussed here:

https://forums.ni.com/t5/LabVIEW-Real-Time-Idea-Exchange/Warn-about-front-panel-property-node-use-wh...

In the end, I did find a few System reference calls in loops which did not close the references when they were done. Closing them out seems to have dramatically reduced my memory increase over time.