Memory Monitor Example

[thutch79]

I'm trying to debug a sporatic "out of memory" situation on a large scale labview program. The program is normally well behaved, but during a run, it will sometimes spiral out of control on memory usage. I've used desktop trace execution to look for reference leaks. I've tried using the performance monitoring tool, but unfortunately, it is difficult to catch the error before it crashes out entirely.

I've been recently looking at the memory monitor example provided by labview. I wanted to use some elements of that example to create a periodic memory logging thread to add to my program. However, the memory monitor example only seems to report back the front panel memory. The data space is usually 0. When I was testing this, my program was running. Even VI's that I know have data (i.e. functional globals) show 0 in the data memory section. Does anyone know why this is?

Also, if anyone has any other good avenues for searching out memory leaks, please let me know. Labview's built in tools seem very limited.

[DFGray]

What version of LabVIEW are you using?  There were some versions that had major issues with correctly reporting memory, although I cannot remember which ones they were.  If I remember correctly, the memory was reported incorrectly if you read it after doing something else in a property node, so the fix was to only read the memory in that property node.

A more invasive way to monitor your code is to sprinkle it with small VIs which write to the windows debug stack.  This has the advantage of being highly customizable, but, in the end, is very similar to the Desktop Execution Trace Toolkit.  Using this method, you can determine exactly where the code was when it crashed, and what led up to the crash.

If the LabVIEW method for monitoring memory does not work, you can use Kernel32.dll calls to use the Windows methods (GetProcessMemoryInfo, ...).  Use the call library node for this, similar to the code linked above.  If you are running in Linux or OSX, similar methods exist.

[thutch79]

I'm on LV 2012sp1. I have looked at the kernel32 view of memory, but I believe that only give the process memory. I really need to know what is going on internally and where all the memory is being allocated to. Desktop trace is useless because if I log memory allocations, I have to choose between logging relatively small memory allocation and having desktop trace crash out fairly quickly due to too many entries, or limiting it to large allocations which doesn't seem to catch whatever is accumulating the memory.

Ideally, if memory monitor worked correctly, I could use the call to periodically log the memory each VI is using (particularly the data space). But like I said, for some reason, 99% of my VI's don't show any stats except front panel memory.

[DFGray]

I have reported this issue to R&D for resolution.  If you want to track it, it is CAR #407932.  My apologies for the issue.

[DFGray]

Looking into this further, the data memory monitor is not supposed to work during execution, and that is reflected in the documentation.  R&D reports that there is no known thread-safe way to get the info during execution, so it was never implemented.  One possible way to attack this is to use the Call Library primitive to call GetProcessMemoryInfo from the Windows DLLs and post to the debug stack using this VI.  Sprinkle the VIs liberally around the code you think is the problem and you should find it in a few iterations.

[thutch79]

I had thought this would be a fairly basic need to determine the run time memory usage of vi's. Wouldn't the GetProcessMemory call only get the memory usage of Labview.exe? That doesn't help much at all since I already know that it climbs. I just don't know where it is accumulating. I'm not following how that would help me narrow that down.