Fatal Internal Error: memory.cpp, line 638

[nbackes]

I recieved this error while running an application that we are in the final stages of testing.  I have not seen this error before, though these tests were not doing anything that we hadn't done in previous tests, except that we were running for a longer time and measuring more parts than we had before.  This error came up and when we clicked OK we got the blue screen.  On restarting the computer everything seemed to run OK.  We keep a log of what the station is doing and the last entry before this problem shows that we had a serial timeout error communication with one of the instruments two times in a row.  That is the last entry in our logs.

I hope someone can provide me with more information about what a memory.cpp line 638 error means, so I know what to check in my code.  I am not calling any external C code or dlls except for NI drivers for boards we have installed.  Our system consists of a Windows 2000 Dell computer, a PCI-1422 image board, two PCI-6143 multipurpose boards, and one PCI-GPIB board.  We are also using VISA to communicate with three serial devices.

Our software versions are

Labview 7.1

IMAQ Vision 7.1.0

NI-DAQmx  7.3.0f0

NI-IMAQ  3.0.0

NI 488.2  2.20

NI VISA 3.2

Thank-you,

Nancy Backes

[Dynamik]

Hi Nancy,

      I've seen the memory.cpp error under many different conditions and don't think there's a simple diagnosis.  But given the scenario you've describe, I'd be tempted to use Tools\advanced\Profile VIs to monitor the memory used by the different VIs in your program - in the hopes of identifying a "memory-leak".  I don't think "Profile" is available in the run-time environment, though.

luck/cheers

[Chris_Cilino]

Nancy,

In addition to using the profile tools of LabVIEW you might also consider using the task manager in Windows. There is a memory meter under the performance tab. If you see this steadily creeping up, it may mean you have a memory leak in your program.

Also, could you tell us a little more about your application. Are you using FieldPoint and andy type casting? Let us know.

Best Regards,

Chris C

Applications Engineering

National Instruments

[perfb@yahoo.com]

according to NI support forums, this 'line 638' error is a NI bug
somehow related to type casting, and passing args to DLLs, I am
getting it too. It appears to be a common bug in 7.1 at least.


nbackes wrote:
> I recieved this error while running an application that we are in the final stages of testing.  I have not seen this error before, though these tests were not doing anything that we hadn't done in previous tests, except that we were running for a longer time and measuring more parts than we had before.  This error came up and when we clicked OK we got the blue screen.  On restarting the computer everything seemed to run OK.  We keep a log of what the station is doing and the last entry before this problem shows that we had a serial timeout error communication with one of the instruments two times in a row.  That is the last entry in our logs.
>  
> I hope someone can provide me with more information about what a memory.cpp line 638 error means, so I know what to check in my code.  I am not calling any external C code or dlls except for NI drivers for boards we have installed.  Our system consists of a Windows 2000 Dell computer, a PCI-1422 image board, two PCI-6143 multipurpose boards, and one PCI-GPIB board.  We are also using VISA to communicate with three serial devices.
>  
> Our software versions are
> Labview 7.1
> IMAQ Vision 7.1.0
> NI-DAQmx  7.3.0f0
> NI-IMAQ  3.0.0
> NI 488.2  2.20
> NI VISA 3.2
>  
> Thank-you,
> Nancy Backes

[nbackes]

I want to thank those who have responded so far.  I don't have an answer yet, but will try to provide you with more information so maybe we can get a little further in solving this problem.

Since the last post we have had the error occur one more time.  So unfortunately I can't call it a one-off and assume it will never happen again.  But, we have also had hours and hours of error free run-time also...

Dynamik had suggested using the Profile tool to monitor the memory by vi.  I'm not exactly sure how to use this tool.  I was able to turn the memory checkbox on, and then it listed info on all the vis (lots of vis here, when loading the application it loads over 500 vis).  Do I have to then just select the "snapshot" button occasionally and see what has changed in memory usage?  I guess figuring out how to make use of the data it is providing is confusing me.  How do I tell which vis, if any, are causing memory problems without recording each one's information between snapshots?  Any advice here would be appreciated.

Chris C asked for more information on the application and asked about type casting.  He also mentioned using the memory meter. 

We tried running the memory meter while running one lot of parts on the software (about 3 hours of work) and did not see any increasing memory usage.  When we stopped the program we basically dropped down to our starting memory level.  I will want to keep this memory monitor running when we do a longer run, as it may be a memory problem due to database access or something like that, which we won't see unless we run a lot more parts.

The application is to automatically run parts through 4 different tests.  We are using plain old LabVIEW, not FieldPoint or real-time or anything like that.  We are using the database toolkit, and the Vision toolkit.  We communicate with a robot through a serial line (VISA) and have it move parts from test station to test station.  The software is all under one main vi - we are not doing any dynamic calling of vis or anything.  Each of the tests is started through setting a flag and the tests are running in parallel loops so they all can be run at the same time.  We can have four different parts under test at the same time, one in each test station.  When all of the tests are done the robot will move the parts on to the next test station and the finished parts back to the storage tray.  One of the test stations is using doing a visual examination - using a motor (Newport motor controller using GPIB interface), camera and image processor, and analog data collection.  One of the test stations is using a motor and analog data collection only.  The third station is using only a GPIB interface to an oscilliscope.  The fourth station is using analog inputs and a serial interface (also VISA) to a laser micrometer.   So far the memory.cpp errors have come right around the time we get a timeout error communicating with this serial laser micrometer.  I don't know if the serial error is the cause of the memory problem, or if the memory problem caused the serial error or if there is even any connection at all.  We have communicated with the device many, many times without problem and the only times we have recorded an error communicating with it we have also had this memory.cpp line 638 error. 

As far as type casting, the only place I see that we are doing type casting is when we call the IMAQ Cast Image routine (to convert from the acquired 8-bit image to a 16-bit image so I can add a number of images together and not go offscale) and when we use the database toolkit and get a record back and use the "database variant to data" vi to cast the data to the correct type.  So the only type casting we are doing is by calling vis provided by NI.

Does this additional information help at all?

I have a further question for perfb.  Where did you find out information about the line 638 error?  When I did a search of the NI site I did not find any hits on my problem.  I would like to read-up on any information anyone has on this.  How have you been working around this problem?

Nancy Backes

[Dynamik]

Hi Nancy,

      Your application sounds like more fun than what I'm working on! (except for the mem.cpp thing...)

Did a search of these forums for "line 638", and found among the "hits", a post by XU, which reproduces the same "line 638" symptom without any apparent reference to a DLL.  Here's the link

http://forums.ni.com/ni/board/message?board.id=170&message.id=100477&requireLogin=False

Save all your work before running the example below!

Almost half the hits also mention "DLL" - but it doesn't seem like you have anything exotic going on - besides, maybe, IMAQ VIs.

After reading your observation that memory looked OK in the Task Manager, it seems less likely that the Profile VI will help you - and 500+VIs is a lot to sift through!  Ideally, you could narrow the scope to a few [dark] candidates and watch them closely.  At this point, I might implement an event logger to document execution.  A simple VI that logs its own call-chain as well as a string control value, to a text file.  You could drop it in near crucial logic-branches (adding a bit of unique text) and then just wait for the error.  Based on what you see in the log (post error), you might then add more "logging" where execution seems to dissappear.  It should be possible to nail-down "the problem" in relatively few iterations (3 or 4?) - assuming there's a specific failure point.  Such a logger ought to open, write, flush, and close the file at every execution.

Intermittent errors!

[Neil.Pate]

Hi there,

I have been getting very similar error messages in a rather large app of mine. I have traced the culprit to a single wire in my code, which (in theory) should not cause any problems.

In part of my app, I write some info to a graph, this is done by reading out of a text file, taking the arrays striaght to the graph indicator (plotting two data sets, not huge amounts of info, possibly several hundred thousand points). This reliably crashes my application after a few hours! (Have checked all memory usage, no leaks at all).  If I remove this writing to graph wire from my code, the app runs for days with no problem.

Although I do have some custom DLL calls, the code in them does no memory management, and this crash does not occur any where near these DLL calls, so I would like to rule that out (also, the code does not crash if I remove this graph update, so that would also seem to indicate the DLL code is ok)

I have very little idea how to fix this, and for now (with more pressing problems), I just do not update the graph.

Sorry I couldn't be of any help, just thought I would share my experience.

Neil

PS: running LV7.0 on Win2k (+SP4)

[Dynamik]

Hi Neil,

      Would like to look at your code - is it possible to create/attach a (simple) example? - (note: this [new] subject probably deserves its own thread.

cheers!

[Neil.Pate]

Hi Dynamik,

I'm not sure I can separate off the bit that is crashing, its a small part of a much larger project which uses custom hardware, I will have to investigate further. Unfortunately, other projects have higher priority at the moment. I am looking for a VI that can clone myself

I wonder if the crash has something to do with the fact that graph VI in particular is being used in a web page using the built in webserver?

cheers
Neil

[rolfk]

---

@nrp wrote:
Hi there,

I have been getting very similar error messages in a rather large app of mine. I have traced the culprit to a single wire in my code, which (in theory) should not cause any problems.

In part of my app, I write some info to a graph, this is done by reading out of a text file, taking the arrays striaght to the graph indicator (plotting two data sets, not huge amounts of info, possibly several hundred thousand points). This reliably crashes my application after a few hours! (Have checked all memory usage, no leaks at all).  If I remove this writing to graph wire from my code, the app runs for days with no problem.

Although I do have some custom DLL calls, the code in them does no memory management, and this crash does not occur any where near these DLL calls, so I would like to rule that out (also, the code does not crash if I remove this graph update, so that would also seem to indicate the DLL code is ok)

---

Unfortunatly this is not as easy. While you seem not to crash near any of your DLL executions they very well can be the culprit.
A DLL making some wrong assumptions about buffers passed to it or going havoc on something it thinks is a pointer can modify completely valid process memory (hence no protection fault) but not valid in the context of the DLL call, and in doing so overwriting some memorey used in LabVIEW elsewhere. The error may go undetected for seconds, minutes, hours and sometimes even days, and only make itself appear at some completely unrelated moment. That can go as far that the application can suddenly work or crash at some completely unrelated changes because of the information moving around to different places after a recompile. Another indication that your DLL is involved in wrongdoings is for instance that your application crashs when you want to exit it.

The only solution to proof that the DLLs are not the culprit is to completely remove them and replace them by some dummy simulation VIs where necessary. Then stress test your application and if it now still crashes the DLL is probably not your wrongdoer.

Rolf Kalbermatter

Message Edited by rolfk on 01-13-2006 12:51 PM