Running out of memory

[Chickentree]

There are six testers that have been running the same LabVIEW application (Environmental TestVIEW.exe) for a while. So far three of them had the following memory problem. The OS is Windows 7.

One day I noticed the physical memory usage was 88% on one of the testers when I took a look at the Windows Task Manager.

I also opened the Resource Monitor. I noticed the orange part ('modified') of the physical memory bar is huge.

I closed the LabVIEW app. The RAM usage dropped from 88% to 83%.

I rebooted Windows and waited for some minutes. (I forgot to click 'Show processes from all users' on the Task Manager this time.)

How should I interpret this memory situation? What might be hogging the RAM so much? Could the LabVIEW app be the culprit?

This is a serious problem for reliable long-term tests. Any insight would be greatly appreciated.

[BowenM]

---

@Chickentree wrote:

How should I interpret this memory situation? What might be hogging the RAM so much? Could the LabVIEW app be the culprit?

This is a serious problem for reliable long-term tests. Any insight would be greatly appreciated.

---

Based on all of the screenshots you posted, yes...  your LabVIEW program is the culprit.

But memory leaks are tricky things to troubleshoot when you have the full code base.  Troubleshooting off of some task manager screenshots will be almost impossible, and this seems like the kind of program you likely don't want to share the entire code base of.

One "hackey" fix that I've used in the past until I was able to actually troubleshoot the problem was to use the System.Diagnostics.PerformanceCoutner class and write a suite of tools that constantly monitored and logged CPU and RAM usage.  If RAM would get above some threshold I had the program send me an email saying it had an issue.  It wasn't ideal but at least let me respond to the memory leak without the program crashing.

You can also use this to watch for rate of memory increase and send a warning if memory starts to increase too rapidly.  It might give you a chance to sprint to your tester (or remote in...) and figure out what actually triggered it 

Finally as you are going through your code trying to troubleshoot, there are a few things I always look for:

• Unclosed references
• Uninitialized shift registers containing arrays or strings
• Verifying any asynchronously spawned vi gets closed correctly (look closely at any reentrant vi)
• Any arrays or strings stored in local variables. Can be the same issue as uninitialized shift registers

Good luck!

[Chickentree]

---

@BowenM wrote:

---

@Chickentree wrote:

How should I interpret this memory situation? What might be hogging the RAM so much? Could the LabVIEW app be the culprit?

This is a serious problem for reliable long-term tests. Any insight would be greatly appreciated.

---

Based on all of the screenshots you posted, yes...  your LabVIEW program is the culprit.

---

Could you tell me exactly what tells you it is the LabVIEW program that's causing the memory issue? How could the RAM usage stay so high after the LabVIEW program was closed? If there is a memory leak, can it be permanent until the OS is rebooted?

[RavensFan]

TeamViewer seems to be eating up as much memory as your LabVIEW app.

How much RAM does your PC have?

[Chickentree]

---

@RavensFan wrote:

TeamViewer seems to be eating up as much memory as your LabVIEW app.

How much RAM does your PC have?

---

8 GB. It's shown in the Resource Monitor screenshots.

[BowenM]

---

@Chickentree wrote:

---

---

Could you tell me exactly what tells you it is the LabVIEW program that's causing the memory issue? How could the RAM usage stay so high after the LabVIEW program was closed? If there is a memory leak, can it be permanent until the OS is rebooted?

---

My apologies!  Looking at your screenshots I read "TeamViewer" as "TestVIEW".  I didn't look close enough - just assumed it was an additional thread.  Looking more closely, I don't think your TestVIEW seems to be using up an unreasonable about of memory - depending on what you're doing with it.

It also looks like you have plenty of physical memory available, but have run out of commit charge.  Not that you couldn't do a search yourself... but 30 seconds of GoogleFu returned this.  Maybe it'll help.

[crossrulz]

I am noticing a lot of svchost threads running.  Are you doing a bunch of TCP communications or .NET or command line?  Can't think of what else I have seen that with.  But it typically comes from not properly closing out resources.

[Chickentree]

Some terms the Task Manager uses seems to be misleading. My focus should've been high commit charge. Thank you for pointing in the right direction!

[Chickentree]

---

@crossrulz wrote:

I am noticing a lot of svchost threads running.  Are you doing a bunch of TCP communications or .NET or command line?  Can't think of what else I have seen that with.  But it typically comes from not properly closing out resources.

---

The LabVIEW program is based on the Actor Framework and extensively uses NI TestStand API to run SEQ files where UI messages are constantly sent. It controls NI 9477 & 9422 modules and XNET devices for CAN communication.