Hi,

what makes a calculation like this:

  result := 4*Q / (pi*ny*d);

throw an error:

An unhandled exception occurred at $080897AB :
Exception : Unknown Run-Time error : 208

and what is the cause and nature of error 208?

(I feel a little stupid, I've searched the .pdf-docs and the freepascal site and wiki to no avail ...)

TIA,
Marc

Marc Santhoff wrote

and what is the cause and nature of error 208?

An unknown/unsupported fpu exception (in the FreeBSD rtl at least, on other platforms this is mapped to rte 207).

Jonas

At least it should be mapped to 207 on FreeBSD as well I suppose.

That's why I knew I had seen this number, it's in the procedure SignalToRunerror(), so I'm not so stupid after all. ;)

Is there any other way of examining the cause besides looking at the values of the variables involved in the calculation?

Many thanks,
Marc

You could check whether signaltorunerror is maybe missing some entries in its case statement for SIGFPE reasons, and add any missing ones (and if so, submit a patch for that).

Jonas

I think so too.

Jonas

The cause was an (easy to detect) division by zero. I expected such errors to be caught ...

The code for FreeBSD in question looks like this:

case sig of
    SIGFPE :
          begin
            Case Info.si_code Of
                FPE_INTDIV : Res:=200;  {integer divide fault. Div0?}
                FPE_FLTOVF : Res:=205;  {Overflow trap}
                FPE_FLTUND : Res:=206;  {Stack over/underflow}
                FPE_FLTRES : Res:=216;  {Device not available}
                FPE_FLTINV : Res:=216;  {Invalid floating point operation}
               Else
                Res:=208; {coprocessor error}
                End;
             sysResetFPU;
          End;
    SIGILL,
    SIGBUS,
    SIGSEGV :
        res:=216;
  end;

What model of the i386 would be the best one for making a start?

I'd at least try to get the programmers manual for looking at the FPU exception codes. Or maybe someone know a better way to get the necessary information ...

Marc

You shouldn't need any cpu/fpu flags info. grep -r /usr/include for FPE_INTDIV, and see if there isn't also a constant for a floating point division by zero in the same file.

Jonas

Ah, now I understand. But I'm stuck at the error number for fpc, is rtl/objpas/sysconsts.pp the authoritative source?

Mine from 2.0.4 looks like this:

<snip>
     200 : Result:=SDivByZero;
     201 : Result:=SRangeError;
     203 : Result:=SOutOfMemory;
     204 : Result:=SInvalidPointer;
     205 : Result:=SOverFlow;
     206 : Result:=SUnderFlow;
     207 : Result:=SInvalidOp;
     211 : Result:=SAbstractError;
     214 : Result:=SBusError;
     215 : Result:=SIntOverFlow;
     216 : Result:=SAccessViolation;
</snip>

If I follow this scheme it'll be surely inconsistent afterwards and may break existing code.

As you can see, the number 208 is not taken, yet.

Together with the list (and adapted comments reflecting those from the FreeBSD source) the resulting code would be:

     begin
       Case Info.si_code Of
             FPE_INTOVF : Res:=205; {integer overflow}
             FPE_INTDIV : Res:=200;  {integer divide by zero}
		FPE_FLTDIV : Res:=200; {floating point divide by zero}
             FPE_FLTOVF : Res:=205;  {floating point overflow}
             FPE_FLTUND : Res:=206;  {floating point underflow}
             FPE_FLTRES : Res:=???;  {floating point inexact result}
             FPE_FLTINV : Res:=???;  {Invalid floating point operation}
             FPE_FLTSUB : Res:=???; {subscript out of range}
       Else
             Res:=???; {coprocessor error}
       End;
       sysResetFPU;
     End;

Note the ???'s there I do not know, which way to go.

Marc