This has been puzzling me for the last several days!
We have an application where we’re running into a divide-by-zero. That application is purposely built to raise exceptions in such cases, with a call to the _controlfp_s function to change the masks on floating point exceptions.
Now, when running into a divide-by-zero on pretty much all of our machines, Visual Studio 2005 debugger breaks at the proper location within our source files. However, on 1 machine, the break location is all over the place and appears to be irrelevant to the actual cause of the break. So as a test, I built a simple C win32 program with just the following lines of code:
int main(int argc, char *argv[])
{
float temp1, temp2, temp3;
unsigned int control;
_controlfp_s(&control, (_EM_UNDERFLOW + _EM_INEXACT, _MCW_EM);
temp1=1.0;
temp2=0.0;
temp3=temp1/temp2;
return 0;
}
On all those “good” machines, the code does break at temp3. However, on the bad machine, the code breaks at:
C:\Program Files (x86)\Microsoft Visual Studio 8\VC\crt\src\tidtable.c
function:
__set_flsgetvalue()
Looking at the registers as I step through the assembly code, everything looks fine until I hit the “fstp” instruction… then all the registers seem to be messed up (vs looking as expected on a good machine). When comparing the stack on the good vs bad, I also see stack entries on the bad machine, which I don’t see on the good one…
I’m skipping quite a few details here in an attempt to keep this first pass short… but I’ll add up more if someone is so kind as to try to help.
Notes:
OS Win7 x64, running all the latest VS2005 Service Packs. Compared to a similar (working) machine running same software and service packs. Getting same weird behavior when running on VS2010.
Thanks in advance.
Wow!
After showing this post to a friend… he found an intel document showing very similar symptoms about some of their cpu’s… I then found the exact document that applied to our specific CPU (intel i5-2500) here:
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/2nd-gen-core-deskt…
See errata BJ1
This pretty much exactly describes what I’m running into! I never (seriously) thought it would be an issue at THAT level!