"the memory could not be written" in LV6.0.2

Question

Hi, I wrote a terminal vi which calls several sub vi's. To communicate with my device, I open the interface to a DLL (written in Visual C++) and use read/write functions from this DLL afterwards, one after another. I do allocate memory for the read function properly (by first asking how many bytes I will receive and creating an input string of the correct size which I wire as an input buffer to the read function). The terminal vi runs correctly under LabVIEW 5.1.1, but crashes with a "the memory could not be written" error (the instruction at "0x008b5225" referenced memory at "0x03015950") under LabVIEW 6.0.2. This does not happen if I switch the highlight mode on in the sub vi that reads the data. The OS is Win2K. Please help
. Thank you in advance!!!

Answer 1

Gabs:
I don't know. Without seeing the source, it's hard to say what's
going on inside the code. I don't understand why you need to specify
the length of the string externally to the function in the first
place.
Whether it is a char * array or whether it is an MFC style CString or
it is a BSTR there are functions available in C to return the string
length.
If you are trying to dynamically allocate a char * array with a zero
number of elements and then do manipulations on it like copying to it
etc. you could easily cause the problem you are describing. If it
must know the length going into it then you will have to enforce the
order of execution to ensure that no errors happen or you will have to
rewrite the code so that it can figure out on it's own how long the
string is using a string manipulation function.
Another approach might be if the problem IS with dynamically
allocating a char *array or doing a GetBuffer on a CString to just
give it a fixed size that you know you will never exceed. These kinds
of fixes would require you to recompile the C code though.
Doug De Clue
LabVIEW developer
[email protected]
Gabs wrote in message news:<[email protected]>...
> Douglas,
> thanks for your comment. I have full access to the DLL's sourcecode,
> but VARIANT or SAFEARRAY data types are not used in the DLL. Could you
> please check the second part of my message which might be hidden (at
> least it is when I open this page and I have to show it by "show all
> answers")? Maybe, that gives you some additional hints. I do not have
> any solution by now. The only "workaround" that we found is to give
> the "get string" function of the DLL another input parameter - the
> string length - additionally to the string buffer parameter. If the
> string length parameter is zero, the DLL won't respond anything and
> LabVIEW won't crash. The value of string length comes from the first
> DLL call "get string length", so, again, from the logical point of
> view, the second call "get string" could not execute before the first
> call isn't finished and has it's return value string length given to
> the corresponding input of the second call "get string". But that
> happens - "get string" is called first with a string length of zero,
> without "get string length" being executed first. Of course, this is
> only a workaround, because it doesn't explain how that can happen and
> it is not a solution. NI didn't manage to help me by now,
> unfortunately.
> Thanks,
> Gabs