LabVIEW causes an access violation on its call to CheckFPStat

[plasmaboy]

I created a logger that communicates with a multitude of devices through DAQ, GPIB, and RS232. My program has been running successfully for over a year. With the last version of my program being updated over a month ago (i.e. last version has been running for over a month). Users would start logging data and stop logging after approximately 24 hours. There have been occasions where the logger was left on over the weekend, generating logs over 100 Mb in size, with no problems. However, recently, LabVIEW has caused an access violation several times on two identical computers running the same program. Some of these crashes occurred when the log was quite large ~100 Mb, and another crash occurred when the lo
g was smaller ~30 Mb. I do keep a reference open to the file as I continue to write; however, I have used this method to continually log in other similar applications with no problems.

Going through the log generated by Dr. Watson, the fault always occurs when LabVIEW calls an internal function called CheckFPStat. What does this call do? Is it the cause of the crash? If not, what else could be causing LabVIEW to crash?

I am running Pentium 3's with Win 2K

[Greg_McKaskle2]

> Going through the log generated by Dr. Watson, the fault always occurs
> when LabVIEW calls an internal function called CheckFPStat. What does
> this call do? Is it the cause of the crash? If not, what else could
> be causing LabVIEW to crash?
>

CheckFPStat checks to see if the floating point unit has been left in
the right mode. The check is there, because historically, meaning back
in the early days, a DLL or driver would return to LV and the floating
point unit would have a different rounding mode, have exceptions
switched around, or something else that would cause incorrect answers on
the LV diagram. More than likely, that is what is going on here as
well. With lots going on, lots of other components, it will be tough to
tell which left it
messed it up. If you have a decent guess as to what
just completed, you might try to update that driver or stress test it to
see if you can make the problem more reproducable. Similarly, if one of
the elements changed recently, suspect that one first.

Greg McKaskle

[DL84]

Greg,

I have the same problem, with the only difference being that I have added a fieldpoint system to my hardware.

How can I check for what you listed as the likely problem?  The fieldpoint IO are referenced about 9 times, and I did run a conversion function to their input to double floating point but still won't run after compiled...

[DL84]

Anyone have any ideas?

[AdnanZ]

Hi leachdor,

I hope you are doing well today! Is it possible for you to try your application in LabVIEW 8.2.1? Also, when it causes the crash, it should be giving you a link to the log file and provide you with an option of sending National Instruments an email. It would be great if you can proceed with that step so the issue can be escalated to R&D.

[VanceS]

I too have fallen prey to the CheckFPStat crash.  My application is a large one whose main function is to communicate with various devices on GPIB (via ENET-100s), VXI, and Ethernet and display information gathered from the devices as well as perform control operations.

This application ran pretty well (with an occasional crash in thread.cpp that happened once in a blue moon, not often enough to do anything but upgrade when we got a chance) under LabVIEW 6.1.

I came in this morning and it had been running for 3 days, although the app had lost the ability to talk to one of our Agilent/HP power supplies on one of the 3 GPIB busses (via ENET).  I went away for a few hours, came back and saw the LabVIEW crash, which according to drwatson was in function CheckFPStat.

This application is very large, 500+ VIs altogether, and from what I read in this thread its going to be near to impossible to isolate the problem without actually analyzing the user.dmp file associated with the crash.

I had one thought though that prompted me to write.  I use -Infinity to signal a problem collecting data from an Omega meter I have on the Ethernet (the original code didn't have provisions for a seperate path to signify errors and using -infinity was expedient).  Could passing Infinities around possibly cause this kind of crash?

[VanceS]

I forgot to mention that I upgraded to LabVIEW 8.2.1, and this possibly satisfies a request earlier in the thread to see if crashes occur in CheckFPStat after an upgrade to that version.