07-06-2023 06:54 AM
I have quite a large application (that I cannot share here) which seems to have some memory leak somewhere (I don't know where). After a couple of days of running, an out of memory issue appears. I'm not able to replicate it in the development environment, only in the executable. I've added this code to monitor the memory usage:
The highlighted line in the Task Manager is the application in question. It shows a much lower memory usage than reported in LabVIEW, nor is it increasing over time. What is the best way to monitor the actual memory usage?
Even better if there is a way to easily find where memory leaks are present (I've been searching for it for a while now...).
07-06-2023 07:52 AM
In the development environment, you can Use the Profile Performance and Memory Window to trace the memory consumption of each VI. However, this tool is not supported in the runtime environment.
If the issue is indeed only reproducible in the executable, perhaps you can try using LabVIEW Desktop Execution Trace Toolkit, but I have never used this tool myself so I can't comment much.
07-06-2023 09:47 AM
I have found that monitoring memory usage is not really helpful in finding memory leaks.
Most memory leaks are arrays and strings that are continuously concatenated so they are constantly growing followed by file references that are not being properly closed.
If your program uses some sort of high speed DAQ high sample rates over long periods can cause out of memory errors.
07-06-2023 11:39 AM
It might be worth noting that there are 3 "types" of issues that can look like being out of memory, but are slightly different:
First is actually running out of memory. This is at around 3 GB of RAM usage for 32 bit, or running into the system RAM limit if 64 bit. From the numbers you show, this seems unlikely.
Second is running out of continuous memory. Some data types, such as strings and arrays, need a large chunk of memory all in a row. If you have one that gradually increases in size, this can happen when it gets sufficiently large over time that there's nowhere to put it all at once even though there's technically enough room, if it could be split up.
Third is running out of references. LabVIEW can only have 10^20 references allocated (just over a million) so if you keep allocating new ones without freeing old ones you can still run out even though you have plenty of RAM available and you don't use large data arrays or strings needing continuous RAM blocks.
In both the second and third cases you should probably focus on what your application does constantly in the background.