Memory leak in System Configuration API

[Eric_Simon]

I am seeing a memory leak on my cRIO-9074 from this chunk of code:

Am I not cleaning something up?  Has anyone else seen memory leaks from the System Configuration API?

Thanks,

Eric

[MoviJOHN]

How are you detecting the memory leak?  Are you going by the FreePhysMem value?

[billko]

Tools --> Profile --> Performance and Memory.  Check the "Profile Memory" checkbox and then the "Memory Usage" checkbox.  By taking "snapshots," you should be able to see if there is anything eating up memory.  (Don't try to examine meory usage and time at the same time, since they will interact with each other and skew your results.)

[Eric_Simon]

First symptom was that over time, the cRIO locks up and needs a hard reset to recover.

To troubleshoot, I started disabling parts of the code and monitoring the memory usage through Distributed System Manager.

I am 100% certain that this guy is the culprit.  With it enabled, the memory usage climbs at around 4 kB/sec.  As soon as I disable this block of code, the memory usage is rock solid (i.e. not changing at all).  It was easy to track down as there is no dynamically allocated memory during run-time.

[0utlaw]

Hi Eric,

What version of LabVIEW/RT/Sysconfig are you using?

Also- it appears that you're calling this particular function multiple times, perhaps even constantly.  Do you see the same problem if the system session is maintained rather than created and destroyed for each call? 

Regards,

[Eric_Simon]

Thanks for the reply Tom.

I am using LV 2012 SP1 f4.

Yes, I'm calling this over and over as a monitoring funciton.  Maintaining the session is a good suggestion as a workaround, though I have not tried it.  My intention with this chunk of code was to have a stand-alone common-use VI for accessing memory/disk information.  I didn't want to expose the underlying mechanisms.

[nathand]

---

Eric_Simon wrote:

Yes, I'm calling this over and over as a monitoring funciton.  Maintaining the session is a good suggestion as a workaround, though I have not tried it.  My intention with this chunk of code was to have a stand-alone common-use VI for accessing memory/disk information.  I didn't want to expose the underlying mechanisms.

---

A bit off-topic, but you can keep the VI self-contained and still open the session only once. Store the session in a shift register. On the first call, open the session. Add a boolean input as a "Close" flag so you can properly end the session as well.

[0utlaw]

Hi Eric,

Redesigning the function into an FGV-esque function with init/query/stop cases (maybe even with the enum input set as optional and the default control value set to query) would probably do the trick, or you could go with something using the "first call?" primitive to open a session the first time the function is run.  This is only possible if the function is supposed to be non-reentrant, which may or may not apply to your use case. 

Nonetheless, a memory leak is problematic.  I don't have a 907x series on hand to try this on, perhaps someone that does can confirm the behavior?

[Eric_Simon]

Thanks all for your replies.  I guess the FGV-esque style will have to do for now.  I was trying to avoid making the user worry about initializing (of course, a 'first-run' call can get around this one) and cleaning up.

I will definitely try to verify that in fact initializing and closing the session is the culprit over the next several days (my gut tells me this is the case).

Still, if the session open/close is leaking memory, this may be a good candidate to submit as a bug.

Thanks again!

Eric

[billko]

---

@0utlaw wrote:

Hi Eric,

Redesigning the function into an FGV-esque function with init/query/stop cases (maybe even with the enum input set as optional and the default control value set to query) would probably do the trick, or you could go with something using the "first call?" primitive to open a session the first time the function is run.  This is only possible if the function is supposed to be non-reentrant, which may or may not apply to your use case. 

Nonetheless, a memory leak is problematic.  I don't have a 907x series on hand to try this on, perhaps someone that does can confirm the behavior?

---

Maybe it's not really closing the session even though you told it to so it keeps opening new sessions instead?