LabView 7.0 crashes (intermittently) when launching VI

[TheWaterbug]

LabVIEW is crashing a _lot_ on a dual-processor machine running NT4 SP6. The error we get is:

"The error at "0x00c01e0e" referenced memory at "0x38345920". The memory could not be "read"."

It will crash when loading a VI, running a VI, or even when loading help for a module. It is frequent, but not necessarily reproducible (e.g. we can't do it at will). But it happens about every 30 minutes, at least. We _are_ linking into external DLLs that we developed ourselves in MSVC++.

We have uninstalled LabVIEW, reinstalled LabVIEW, updated to IE6 SP1, and uninstalled NI-Device.

We have Microsoft VC++ 6 SP5 installed, but we've uninstalled most other things that aren't strictly necessary for us to do our work.


Are there any known incompatibilities with LabVIEW 7.0 and our system?

[rolfk]

TheWaterbug wrote:

> LabVIEW is crashing a _lot_ on a dual-processor machine running NT4
> SP6. The error we get is:
>
> "The error at "0x00c01e0e" referenced memory at "0x38345920". The
> memory could not be "read"."
>
> It will crash when loading a VI, running a VI, or even when loading
> help for a module. It is frequent, but not necessarily reproducible
> (e.g. we can't do it at will). But it happens about every 30 minutes,
> at least. We _are_ linking into external DLLs that we developed
> ourselves in MSVC++.



> Are there any known incompatibilities with LabVIEW 7.0 and our system?

Nope, but the mentioning of using your own DLLs most seriously pinpoints
to the culprit. This sort of problems you see does usually stem from a
DLL trying to modif
y memory it shouldn't do, and in doing so stepping on
LabVIEWs toes. This may not necessarily fail immediately but as soon as
LabVIEW tries to reference its internal data structures your DLL has
unwisely written over it will simply double up and crash.

Possible reasons, are manyfold: An error in the Call Library Node
configuration, or not initializing arrays passed to the DLL to the
expected or needed length, and last but not least a simple error in your
DLL.

Rolf Kalbermatter

[TheWaterbug]

Ah! This sounds consistent with my DLL developer's hypothesis and with our experience. So now the question is, how do we allocate string space in LabVIEW?

We have a function, GetOutputMsg(), that we export so that other apps (e.g. LabVIEW) can read a response from our DLL:

void GetOutputMsg(char *pMsg, int nMaxBytes);

LabVIEW needs to pass in a string pointer and an int so that our DLL knows how big a message it write to the string. Currently, we are using the Call Library Function module, and using a C String Pointer for arg1 and an int for arg2.

How do we allocate a known amount of memory for a string in LabVIEW? Alternatively, if we just create a string in LabVIEW, how much space does it allocate, by default?

We've already called NI, bu
t they didn't have an answer.

[rolfk]

TheWaterbug wrote:

> We have a function, GetOutputMsg(), that we export so that other apps
> (e.g. LabVIEW) can read a response from our DLL:
>
> void GetOutputMsg(char *pMsg, int nMaxBytes);
>
> LabVIEW needs to pass in a string pointer and an int so that our DLL
> knows how big a message it write to the string. Currently, we are
> using the Call Library Function module, and using a C String Pointer
> for arg1 and an int for arg2.

I do this usually by initializing an array "Initialize Array" of U8
integers of the desired size and then wiring it through the "Byte Array
to String" conversion function. Just watch out, sometimes badly
programmed C functions expect the buffer to be one char longer than the
maxBytes value indicates, for the strin
g terminating NULL char.

> How do we allocate a known amount of memory for a string in LabVIEW?
> Alternatively, if we just create a string in LabVIEW, how much space
> does it allocate, by default?

Aside from some internal space for LabVIEWs own string type it basically
allocates as many bytes for the string as there are characters in there.
This means an empty string is a pointer to an array of 0 bytes for the
underlying C function (and will certainly cause problems if the function
tries to do anything with that pointer).

Rolf Kalbermatter