LabVIEW
Problem:Memory Corrupted in LabVIEW?
@sarmin wrote:
hi,
just to follow on this discussion thread, after a few fiddling about i found that even when running under labview7.1 platform the software will also fail with the same reason (labview memory corrupted on 'DAQmx Create Virtual Channel'). however, it is very unpredictable when it is going to fail. it is for sure less frequent than the executable one.
many thanks.
Ok, there are a number of quite different errors that can happen here and that all might show the same symptoms. The most simple are when you create Call Library nodes and simply get the parameter list completely wrong or use the wrong calling convention. This willl normally (a few rare exceptions might be possible) crash immediately in the called external code and you will therefore see the error quite clearly. There are however a lot more subtle error possibilities. If you create a Call Library Node for a function that expects to be able to write into a buffer it is very important to allocate in LabVIEW the correct amount of memory through Initialize Array or similar functions before passing the buffer to the Call Library Node. If you allocate a to small buffer here things can go really bad in very weird ways and there is absolutely no way LabVIEW could avoid this or help you better with this. The called function will then overwrite some memory somewhere in the LabVIEW heap memory space that it is not supposed to touch. This could manifest itself in an almost immediate crash, or in some seemingly unrelated crash such as crash another completely legitimate code part including other external code when that one executes. Another possible indication for such errors is that LabVIEW crashes when you close a VI or the entire application/development system as well as non reproducible crashes with significant difference in occurrence between eh development system and an executable.
So in your case there is basically the big question: Do you have any other external code in your application that is not part of NI-DAQ? Since the NI-DAQ driver is quite well debugged as far as such things go, it is not so likely that it would cause such crashes itself because of badly configured and setup Call Library Nodes. It might crash in some lower level driver somehow on your specific platform but the fact that it only does that intermittingly and with not the same behaviour between development system and executable really points to a badly configured Call Library Node and here especially to a buffer parameter that is not allocated big enough in LabVIEW (usually most Call Library Node beginners forget to allocate a buffer altogether expecting LabVIEW to magically know things about an external library it can't possibly know).
Remember one badly allocated buffer for a Call Library Node you or someone else created for you may cause all sorts of rare crashes including crashing other completely legitimate Call Library Nodes. So check your application for any Call Library Nodes that did not come with LabVIEW.
One more suggestion: When you say you have installed the latest NI-DAQ on your system make sure you install it on your development system too and allow the Installer to update the VI libraries in your LabVIEW development system too. Otherwise you can install the latest and best NI-DAQ and still may end up with an old or corrupted VI in your development system that gets copied into your application each time again.
Rolf Kalbermatter
Message Edited by rolfk on 12-11-2006 12:09 PM
