Robustnes problen on call library function node

[sylviane]

 Hi all,

I have a robustnes problem with the call of DLL fonctions from Labview using the "Call Library function Node".
My DLL is made using VisualC++. I have configured the Node with the correct parameters.

I use three functions with the following prototypes.
char ANumMasterOpen(char, char*)
char ANumMasterWrite(char, char*)
char ANumMasterClose(char)

My Labview is working correctly but is not robustnes. Sometimes (after 15 minutes or after 1 hour), my Labview module craches with
this error :

Labview: An exception occurred within the external code called by a
Call Library Node. This might have corrupted LabVIEW's memory. Save
any work to a new location and restart LabVIEW.
VI "func_x.vi" was stopped at Call Library Function Node 0x0 of
subVI "func_x.vi"

Can anyone help me?

[sylviane]

More information about my problem.

I call my C++ DLL from three differents subVI and I read that LabView unloads the DLL when the subVI is finished. I think that sometimes Labview unloads the DLL in the first subVI and very quickly after Labview loads the same DLL in the second subVI without any success. It could be an explanation of the error.

Has everyone already meet this problem ?

[rolfk]

---

@sylviane wrote:

More information about my problem.

I call my C++ DLL from three differents subVI and I read that LabView unloads the DLL when the subVI is finished. I think that sometimes Labview unloads the DLL in the first subVI and very quickly after Labview loads the same DLL in the second subVI without any success. It could be an explanation of the error.

Has everyone already meet this problem ?

---

This kind of problem is almost always (and I mean almost always such as in 99.99999%) a result of badly configured or wired Call Library Nodes, despite your claim that this can not be the problem. A very common error by a lot of LabVIEW programmers is that they forget to allocate the buffers the DLL is supposed to write data in since in LabVIEW you normally do not bother about buffer allocations at all. However calling an external function LabVIEW has no way of knowing what that function expects and you have to do the hard work yourself. LabVIEW will happily pass the pointer to an empty string or array to a DLL function but once the DLL function writes in such a buffer it will cause a buffer overflow and overwrite vital information that is used by LabVIEW itself sooner or later. So make sure you understand the buffer parameter requirements of your functions. It's not just that no buffer can cause problems even if you pass a buffer that is only a few bytes smaller than what the function expects can you already run into serious problems.

As to your other suspicion. LabVIEW does not unload a DLL when the function call is finished. That would be awfully inefficient since DLL loading is not very fast. LabVIEW loads a DLL when the VI containing the Call Library Node is loaded and unloads it when that same VI is unloaded. So just by calling various VIs containing calls to your DLL won't load and unload that DLL over and over again unless you put each DLL call into a VI that you load and call dynamically through VI server.

Rolf Kalbermatter

[sylviane]

Thanks for your answer.

I remark something in Labview error

Labview: An exception occurred within the external code called by a
Call Library Node. This might have corrupted LabVIEW's memory. Save
any work to a new location and restart LabVIEW.
VI "func_x.vi" was stopped at Call Library Function Node 0x0 of
subVI "func_x.vi"

I read many documents about this error and Labview gives often a valid address. Could you explain the case of library function node is OxO ?

[rolfk]

---

@sylviane wrote:

Thanks for your answer.

I remark something in Labview error

Labview: An exception occurred within the external code called by a
Call Library Node. This might have corrupted LabVIEW's memory. Save
any work to a new location and restart LabVIEW.
VI "func_x.vi" was stopped at Call Library Function Node 0x0 of
subVI "func_x.vi"

I read many documents about this error and Labview gives often a valid address. Could you explain the case of library function node is OxO ?

---

This is an exception. Your DLL function tried to write to or read from memory it was not allowed to do most likely. LabVIEW itself organizes its diagram as (I think it is called) a directed graph. All the different objects in that graph have an index ID and this one means that the Call Library Node is the first object in that graph. Is this information useful for you? No!

But it can help LabVIEW technical support to pinpoint the exact location of problems when diagnosing problems and bugs in complicated VIs. In your case I still am almost 100% sure that you do not pass correct buffers to your Call Library Node. The problem with this is that this does not necessarily have to crash immediately. Your function might not always write into the buffer or not always the same amount of data, usually working fine or sometimes overwriting data it shouldn't that are not immediately fatal to LabVIEW. But sooner or later memory gets corrupted and things have to go wrong from there in various ways such as when trying to edit your VI (your DLL function has overwritten important LabVIEW editor data), exiting the application (LabVIEW tries to deallocate data pointers that have been trashed by your DLL function), or in the worst case you are saving corrupted VIs to disk.

There is no way for LabVIEW to protect process internal memory from being trashed by your DLL functions without horrible performance issues.

Rolf Kalbermatter

[DFGray]

I would like to second Rolf's analysis and give you an example.  I once created a LabVIEW application (LabVIEW 6.1) that called a DLL using 64-bit integers.  However, due to the way they were allocated, I thought they were 32-bit integers.  The program worked most of the time, since I was only using the bottom 32 bits of the integers, even though I corrupted the call stack every time I used it.  It crashed every once in awhile.  Once I solved the 32-bit/64-bit issue, it was solid and the resulting code has been shipping for years now (yes, you can use 64-bit integers in LV6.1, with a little digital sleight-of-hand).