10-26-2010 10:32 AM
In the release notes for the NI-DAQmx version 9.0 drivers I see there was a CAR ID 169815 that states "DAQmxRegisterEveryNSamplesEvent() is raising an unhandled floating point exception" was fixed, but I am curious to find out more information regarding the specifics of this fix: i.e. how can this error be reproduced, what behavior was observed for software using this function call when the error occurred, is there a way to confirm if an error I'm seeing is this error etc. stuff like that. My curiosity stems from an attempt to either confirm or eliminate this particular fix as a cause to an error I am seeing while using NI-DAQmx version 8.8. Yes I can upgrade versions and run to see if I no longer get the error I'm observing, but this does not provide the definitive closure of the issue that I hope to achieve - it is not adequate to simply have the error "disappear" I need to be able to confirm it is no longer a possibility in the system.
Is there some place more details about the various NI DAQmx CAR ID fixes can be found?
10-26-2010 07:12 PM
Hi KWM28,
There is no public repository of NI CAR information, but I looked this one up in our internal database because it sounded very familiar. I filed CAR #141892 in response to DAQmxRegisterEveryNSamplesEvent generates Win32 floating point exception?, which contains the code that reproduces the crash. It was cloned as CAR #169815 because a similar problem needed to be fixed in the E Series codebase. For some reason, the ID of the cloned CAR ended up in the NI-DAQmx Readme, not the ID of the original CAR.
The root cause was a few uninitialized floating point local variables in the M Series AI code. If floating point exceptions are enabled (via _control87() or by using a Borland compiler) and one of these variables happens to contain a pattern of bytes that represents a denormal or NaN, then passing the variables around raises a floating point exception. The fix was to initialize the variables.
If you build and run the code from the original forum thread, you should be able to look at the faulting instruction in a debugger and see if it's crashing in the same location in your app.
Brad