Floating point division by zero exception in Delphi5

Question

My app is written in Delphi5. I am using madExcept to track down bugs. I tracked down a "Floating point dvision by zero" exception, where it shouldn't be. The code segment, where it is raised, goes as followed:

val:=100*Power(1.25,c);

where 'c' actually always has the value '1'.

The stack trace of the log:

main thread ($338f8):
00403504 +010 MyApp.exe   System   1970  +5 @FRAC
00479148 +058 MyApp.exe   Math              Power
007ae8a6 +262 MyApp.exe   MyClass  1962 +36 TMyClass.FormMouseWheel

I had another exception at one point, where a division did take place, however the divisor was a variable, which also had the value '1' when the exception occured. That i was able to debug and reproduce.

My question: what am i missing? Are there some false positives about floating point division that i am not aware of?

Furthermore: I am not using any C++ DLLs at the exception points as they tend to handle FP divisions differently (returning NaN or +/-INF rather than raising an exception).

Any pointers appreciated.

Shelly

Doesn't sound very plausible. I don't think your debugging tools are pointing you to the right place, or perhaps the variables aren't holding what you think they are. – Bohemianism

Don't remember if D5 already had it, but did you try to check what's happening in the CPU/FPU view when that code is executed? – Typography

@ldsandon Of course D5 already allowed to use Alt-F2 and step into the CPU/FPU view. Good idea. But I guess an unhandled FPU exception will break in the System._Frac code. – Archduchy

Are you using any external DLLs at all? If so, they might have changed the FPU control word. See this posting on some more info: wiert.wordpress.com/2009/05/06/… – Boland

Answer 1

I just tried the following code:

procedure TTTest.FormCreate(Sender: TObject);
var v: extended;
    one: extended;
begin
  one := 1.0;
  v := 100*Power(1.25,one);
end;

It just compiles and runs as expected in Delphi 5.

My guess is that the division per zero flag may be set outside your code (even if you do not link to C++ code, calling Direct X or such may have the same effect), but raised later, in _Frac.

The only call to Frac in the standard implementation of Power() is to test Frac(Exponent) = 0.0.

There was a modification in the implementation of Frac between Delphi 5 and Delphi 6.

Here is the Delphi 5 version:

procedure       _FRAC;
asm
    FLD     ST(0)
    SUB     ESP,4
    FSTCW   [ESP]
    FWAIT
    FLDCW   cwChop
    FRNDINT
    FWAIT
    FLDCW   [ESP]
    ADD     ESP,4
    FSUB
end;

Here is the Delphi 6 version:

procedure       _FRAC;
asm
    FLD     ST(0)
    SUB     ESP,4
    FNSTCW  [ESP].Word     // save
    FNSTCW  [ESP+2].Word   // scratch
    FWAIT
    OR      [ESP+2].Word, $0F00  // trunc toward zero, full precision
    FLDCW   [ESP+2].Word
    FRNDINT
    FWAIT
    FLDCW   [ESP].Word
    ADD     ESP,4
    FSUB
end;

From the above code, you'll find out that the following commands caused the delayed exceptions to be raised before Delphi 6 was released: Trunc, Frac, Ceil.

So I guess you faced an issue with Delphi 5, which has been fixed with Delphi 6. You may have to use your own version of Power, like this one:

function Power(Base, Exponent: Extended): Extended;
begin
  if Exponent = 0.0 then
    Result := 1.0               { n**0 = 1 }
  else if (Base = 0.0) and (Exponent > 0.0) then
    Result := 0.0               { 0**n = 0, n > 0 }
  else
    Result := Exp(Exponent * Ln(Base))
end;

Archduchy

Great answer that pointed right to the problem for me. Minor nit-picking, but the answer could be improved with comments explaining what each line of assembly is doing - at least for the key lines. Or alternatively, summarize what each _FRAC procedure does (push old CW on stack, set new CW, do operation, pop old CW from stack, that sort of thing). Would help for those of us not well-versed in x86 assembly. :) – Palestra

Answer 2

Not a definitive answer by any means, but...

Fpu related exceptions where there shouldn't be, could be related to the FPU stack not being cleared properly. We had similar problems at one stage, though we experienced Invalid Floating Point Operation exceptions.

This article: Delphi bug of the day: FPU stack leak where somebody tracked down the reason for an Invalid Floating Point Operation exception thrown by S := S + '*'; , helped us resolve the issue.

Lupelupee

Answer 3

Are you using TWebBrowser or any IE webbrowser component like EmbeddedWB?

If so, this might explain it: https://forums.embarcadero.com/thread.jspa?messageID=334125&tstart=0

It also contains something that might fix the problem, even if you're not using a webbrowser (Set8087CW) as the link provided by Jeroen above describes.

Tactful