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?
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.
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.
I still say that the most likely problem is fragmented memory.
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.