Fatal Internal Error : "memory.cpp", line 638

[ASteiner]

I am relatively new to LabView, and I am attempting to build a front end application to control acquisition and analysis of some data coming from a NI DAQ and an RFID reader. Right now the VI is able to initialize all of the hardware without issues the first time I run the VI, but if I stop the VI and then restart it I get the error in the subject line of this post: "Fatal Internal Error: 'memory.cpp', line 638". I have isolated the location in the Sub-VI where the error occurs and it is after one of the DLL library calls I make to run the RFID reader. The error however seems to be internal to LabVeiw. Does any one have any suggestions as to what is causing this error, or what memory.cpp is?

FYI, I am using LabView 7.1 Express on a WindowsXP SP2 machine.

[ASteiner]

Here is the output from the error logfile:

####
#Date: Tue, Nov 20, 2007 1:36:53 PM
#OSName: Windows NT
#OSVers: 5.1
#AppName: LabVIEW
#Version: 7.1
#AppKind: FDS



D:\lvmerc\src\source\manager\memory.cpp(638) : DAbort:
$Id: //labview/branches/Mercury/dev/source/manager/memory.cpp#10 $
0x004650BD - LabVIEW <unknown> + 0
0x004651C0 - LabVIEW <unknown> + 0
0x004C0F1C - LabVIEW <unknown> + 0
0x05C2C87A - <unknown> <unknown> + 0
0x0153D0F0 - <unknown> <unknown> + 0
0x00A09110 - LabVIEW <unknown> + 0
0x8B535CEC - <unknown> <unknown> + 0

[ASteiner]

I have done a bit more digging in the NI forums and it looks like this is an error others have come across, however no one has posted any concrete solutions to the issue yet. In all of the threads reporting this error the users are working in LV 7.1, so is the solution just to upgrade?

[Jason_Whaylen]

Hey A Steiner,

Thank you for contacting National Instruments.  The memory.cpp indication you received can mean many things.  Most often it is for indicating a corruption in memory, or reallocation of reserved memory.  In looking into this issue, I have located a CAR '3C3BOL8V' that was filed for this problem.  It has since been closed and therefore should be resolved in more recent versions of LabVIEW.  We attempt to resolve most bugs that are located and reported in the subsequent version of LabVIEW.

Due to the different possibilities of this error, any possible workarounds could vary greatly.  You may have referenced the discussion forums found here and here, but they provide different suggestions for trying to avoid the error they encounter in their circumstances.

I hope this helps!  If you have any related questions or need more clarification please let me know.  I hope you have a great Thanksgiving weekend!

Jason W.

[ASteiner]

Jason,

Thanks for your reply. I have just downloaded the evaluation version of LV 8.5 and the error no longer occurs so it looks as if this DLL access issue has been resolved in more recent versions. Is my best bet then to upgrade to 8.5? For cost reasons I would like to continue developing in 7.1.1 for a few months if possible.

[instrumento]

Second that motion.  Is there a patch for those of us stuck in 7.1 or 7.1.1? The time cost (not necessarily the money cost) to upgrade to newer versions is sometimes prohibitive.

[Jason_Whaylen]

Hi Instrumento and ASteiner,

Thank you for posting to the forums.  Hopefully, each of you have been able to find alternative methods to avoid this error in LabVIEW 7.1.  Unfortunately, due to the frequency of updates that we provide, we do not normally have patches for individual or groups of bug fixes.  Instead we look to correct the bug and maintain that fix through all future releases.  Therefore, any LabVIEW version 8.0 and onward should provide that this will not occur.

The best suggestion that I can provide for a LabVIEW 7.1 user would be to look in the LabVIEW 8.0 Upgrade notes and reference that CAR ID I provided previously.  Often times through this means we will provide any workaround method that was developed when this issue was identified.

I hope this helps!  Have a great day!

Regards,

Jason W.

[cdweiss]

I am experiencing a similar problem.  These posts seem very  3C3BOL8V or the CAR 3GKCEKSN related to SR 635103 in the links in the one post only find this post.  Can someone please post me to the LabVIEW version release notes where this problem is reported as fixed.  I'd like to know the description of the fix and what particular version it was fixed in.

[Robbob]

As Jason mentioned, there can be many reasons why you may recieve a memory.cpp error.  The specific cause mentioned in your linked CAR's (typecasting void data) seems to be fixed in 8.0.  You can find the 8.0 release notes and readme here.  I am not sure exactly what you are looking for, however, as we normally don't release exactly how we fix issues, just that they are fixed.  Your best bet, as always, is to keep an updated version of LabVIEW.