LibXML DLL corrupts LabVIEW memory

[KarthiK_Renganathan]

Hi,

I am using LibXML2.dll (got from http://xmlsoft.org/) to read XML files in LabVIEW 2019 64-bit. When I call open XML function, the DLL somehow corrupts the LabVIEW memory and I'd have to restart LabVIEW. It's strange, I use quite a few functions of the DLL and none of it throws error except the close function which will be called at last. The error code thrown by close function is 1097.

And if I use the same DLL with LabVIEW 2016 64-bit, it just appears to work fine.

By the way this piece of code to read XML files, I have been using it for a long time with LabVIEW 2014 and 2016. Any help would be greatly appreciated.

Thanks,

Karthik M R

[rolfk]

Most likely there is a problem in the VI interface, less likely but possible a bug in the DLL itself.

If the problem is in the VI interface it has most likely to do with one of two things:

1) Somewhere it treats a pointer as a 32 bit value. That works as long as that memory is allocated below the 4GB memory limit. Many things can influence how memory is allocated including increased memory requirements of OS and applications (LabVIEW 2019 definitely has a larger basic memory footprint leaving less memory available to be allocated before the memory allocator starts to create memory blocks beyond 4GB).

2) A memory buffer that is meant to be an output buffer for the DLL to write into has been to small. While for most situations this is something that would have been found in 32-bit too, there is one specific situation that could result in such a problem surfacing more readily under 64-bit execution. If the buffer in LabVIEW is allocated in bytes for some reason but the API takes a number of elements as extra parameter to know how much it can write and the size of the array element is for some reason pointer sized then the buffer can end up being to small for what the LabVIEW VI told it to be, if it doesn't account for the different element size in 32-bit and 64 bit it can fail. Why that only happens in 2019 would be a bit of a mystery but not impossible.

Not every memory corruption necessarily leads to a 1097 error crash, but can stay undetected for a long time, depending on what memory is corrupted. When you upgrade LabViEW the actual memory allocation will change due to different memory use of various components and suddenly a vital part is destroyed that LabVIEW can detect (error 1097) or that will crash you immediately.

[pulidotech]

I encountered similar issues with LabVIEW 2018 code called from TestStand 2017 (with LV RTE), all 64 bit.  I decided to just convert those VIs into executables and I haven't seen issues since.