VI crashs when calling CIN that calls a Matlab dll by lsb that do casting

[lior]

The problem:

A VI that includes a CIN calls a different DLL that was compiled by Matlab 6.5, using an LSB file that performs type casting for Matlab mxArray type variables.

The VI crashs when entering the CIN.

It seems the code crashs whenever we attempt to access pointers returned by the Matlab DLL.

The same VI with the same LSB and Matlab DLL runs correctly in LabVIEW 7.1.1.

The Matlab DLL was compiled via the Matlab MCC command.

We also compiled the LSB using LabVIEW 8.5 - Multithreaded DLL + 1 byte alignment, via VC 6.0 - this didn't solve the problem.

There are no int64 variables. We tried to remove the complex 128 and float64 variables and change them to float without success.

We also compiled the LSB using LabVIEW 8.5 - Singlethreaded* + 1 byte alignment or Debug Singlethreaded + 1 byte alignment - again with no success.

I have notice that the lvsbutil.exe from the cintools directory was change in 8.5 comparing his size to 7.1.1 and now it is no longer possible to run it from the command line.

Any help on how to use it in labview 8.5?

If needed i can post the C source code

Thanks

 Lior

[JamesR]

As far as the lvsbutil.exe not working is concerned, this was reported to R&D (# 4C5FE0E9) for further investigation.  A workaround is to replace the lvsbutil.exe file from LabVIEW 8.5 with the one found under the LabVIEW 8.2 directory.  Do you have access to this file from LabVIEW 8.2?

[lior]

Hello JamesR,

Thank you for your replay,

I tried to to follow you suggestion using the lvsbutil.exe from Labview 8.2.1 (I don't have 8.2) but with no result.

The vi is still crashing.

I notice that the lvsbutil.exe in Labview 8.2.1  is much smaller than 8.5 or 7.1.1 (196kb)

Do you have any more suggestions?

Thanks

Lior

[rolfk]

---

@lior wrote:

Hello JamesR,

Thank you for your replay,

I tried to to follow you suggestion using the lvsbutil.exe from Labview 8.2.1 (I don't have 8.2) but with no result.

The vi is still crashing.

I notice that the lvsbutil.exe in Labview 8.2.1  is much smaller than 8.5 or 7.1.1 (196kb)

Do you have any more suggestions?

---

Changing this CIN stuff to go over DLLs instead sure would help getting debugging more simplified. As it is with CINs your possibilities for source level debugging are quite limited and in the case of 8.2(.x) according to my own underfindings impossible because the CIN Node will simply shutdown LabVIEW on any exception, even if that is a debug breakpoint. In LabVIEW 8.0 and 8.5 I do not have this problem, notably on the same machine, so it can be hardly an environmental influence of my Visual Studio debugger not being registered properly.

Also a crashing CIN is probably hardly caused by a bad lvsbutil. As I understand it the bad lvsbutil in LabVIEW 8.5 will prevent you from creating CINs, not create CINs that always crash.

A crash in external code really should be sought in that code somewhere. Or also in the configuration of the interface in the case of a Call Library Node. Except in the early days of LabVIEW 2.5 and 3.0 or so I have NEVER had the case that external code crashed on me because of anything else than my own stupidity in interfacing with some external code either in my own C code, bugs in the external code itself or in the configuration of the Call Library Node, but NEVER because of LabVIEW doing something wrong.

Naturally NI can not really help you much with the external code itself it is not from them and I have no experience with Matlab code but wouldn't  be surprised if you need to do specific stuff before calling such code. Unless Matlab has its own ideas of memory management, I would as a first step make sure that any pointer you pass to the matlab code is valid and properly allocated before getting passed to the Matlab code. In C it is standard that the caller (here your CIN or DLL wrapper) allocates memory for buffers the callee is supposed to write information in. This is quite different than what you do in LabVIEW and is the main reason why many external code attempts always crash when LabVIEW programmers start to dive into external code without a very good understanding of C programming.

And before you ask, no LabVIEW can NOT do anything about that as it can NOT know what an external code component would need in terms of allocated memory nor the means for that allocation.

Rolf Kalbermatter

[JamesR]

Hi lior,

rolfk is right that the bad lvsbutil in LabVIEW 8.5 prevents you from creating CINs; it's not the cause of your CIN that is crashing.  I would suggest following rolfk's advice, namely to fix any errors which may exist in your external code.