"The memory could not be "written". " error

[Volodymyr Kudryavtsev]

Hi, I have a recurring program problem on LabVIEW 5.1.1 under Windows. I
write what appear to be working vi's, but upon execution I get a fatal "The
memory could not be "written". " error. By stepping through the program, I
can determine where the crash happens; usually as the vi exits from a sub vi
(after it has already completed all operations in the sub vi), or when
performing a simple math operation. My usual solution is to re-write chunks
of code until the
problem goes away, but that has become too labor intensive. Occasionally,
compiling an *.exe eliminates the problem, but that solution is very
unreliable. Any ideas what this problem is?
V. Kudryavtsev


Error message:
the instruction at "0x007b370e" referenced mem
ory at "0x407aa006". The
memory could not be "written".

Debugging in Microsoft Developer Studio: Unhanded exception in labview.exe :
0xC0000005: Access Violation

=>007B370E mov dword ptr [eax+6],ebp
007B3711 mov eax,dword ptr [edi+4]
007B3714 cmp word ptr [eax],si
007B3717 jae 007B3786
007B3719 mov word ptr [eax],si
.......

[Labviewguru]

I have seen these errors in a number of places, primarily when not cleaning up memory (destroying images) in IMAQ when closing a thread (application or deployed program).

I recommend looking for something of this nature. Either that, or let us know exactly where this occurs. You can isolate it by putting your program in Hightlight Execution. This will isolate subVIs. Subsequent runs will isolate this further. You should be able to pinpoint exactly where this occurs. Post the code, and more description of the problem, and I'm sure someone can help.

From your posting of the machine code, it seems to me that it is a fatal cleanup error. I don't know a whole lot of machine code, but the instructions indicate to me that you have a 16 byte pointer that
may not be handled properly. There isn't any clear way of finding out how to trace this back to the LabVIEW code, and I suspect you don't need to. Look for memory leakage or memory that isn't deallocated. This can occur in a number of ways.

Good luck, and keep us posted.

[Volodymyr Kudryavtsev]

Thank you very much for quick response. I still have troubles with the
Memory could not be "written" crashes. I have improved the performace to a
usable, but still inconvenient condition.

LabView crashes exactly at the moment of exiting from sub VI. If I set
"Suspend when called" property for this sub VI, no crash occures. If I
toggle off "deallocate memory as soon as possible" from the preferences,
then the crash will occur only when the window is closed. In the latter
configuration, the program will run repeatedly without crashing as long as
the window is not closed. Any ideas?

I have LabVIEW 5.1.1
The offending subVI contains only a few simple icons and 2 subsubVI's with
simple icons (array size(s), case structure, logic operators) and
a Call
Library Function calling C code from a dll. The C code runs alone quite
nicely, and those subsubVI's don't crash.

************************************************************
Dipl. Phys. Volodymyr Kudryavtsev
Max-Planck-Institut fuer Biophysikalische Chemie
Abt. fuer Spektroskopie und Photochemische Kinetik
Am Fassberg 11
D-37077 Goettingen
Tel:++49/551/201-1087
Fax:++49/551/201-1006
E-Mail: vkudrya@gwdg.de
http://www.mpibpc.gwdg.de/abteilungen/010/seidel/
************************************************************

[Greg_McKaskle2]

> LabView crashes exactly at the moment of exiting from sub VI. If I set
> "Suspend when called" property for this sub VI, no crash occures. If I
> toggle off "deallocate memory as soon as possible" from the preferences,
> then the crash will occur only when the window is closed. In the latter
> configuration, the program will run repeatedly without crashing as long as
> the window is not closed. Any ideas?
>
> I have LabVIEW 5.1.1
> The offending subVI contains only a few simple icons and 2 subsubVI's with
> simple icons (array size(s), case structure, logic operators) and a Call
> Library Function calling C code from a dll. The C code runs alone quite
> nicely, and those subsubVI's don't crash.
>


I've seen this numerous times. If thi
s were Las Vegas, I'd give you
odds of about 500 to 1 that it is the C code. The C code is writing
past the end of a string or array, and corrupting other data in the VI.
It is pretty common for the corruption to go unnoticed until LV tears
down the data of the VI and tries to access what was once a pointer or
handle and now has data written on it.

If the strings are being resized as handles from within the C code, then
make sure the size is big enough to hold the data and the four byte size
in the front. Also make sure to write the size into the string.

If the C code is just writing into the buffer, and the diagram is sizing
the string in advance, make the values a bit larger. If the C code
assumes that it has 2200 bytes and you only allocate 2100, then nothing
bad happens on calls that only write 1000 bytes or 2000 bytes. But when
the C code writes a full amount of data, the extra hundred bytes just
corrupted other data in the VI.

These are the two most common bu
gs with C code incorporated into a LV VI.

Greg McKaskle

[Labviewguru]

Volodymyr,

I agree with Greg that the C code is probably the problem. This error that you are receiving (you are running Windows 2000 or NT, by the nature of the fact that the system doesn't crash, and the error that you get.), which tells me that you have a serious issue with your code. The C code is almost definitely the problem (please post the subVI if possible so we can be sure) and should be looked at. Look for threads or memeory that are not properly cleaned up. If you want to test this to be sure, you can "comment out" the dll and see that it does't crash.

Having just reread your troubleshooting procedure, I am certain that the problem is memory allocation related, but don't want to give you a guarantee. The changing of the
setting "Deallocate Memory as soon as possible" and the subsequent change in the results indicates a definite relationship. Look there.

So that you are aware, whenever memory is allocated, threads are created, or other system resources of that nature are used, proper cleanup procedures have to be implemented, or a crash will occur. Windows NT (2000) handles this a lot better than 9x platforms, so you at least don't get a systemic crash.

I hope this helps.