views:

111

answers:

2

I recieved a crash report from MadExcept from a user. The Exception was Invalid floating point operation.

The odd part though is that the callstack dies at @FSafeDivide.

I did a google and found out that this was a check for certain pentium chips which didn't do division correctly. If the test failed all the divisions would be done in software rather than hardware. I have the Pentium-Safe FDIV option turned on in my compiler settings.

Could this have caused the error? I also read somewhere else that the EInvalidOp which was the exception class can be a stack overflow or something.

Here's a snipit of the mad except message if you want to read it.

exception class : EInvalidOp exception message : Invalid floating point operation.

thread $1014 (TMyBossThread):
00403509 M5b3.exe System                @FSafeDivide
008300c9 M5b3.exe MMyWorkerThread    317 TMyBossThread.Search
0073e87a M5b3.exe MMyManagerThread 186 TMyWorkerThread.Execute
008e8c17 M5b3.exe madExcept             HookedTThreadExecute
0042c150 M5b3.exe Classes               ThreadProc
00405354 M5b3.exe System                ThreadWrapper
008e8af9 M5b3.exe madExcept             CallThreadProcSafe
008e8b63 M5b3.exe madExcept             ThreadExceptFrame
created by main thread ($864) at:
0073e828 M5b3.exe MMyManagerThread 171 TMyManagerThread.Create
+2  A: 

First, unless you actually have people still running on early Pentium I chips, you should probably turn that compiler option off. It's to address a glitch in a few specific CPUs, and any chip sold since 1995 has not had the problem.

Having said that, if you've got an invalid floating point operation in a division, the problem's most likely in your code somewhere, especially since FSafeDivide is the routine that's supposed to produce the right results. Take a look at TMyBossThread.Search, line 317, and see what it's dividing there. Also look at line 316, since stack traces can sometimes point you to the line after the one you care about.

Mason Wheeler
I will take this compile flag off since I now Know it's not relevant anymore. It was relevant when the project started (before 1995) and I doubt that the build instructions have changed much since then. :D
Daisetsu
If any of your customers are running this software on Pentium CPUs lower than 120 MHz, they've got bigger problems than the occasional divide going wrong. :-)
afrazier
+1  A: 

A few comments, before searching in the haystack:

  • "If it's not reproducible, it's not a bug but an anomaly". Don't waste time on What or Why but on How you can recreate it.
  • As Mason said, it's probably time to remove this compiler option. (D6 is almost 10 years old)
  • Do you know if it happens on a specific Windows version? For instance, Text-To-Speech working well on XP gives a "Floating point division by zero error" on Vista and up.
  • Supposing your code seems fine, what is called that would involve some floating point operations?

The 2 last ones refer to problems with the FPU registers being messed up:
See here for interoping with .Net and in the Help on Set8087CW for OpenGL

François
If the exception happens on the first floating point instruction in a routine, that is an extra strong sign to check out the last paragraph of francois' answer. It could be external code not properly fwait'ing to process exceptions.
Marco van de Voort