Error 1097 in Windows 10 when it is working elsewhere

[cfaigle]

I have a LV program that calls an external library via wrapper functions that I downloaded via VIPM (libxml2). This program works fine on computer A (Win7, LV2015 32-bit). Since it is meant to be portable, I have installed it on various computers (Win7) where it runs well, except for computer B. There, it throws an Error 1097 when calling the external library. The libxml2 package is obviously installed and I can see it on the Functions palette. Could it be due to the differing versions of Windows, or due to conflicts between Labview 32- and 64-bit? I open and run my program with LV 32-bit. 

Computer A:

Labview 2015 (32-bit)

Windows 7

Computer B:

Labview 2015 (32-bit)

and Labview 2015 (64-bit)

Windows 10

[Bob_Schor]

This would be much easier to diagnose/test if you (a) posted all of the code that constitutes this Project (I assume it's a LabVIEW Project, so just compress the folder holding the Project and post the .zip file) and (b) note what VIPM packages it requires (you mentioned an XML package -- are there others?).  I'm sure there are a number of us who could try to run this on a Windows 10 machine and see if we can (a) produce the error (or else tell you why it seems to work for us, but not for you), and (b) "work around" the error (possibly by fixing it).  Otherwise, it is mostly idle speculation (i.e. "guesses") on our part ...

Bob Schor

[rolfk]

Error 1097 means that after return of the function from the shared library, LabVIEW detected that something in the state of memory has been changed which shouldn't have happened. This is a catch all error that can be caused by a number of reasons, including a misconfigured Call Library Node or a bug in the shared library. Not returning such an error does unfortunately not mean that no such error is present anyhow, since LabVIEW can not detect every possible memory corruption. It can even depend on the actual state an application is run in if such an error makes itself known or gets unnoticed by LabVIEW (but the actual memory corruption happens anyways even if LabVIEW can't detect it). 

Most common reason for this error is an output buffer that is not configured large enough on the LabVIEW diagram for the function to write its array or string data into. A systematic Call Library Node misconfiguration is not likely in this case as it seems to work on other systems. A bug in the shared library is a possibility but considering that it is a well known library also not that likely. So most likely it is an array or string buffer that is allocated on the LabVIEW diagram to small and then one of the library functions tries to write into that buffer and overwrites over the end of the allocated buffer. It could be that due to system differences the information that a function wants to return ends up being larger than on the other systems and runs now into a buffer limit that didn't happen before. Or you were simply very unlucky that it didn't crash on the other system before but might still have corrupted memory somehow.

[cfaigle]

Unfortunately, the software is confidential and I was not able to create a minimum not-working example. However, I was able to solve the problem and I think it was due to race conditions. I was calling the library function at different spots in the program and it sometimes got highly random input strings. I assume there was some memory leak somewhere in there. Apparently, the same problem occurred in the Win7 versions and led to corrupted data output, but did not throw the error message.