PXI crash down (DWarn: Internal error 2)

[tom_ifms]

My PXI controller 8108 crashes after an undefined run time (typically about 1 h). After the crash down the communication to the PXI is interruped. Afterwards I could retreve the error log that you find attached.

There are two related documents I found on the NI web-site:
1. Discussion forum: 'Free RTOS heap memory'
2. LabVIEW 2010 and 2010 SP1 Known Issues: '45802 4IDA53I0'

The discussion forum entry seams quite to hit my situation, only that it doesn't contain a direct solution.
As to the known issues: I indeed do have fixed size arrays on my [fpga]_main.vi front panel that are used for communication with the host. However I don't understand why the crash would happen after un undefinded run time and not right in the beginning (I've been using similar code with this config for quite some time and never had any problems).

Further it seems suspicious to me that the error log indicates  the [host]_LoadVectBlocks.vi as crash location allthough the controller is running in a state where the block diagram of this vi should not execute since the 'Axis to load'-array is an empty array in this running state, thus the for loop should be jumped over.

Does anybody have an idea what the problem could be?

Can anybody help me with interpreting the error-log, since I don't understand much of this text? What's the general meaning of 'error 2' for example?

[Texas_Diaz]

Can you additionally provide the file rtlog.txt found in /ni-rt/system ?

-Danny

[tom_ifms]

...here you go. Indeed the free RTOS heap memory is down to zero as well...

[tom_ifms]

The RTOS heap memory entry in the rtlog.txt is without meaning, as I just found out: 0x80000003-Real-Time-exception (I'm using a PXIe8108)...

... I've been displaying memory usage with the 'RT Get Memory Usage.vi' and there is nothing suspicious right before the controller crashes.

[gregorelectric]

Hey Tom,

this is an Error you get when you're out of memory. So i suspect a memory overflow in a queue. Please monitor the Memory with the NI Distributed System Manager and change your program.

Monitoring CPU and Memory Usage on Real-Time Embedded Targets

http://digital.ni.com/public.nsf/allkb/8C7B655978C8ADFB86256AAE004AD261?OpenDocument

Why Are CPU and Memory Usage Not Visible in Distributed System Manager?

http://digital.ni.com/public.nsf/allkb/FA5C65FF5645FA5A862575D30029B6E4?OpenDocument

Gregor

[tom_ifms]

Thank you guys, that will help me next time. For this time I found that the problem had its origin somwhere else before the system crashed: An overflow wrapping when adding two int32 caused the code to go in an unpredicted situation; somwhere later on it eventually ran into the crash.

Conclusion:

1. I still don't know how and why the crash was eventually caused and I don't have time to investigate that further.

2. I learned that LabView arithmetik functions and type conversions do not saturate but overflow! ...which I didn't expect (it's not mentioned in the functions help either). However, now after searching for the issue, I found it mentioned on the web site: How do I make LabVIEW coerce to Max and Min values when Adding and Subtracting?