LabVIEW
Memory Leak Detection Desktop Execution Trace Toolkit
@swatts wrote:
I'm loading and parsing a large XML file and it has a horrendous memory leak.
I have run the Desktop Execution Trace Toolkit and cleared up any unclosed references and yet it still persists.
My next plan of attack is to try and understand the allocation and freeing of memory to handles from the report exported from the Desktop Execution Trace Toolkit.
Here's the assumption I'm working on, if a handle has memory allocated but not freed we will get a memory leak.
Am I correct in this assumption and is it a valid place to look?
(I have 600+ instances of this happening on this file)
Lots of Love
Steve
It really depends what you mean with a handle. If you mean LabVIEW string or array handles, then safe from an unlikely bug in the LabVIEW diagram code generation you can't really speak of a memory leak there. LabVIEW does use lazy deallocation of its handles but that isn't a memory leak in itself. LabVIEW still knows and manages all those handles it just doesn't free them immediately as it would have to reallocate them in the next iteration or run again anyhow. The only way that those handles can get usually lost is if you pass them to external code and that code handles them badly.
I assume you are using the LabVIEW DOM XML Parser library. This library is implemented using an external code library and had in the past indeed some problems with problematic reference counting of its refnums. It might also leak LabVIEW string handles on occasion but that is not something I have noticed myself. The problems prompted me at that time to create my own XML parser fully in LabVIEW native code, that was most likely not as standard compliant as the LabVIEW DOM Parser since proper XML parsing is quite a challange to do, while the LabVIEW XML parser itself relies on the existing Xerces library from Apache, with a thin LabVIEW wrapper around it.
So what sort of handles do you suspect are getting leaked?
Yes, the underlaying Xerces library is fully OOP, parsing an opened document into a tree of various C++ objects. The LabVIEW wrapper then accesses this tree of objects and abstracts it in a way that is more easily usable from the LabVIEW diagram. So I'm not surprised that loading the document does allocate roughly the same amount of memory plus a bit overhead for the objects itself. Once you close the entire document that memory should be released but may still show up as being owned by LabVIEW depending where you look at. The desktop Execution Trace Toolkit should however be able to recognize the memory being not really in use anymore, but looking at Windows heap status LabVIEW will simply seem to hold onto that memory. Since freeing and allocating memory is a pretty expensive operation, LabVIEW tries to minimize that as much as possible, by maintaining its own internal list of available memory blocks that it is not currently using but hasn't returned to the OS yet.
@swatts wrote:
Sadly on my RAM challenged Laptop it chewed up the memory and didn't give it back.
I've still got a fair bit of fault finding to do yet, but will crack/work round it in the end.
Thanks for the insights
S
Maybe this is a good candidate for Request Deallocation after closing a document, I dont know how much it'll help, but it cant hurt. 🙂
/Y
@Oli_Wachno wrote:
Rolf,
am I getting it right, that in this case freed memory is available for LabVIEW (application), but not for the OS?
Cheers
Oli
Yes LabVIEW will reuse that memory when necessary. It hasn't lost the reference to the memory, just decided to hold onto it for later reuse, rather than giving it back to the OS and maybe having to request it a moment later again. Something similar also happens in the C runtime library and in the OS memory manager layer, so it is not as clean cut as this simplified explanation, but the principle remains in all cases the same. The memory is still allocated to the process but available for reuse.
A memory leak is something quite different. Here the application requested some memory and then consequently lost the reference to it by overwriting it somehow. This memory is then still allocated to the application but not usable anymore and that makes it a memory leak. Lazy deallocation on the other hand can be unconvienient at times when your system is a bit tight on resources, but is not a memory leak at all.
All memory leaks except when created in the OS kernel itself (by a faulty kernel driver for instance) will be cleared up at the moment the process terminates since the OS does bookkeeping about which resources (devices, handles, memory, etc.) a process has allocated and consequently will clean them up at process termination if the application hasn't done so already. Some programmers believe it is proper to do a complete cleanup before exciting the process, others trust that the OS will do a better job at this than they ever could. Personally I tend to believe that the latter a pretty lazy programmers. 
@rolfk wrote:
Some programmers believe it is proper to do a complete cleanup before exciting the process, others trust that the OS will do a better job at this than they ever could. Personally I tend to believe that the latter a pretty lazy programmers.
I dont know if the system is alot better, but it's alot faster to ditch LV that close all correctly. ;D
/Y
