LabVIEW 8.6.1 crashes

Question

Good Day All,
   I've got an application where I'm getting intermittent crashes, sometime when in edit mode, sometimes when my program is actually running. I have gotten a couple of "MemoryManager.cpp  line 437" crashes, but more often, but still intermittently, I just get the window that says something has happened to LabVIEW and it needs to be terminated. When you click on the more information link it pops up a window that says:
"AppName:labview.exe   AppVer: 8.6.0.4001  ModName: Unknown
ModVer.: 0.0.0.0        Offset 6f636974"
This happens when running the application or when editing. It may happen twice in an hour, or after several hours of running. I've watched the memory and thread usage in "Task Manager" and they seem to be stable.
The program has two main parts, a UI that at the beginning of the test run uses a .NET call to read back data over the network from the Unit Under Test, parse the returned XML string (using string functions, no "XML parsing" functions from LabVIEW or Windows) and a user interface to start the program. The UI sends a message over a queue to the "Test Engine" which then, depending on the "test recipe" installs and launches the appropriate test program using a "Call by Reference Node". The test program makes measurements of the UUT and saves the results to an Excel file using NI Report vi's from the NI Report Generation Toolkit. The measurements are visa calls to standard "rack and stack" instruments like spectrum analyzers and signal generators.
I've done a moderately deep search on the NI site, haven't found anything that looks like the issue, need ideas how to trap this beast and eliminate it.
I hope that many of the major players being at NIWeek won't impact the response time. It seems like those years I haven't been able to attend are the ones where I hit a snag like this one. I guess the moral is that I should always attend
Thanks in advance,
Putnam
Putnam
Certified LabVIEW Developer
Senior Test Engineer
Currently using LV 6.1-LabVIEW 2012, RT8.5
LabVIEW Champion
Solved!
Go to Solution.

Answer 1

Looking at this specific error, LabVIEW's memory manager has decided that a memory handle is invalid. One case in which this can happen is when different versions of LabVIEW are in use simultaneously and a data handle is passed from one version of LV to another. One such scenario would be:
LabVIEW 2009 calls the function 'myFunc' from 'foo.dll'
'foo.dll' was built using LabVIEW 8.6
'myFunc' expects an array of data, passed as a LabVIEW array handle
The problem arises in this case because the array handle allocated by the LabVIEW 2009 instance of the LV memory manager is sent to a VI running in the LabVIEW 8.6 Run-Time Engine, which has the LabVIEW 8.6 version of the memory manager. Because the data is an array handle, and LabVIEW may need to resize the handle, the code in the LV 8.6 Run-Time inspects the data handle to see if its memory manager considers it a 'good' memory handle (i.e. one that it allocated itself). It discovers that the LV 8.6 Run-Time didn't allocate the handle, and, being mistrustful of data from other memory managers ( ;-) ) it has no choice but to abort the application. It's either that or corrupt memory.
In such cases, a workaround is to pass array pointers (or strings) that cannot be resized -- an unsavory situation if the underlying implementation must resize the array (or string). The workaround in that case is more complex - e.g.. having two functions - a 'preflight' that tells you how big the output will be, and the 'actual' function that requires a properly sized output buffer.
For more complex data structures (e.g.. clusters) the workaround is to break apart the cluster into individual, simple types that can be passed as pointers to data or simple scalar values.
Whether this is at all similar to your case is unclear - it sounds like there are several component layers involved with different technologies. But the crash itself is still that LabVIEW 8.6 has gotten a memory handle from somewhere that's *not* been allocated by the LabVIEW 8.6 memory manager.
One thing you could do with Process Explorer and similar tools is determine if there are multiple versions of LabVIEW in the main process. For example, if both LabVIEW.exe and one or more lvrt.dll instances from different locations on disk are in memory, you've found a red flag. The quest then is to find out which components in your software stack are responsible for bringing in those different versions of LabVIEW, and how they're interacting via code.
Best regards,
intvsteve
LabVIEW R&D