问题
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
回答1:
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.
回答2:
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
回答3:
This (german) article describes a case where switching on the Pentium(tm)-safe divide ($U+) fixed a Data Execution Prevention error on a Windows 2003 Server system, which has DEP enabled:
http://entwickler-forum.de/archive/index.php/t-41207.html
Delphi 2009 still has this compiler flag with default $U- (no Pentium(tm)-safe divide.
So even if we can forget about the hardware related part (broken CPUs), it still could make a difference depending on Operating System 'features' like DEP
来源：https://stackoverflow.com/questions/3681244/delphi-6-compiler-options-pentium-safe-fdiv