Strange memory issue

[Mark_Yedinak]

I have a rather large application that is well established and has been in use for many years now. Recently after some minor updates to the application it is eating up memory during execution. The changes made didn't add any type of arrays, queues or things that would increase in size. As stated, the application has been in use for years without this issue. I have been reviewing all of the recent code changes and cannot find anything that should result in the application devouring memory. Unfortunately I cannot post any code due to intellectual property concerns as well as simply the size of the project.

The application is quite literally increasing by several hundred kilobytes every few seconds. I have tried disabling large blocks of code which include the recent updates but that does not seem to help. I have tried using the Execution Trace tool but that messes with the timing in the application. However, nothing really stood out in that tool. Tried the profiler but that reveal anything. I went back to a working released version of the code and now that is also exhibiting this strange memory issue.

Does anyone have any thoughts on I might be able to narrow down where the issue is coming from?

[Gregory]

Did you switch LabVIEW versions at any time? Or did you change the way some code was called from static to dynamic? 

I am wondering if there are some references being opened that are not being closed. And a wild stab in the dark is that maybe in one LabVIEW version they were being closed automatically and in another they were not.

[mcduff]

Are you using a new version of LabVIEW?

---

@Mark_Yedinak wrote:

I went back to a working released version of the code and now that is also exhibiting this strange memory issue.

---

Is this version compiled with the option "Allow future versions of LabVIEW to run this" or whatever the verbiage is?

I had an issue in the past with DAQmx, an update to the driver led to a memory issue that wasn't there before, then another update seemed to get rid of it. 

Check if you also updated any other LabVIEW drivers, versions, etc. Newer versions of LabVIEW seem much more buggy to me, than in the recent past.

[Mark_Yedinak]

The code is currently running LV 2018. I also have LV 2023. This issue did appear to show up after I ran a repair which ended up updating stuff. I would like to avoid having to uninstall everything because I have several versions of LabVIEW installed and I need those multiple versions. The application does log the memory usage to a DB but for some reason the call to get the memory usage is not working in LabVIEW 2023 64-bit.

[santo_13]

If possible, I would try reverting the changes and see if the memory problem goes away, if it doesn't, then it may be the environment (i.e., software versions) instead of your application code.

[rolfk]

The fact that running fhe old application exhibits the same problem clearly hints at an environment issue rather than something in your application code itself.

Things to consider:

- that old application is a compiled exe?

- it doesn’t have “use future runtime” enabled in the build options?

- are you using DAQmx or similar drivers? There only can be one version installed on a system, whatever is the newest you successfully installed.

- other third party drivers that may have gotten corrupted or upgraded?

- your memory monitor functions use what API? Third party .Net, LabVIEW application properties, NI system API?

[JÞB]

I would agree that this looks like an environment issue. I would suspect that the compiler optimization setting might have something changed.

Two things I would check first:
A) run VIA after setting the cyclic complexity threshold excessively low. (try to get lots of FAILURES)
B) tweak the ini option for compiler optimization all the way to 10(Rarely Limit)
Failing all else- see if you CAN find a LabVIEW.ini from the developer that checked the older files into SCC. Worst case here is that a NEWLY APPLIED optimization caused the leak. You really can't "UNAPPLY" an optimization - you would need to go back to the original working code and recompile with the original setting.

[Mark_Yedinak]

After further investigation it definitely looks like something with the LabVIEW environment. I ran the executable of the previous version and it is exhibiting the same issue. This is the same application that is currently running in production. I also tried running from source code using LV 2023 and that ran without issues. Now the hard part is how to I fix my environment so everything will be normal again. It should be noted that this application is pure software. No DAQ or hardware device drivers are being used. The devices the system communicates with use either Modbus or REST APIs. In my testing I am not using the REST based devices as I don't have simulators for those yet. It does use a few .Net calls but there aren't many. A few to get the memory usage. I will have to dig around the environment to see if I can identify any changes. In the meantime I will try building on a different computer.

[Mark_Yedinak]

Update: After several clearing of the compiled cache the application started working normally until yesterday. I was making a few minor updates and now the entire application is running dog slow. I have built in performance metrics so I can see quantifiable measurements of the timing. For example, one of actions had been averaging 0.006 seconds for execution and as of yesterday the same action is now taking and average of 0.730 seconds. This particular action had no updates. That is an order of magnitude slower. I am beating my head against the wall as to what is going on. All of this is on the same machine and same source code. I have once again tried clearing the cache but nothing seems to be making a bit of difference. This is driving me crazy.

[santo_13]

Was the piece of code that was running in 6ms some sort of calculation logic or does it interact with .NET dll or sort?