how to diagnose an out of memory error

[Dave_Thomson]

We have a client running our LabVIEW 2018 program (compiled) on W7, 32bit. They run 24/7, and every 4 months they get error 2, out of memory from our program. (There are two other programs running as well, written in an older version of LV that don't exhibit problems.) Our program is very modular, and except for a couple of custom modules, we've run it on numerous other systems without seeing any such error. So I set up a computer here to run just those two modules. No obvious memory leak. Also, when LV start reporting Error 2, Windows still says that our program is only taking up about 140MB, and there are 600MB free memory! So it really doesn't look like a traditional memory leak out-of-memory error.

I'd like them to try replacing the memory chips, but the system is remote, with limited physical access.

My questions are:

Does anyone have experience with similar symptoms in which it turned out to be the memory hardware was bad, not the software?

Stated another way: Do the symptoms described sound like they could be due to bad memory chips?
Also, any recommendations for a diagnostic program we could run that could check the chips?

Thanks,

    DaveT

[billko]

LabVIEW needs contiguous memory.  It's likely that arrays are being built and destroyed in a way that leaves holes in your memory.  Eventually the arrays can't fit into whatever holes are left and you get the error 2.

[LucianM]

Was there a function referenced in the out of memory error that caused the error? For testing the memory chips you can try with memtest86.

[Yamaeda]

It can be a false error. If something else, like a DLL, generates error 2 LV will say Out of memory. Otherwise the Profiler might be able to tell if something slowly eats memory.

[billko]

I still say that the most likely problem is fragmented memory.

[Petru_Tarabuta]

• Do the symptoms described sound like they could be due to bad memory chips?
  • It seems unlikely that the cause would be bad memory chips. If that was the case then presumably the two other apps written in an older version of LV (and other Windows apps too) would experience the same (or similar) error and/or timing of the error (once every 4 months).
• Any recommendations for a diagnostic program we could run that could check the chips?
  • A program that may shed more light on the LV app that experiences the error is Process Explorer from the Windows Sysinternals suite of utilities. It is like a much more advanced version of Task Manager, Resource Monitor or Performance Monitor. In Process Explorer, you can right-click on the LabVIEW app and select 'Properties'. Then navigate to 'Performance Graph' (there may be no need to navigate to this page, as it might be the one that meets you when you open the properties). The 'Private Bytes' plot in that page may give you insight into whether the memory usage keeps increasing.

[User002]

---

@Dave_Thomson wrote:

We have a client running our LabVIEW 2018 program (compiled) on W7, 32bit. They run 24/7, and every 4 months they get error 2, out of memory from our program [...]

---

OK, this may be a really long shot, but I saw a similar multi-month-memory-issue with an application I interacted with a lot (this was before I was programming in LabVIEW - the application was written by a professional developer, and the application was generally very good).

The issue (from a user perspective) came from a log file reaching a certain size, about (IIRC) 2GB. The computer had plenty of extra RAM and hard-drive space, but the application couldn't write to it anymore. I haven't seen the source code, but I suspect the whole file was being read into LabVIEW before writing, so that it was entirely in memory. Again, at the time, I was just a user, so I'm not sure of the root cause in our case, but our workaround was to rename the log file every few months.

If it's related, maybe this can point you in the right direction (or maybe this doesn't help at all, or points to @billko's answer(s)), but that's what I've seen, for what it's worth.

-joeorbob