I'm working on a large application that will suddenly spiral out of control on memory usage. I've been analyzing the desktop execution output from a time during the spiraling memory. My understanding (which may be very wrong or at least incomplete) is that each entry for a memory allocation for a particular handle will tell you how much memory that handle represents. For a "Allocate" event, the number after "Size: " is how much memory is there. For a "Resize" event, the number after "New Size: " is how much memory is now there. A "Free" event obviously releases the memory and the handle may be reused again.
Is my understanding correct? If so, here is the most concerning thing I'm seeing. I've created a program to parse the output from a trace. The trace captures all memory allocations. The program parses the output and sorts all the entries by handles. These entries are an example of my concern:
1093116:12:23.1099782 TranslocMeasure.vi Memory Allocate 31 0 Handle: 0x329F5024; Size: 80004
6007916:12:24.3637328 Text File.lvclass:Add Data to Files.vi Memory Free 32 7 Handle: 0x329F5024; Size: 28
These are consecutive events for this handle. There are no other memory events for this handle between the two. If I'm understanding this correctly, what happened to that 80004 of memory? Does the "Size: " at a "Memory Free" event represent how much got free up? Or is that the new size of the handle?
Is this a real memory leak or am I misinterpretting the output of this tool?
The tools in Labview for tracking memory usuage are sooooo bad. Does anyone have a good method of tracking issues like this down? I've used desktop trace obviously. I've also tried the performance/memory profile tool, but I find that to be totally erroneous. I have instances where Labview is using close to 2gB of ram, and when I look at the performance tool, the total memory usage doesn't add up to more than a couple hundred kBs.