LabVIEW
XML Parser Memory leak
HI,
I'm using the native XML parser palette to edit SVGs (color, width, height) to show icons in my application (using G-Image from VIPM to rasterize them). By using the Desktop Execution Trace Toolkit (DETT) after having a big memory leak in my application (it used all my computer available memory during the night), I found memory leaks in my XML edit VIs. It makes sense because these VIs were called every seconds, generating 3 memory leaks each time. And after fixing the issue, I've been able to run the application all night long without memory growth.
Here's the issue / fix: (LabVIEW 2024 Q3 64 Bit)
When calling Get Named Item method on a Node Attributes, if the given attribute Name is found, the returned Node reference is seen as valid by Not a Number / Path / Refnum? and if the attribute name is not found, it is seen as invalid.
Usually in LabVIEW, refnums seen as invalid by Not a Number / Path / Refnum? do not need to be closed and will generate an error if closed (queues, DVRs, VI references, ...). So I thought I didn't need to do it on the XML Node.
Big mistake!!!
Here is a small example (see attached zip, code saved for LV 2020):
We can see DETT detecting memory leaks when the Invalid Nodes (Not a refnum) are not closed.
So,
- Is it expected to close all XML parser refnum, even invalid ones?
- Is it a bug that Not a Number / Path / Refnum? sees them as invalid even though they lead to allocated stuff?
- I've tested only this Get Named Item method, but it may not be the only one with the same behavior.
That clearly seems like a bug.
Maybe that's related, but you can also see that the flattened "Ref" from the invalid refnums has a non-zero value, while it should definitely be zero.
From experience, I have learned to always close an XML Parser refnum. Whatever its validity, it will be always safe to close it.
Regards,
Raphaël.
Good find! I assume it creates the reference regardless, but it points to Null if not found, that's why you need to close/free it.
I think there is an EasyXML LabVIEW library out there that is literally hundreds of times faster than the native VIs. It's a little less user friendly, but much more capable.
I agree on this:
@billko wrote:
I think there is an EasyXML LabVIEW library out there that is literally hundreds of times faster than the native VIs.
However on this it's the other way around!
@billko wrote:
It's a little less user friendly, but much more capable.
EasyXML (which you can get from VIPM) allows to easily and efficiently read/write most LabVIEW data types from/to XML, but that's it.
If you need to perform more complex XML tasks (search/edit/add/remove nodes, get/set attributes, process namespaces, validate against a schema...), to my knowledge the native XML Parser palette is the most reasonable tool. It may not be suited for giant XML files though.
Regards,
Raphaël.
@raphschru wrote:
I agree on this:
@billko wrote:
I think there is an EasyXML LabVIEW library out there that is literally hundreds of times faster than the native VIs.
However on this it's the other way around!
@billko wrote:
It's a little less user friendly, but much more capable.
EasyXML (which you can get from VIPM) allows to easily and efficiently read/write most LabVIEW data types from/to XML, but that's it.
If you need to perform more complex XML tasks (search/edit/add/remove nodes, get/set attributes, process namespaces, validate against a schema...), to my knowledge the native XML Parser palette is the most reasonable tool. It may not be suited for giant XML files though.
Regards,
Raphaël.
Yes, the best tool for the occasion. I'll use the native XML VIs for simple tasks, but in one of the related topics (can't recall it ATM) it from like five minutes to less than a second.
