LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What is memory.cpp at line 1038?

I can give you a generic description of what this is complaining about. Some piece of code asked us to deallocate an invalid memory block. There are many ways of arriving at this type of symptom though. It could be the result of memory corruption. It could be related to calling LabVIEW built DLLs that were built with different versions of LabVIEW. Since you are seeing this in LabVIEW 7.1, I would suspect calling external DLLs is involved.
 
Sending the log file to support is definitely a good start, but is unlikely to pinpoint this type of problem. The only sure fire way is to provide enough information to support so that we can reproduce the problem here. Any work you can do to narrow down the problem is greatly appreciated. Try to identify the portion of the code causing the problem and extract that into a smaller hierarchy that will still reproduce the problem. If you can provide us with a way to see the problem happen on our machines, we will be able to track it down.
Message 11 of 16
(1,068 Views)
Were any of the VIs that you are using written in LabVIEW 5.1?  If they were written in a previous version, you would need to open them all in LV 7.1 and recompile all of the VIs that you are using.  And if you are using any typedefs written in 5.1, you will need to save them for 7.1 as well, or even recreate them in 7.1.  Then rebuild your executable and see if the error occurs again.  This error will occur if there is a corrupt VI in your program, so most likely a mass compile will resolve the issue. 
 
Also, the error log file for this error would be helpful.  When the error occurs, you should report the error and the log will be sent to NI and that will help us find where exactly the error is coming from.
Brian Coalson

Software Engineer
National Instruments
0 Kudos
Message 12 of 16
(1,033 Views)
I believe that the error occurs in the Storage VI library.
 
I have isolated the issue to a section of code in a VIT.  The VIT is spawned off dynamically.
 
If I remove the code from the dynamic VI.  The error does not occur.
 
This section of code uses the Storage VIs to open a TDM file, close a TDM file, read a group, channels etc.
 
I am curious whether other users with the issue are using TDM.
 
Jim West
 
0 Kudos
Message 13 of 16
(1,001 Views)
Jim,
 
Would you mind posting this code that is causing the error?  Thanks.
Brian Coalson

Software Engineer
National Instruments
0 Kudos
Message 14 of 16
(955 Views)
The code is too build to post. I have submitted to NI for tech support. - Jim
0 Kudos
Message 15 of 16
(949 Views)
NI has recreated my problem using code that I sent in to them.  As part of the debugging process, I put a semaphore around each Storage TDM VI call.  (Anything that uses the storage.dll).  This has cleared up the problem.  The conclusion is that there is a problem with the storage.dll.
 
Even though calls to the storage vis are not reentrant, the calls themselves were not safe.  Different vis would attempt to use the storage.dll at the same time.  Sometimes this results in the Memory error.
 
Other times various TDM errors can occur.  Sometimes a -2558 error will occur when opening a file that was recently closed by DIAdem. 
 
-2570 was also received when attempting to close the file.
 
Note that all TDM IO calls must be coordinated.  Any access to any file at the same time may result in an error or worse a CPP error.
 
Jim
 
0 Kudos
Message 16 of 16
(897 Views)