random crash of DLL

[luuk]

hi!

I'm building a dll file to fit some measurement data. To test the routine I use some sets of measured data, the strange thing is when I fit the same data a couple of times, so press the fit button a couple of times to start over and over. Labview is saying the call library function node threw an exeption.

I've read on the fora that this can occure when deviding by 0 of take the sqrt of an negative number, but since the input is the same all the time this can't be the case.

Anyone a suggestion what it could be?

I'm using the calloc and free function.

thanks!

[ShaunR]

Post the DLL/source and test harness.

[AnalogKid2DigitalMan]

DebugView can be handy at providing more details of the problem, especially with exceptions:

http://technet.microsoft.com/en-us/sysinte...s/bb896647.aspx

Is the dll public, private, in the GAC, what environment was it created in (ie C, C#, etc)???

-AK2DM

[Rolf Kalbermatter]

Typically this is a problem with your DLL and/or how you call it. You do not say how you created the DLL (LabVIEW or C) nor how you try to call it. But a common problem is that people calling a DLL from LabVIEW using the Call Library Node do forget that in this case normal C rules apply and the automatic memory allocation management they have gotten so used to in LabVIEW does and can not work here.

So they call a function to sum array a and b and hope that the DLL magically allocates array c to write the result in. Well the DLL can't do so and LabVIEW can't do so for you either as the development of the LabVIEW mind reader interface to read the programmers intentions is still in the early stages of prototyping .

So what happens is that the DLL writes its results in the invalid (or to small) memory pointer that is passed to the DLL and sometimes that overwrites only non-vital data, sometimes it overwrites very vital data that will make LabVIEW crash after the fucntion returns (or destroy the VIs that you have in memory) and sometimes it happens to write to memory locations the OS knows are not valid for the current process, which will throw the exception during the fucntion call already.

Review your DLL for possible out of bounds array references, make sure you call it with preallocated arrays that are long enough for all array and string output parameters and then come back with more info such as the DLL source code and test harness itself if it still fails.

Rolf Kalbermatter