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
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.
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.
> 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.
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.