I have a Procedure as follows.

procedure TForm_DB.Image1MouseMove(Sender: TObject; Shift: TShiftState; X,
  Y: Integer);
var
  xr,yr: Real;
  dx,dy: integer;
  SrcRect,DestRect: TRect;
begin
  if iScale=0 then exit;<- External SigFPE occurs here.
  mousePos.x:=X;
  mousePos.y:=Y;
  xr:=trunc(x/iScale+PanVect.x);
  yr:=trunc(y/iScale+PanVect.y);
  if middleDown=1 then
  begin
    SrcRect:=Rect(0,0,ImageWidth,ImageHeight);
    dx:=X-MouseClkDn.x;
    dy:=Y-MouseClkDn.y;
    DestRect:=Rect(dx,dy,ImageWidth+dx,ImageHeight+dy);
    Image1.Canvas.CopyRect(DestRect,ImageBuffer.Canvas,SrcRect);
  end;
end;

Mostly it works as expected.

However, after some reasonably complex computing, mostly involving TStringLists, it throws up an error:

"Project project1 raised exception class 'External SigFPE' in file 'unit5.pas' at line 435:
if iScale=0 then exit;"

The iScale variable at this point is 1.1394385252832742, so clearly the debugger is not actually indicating the correct cause of the exception.

Can anyone offer a way to try to seek out the cause?

Many thanks,

Dave Coventry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130628/30c8d07c/attachment.html>

...

Maybe memory got corrupted at some point before, then errors can happen at seemingly random locations.

Check your dbg setup http://wiki.lazarus.freepascal.org/Debugger_Setup

use all avaailable compiler checks
-Criot
-gh (heaptrace/linking)
-gt

What does the stack window show?

8087 style exceptions are raised on the next floating point instruction for speed optimization. If you want to raise the exception on the correct location you should insert an fwait opcode after every floating point operation which is very expensive.
See what happens in the code that is calling the procedure. If any external code is involved, then you could consider masking some floating point exceptions. Freepascal (Delphi compatible) enables all exceptions which is not the default for fe. gcc. Use the SetExceptionMask function in unit mask for that.

For more info see
http://www.c-jump.com/CIS77/reference/Intel/CIS77_24319002/pg_0201.htm

Ludo

We need to add that info to
http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips

Thanks, Martin, Ludo,

Sorry for taking so long to respond. I have rewritten a large section of my code which accounts for the delay.

I have had issues with using TStringLists in the past, specifically with passing a TStringList as an argument to (or returning from) a function. So I have rewritten my code to try to avoid doing this.

Basically I am reading a large Blob from a (Firebird) Database into a TStringList which has been declared as a global variable. This is the only Tstringlist.

This list contains commands for a vector graphic which is rendered, first on a Image buffer TBitmap and then copied (CopyRect) onto the Canvas of a Picture component.

The first pass works fine. The GlobalList is cleared and the Blob loaded and then rendered.

Selecting another Database entry also works fine: The globallist is cleared and reloaded from the new database entry, the scale is recalculated and the drawing is rendered correctly.

I can pan around the drawing as well.

However, I am using the Mousewheel to zoom in and out to enlarge portions of the drawing and this is where I am getting the SIGFPE.

After my using the Mousewheel (up or down), the application performs the zoom without error, but, on the first movement of the mouse, the SIGFPE occurs.

Check your dbg setup
http://wiki.lazarus.**freepascal.org/Debugger_Setup<http://wiki.lazarus.freepascal.org/Debugger_Setup>

0042A8D5 751a jne 0x42a8f1
0042A8D7 8b450c mov 0xc(%ebp),%eax 0042A8DA a3b0e26700 mov %eax,0x67e2b0 0042A8DF 8b4508 mov 0x8(%ebp),%eax 0042A8E2 a3b4e26700 mov %eax,0x67e2b4 0042A8E7 c705e0e2670001000000 movl $0x1,0x67e2e0 0042A8F1 c9 leave
0042A8F2 c20c00 ret $0xc
0042A8F5 0000 add %al,(%eax) 0042A8F7 0000 add %al,(%eax) 0042A8F9 0000 add %al,(%eax) 0042A8FB 0000 add %al,(%eax) 0042A8FD 0000 add %al,(%eax) 0042A8FF 005589 add %dl,-0x77(%ebp) 0042A902 e583 in $0x83,%eax 0042A904 ec in (%dx),%al 0042A905 64895d9c mov %ebx,%fs:-0x64(%ebp) 0042A909 8975a0 mov %esi,-0x60(%ebp) 0042A90C 897da4 mov %edi,-0x5c(%ebp) 0042A90F 8945f4 mov %eax,-0xc(%ebp) 0042A912 8955fc mov %edx,-0x4(%ebp) 0042A915 894df8 mov %ecx,-0x8(%ebp) 0042A918 d9ee fldz
<----------------------------------------- Exception raised here. 0042A91A dd0580e26700 fldl 0x67e280
0042A920 ded9 fcompp
0042A922 dfe0 fnstsw %ax
0042A924 9e sahf
0042A925 0f841b010000 je 0x42aa46
0042A92B 8b450c mov 0xc(%ebp),%eax 0042A92E a300e36700 mov %eax,0x67e300 0042A933 8b4508 mov 0x8(%ebp),%eax 0042A936 a304e36700 mov %eax,0x67e304

Regards,

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130708/6c9477ef/attachment.html>

Ludo Brands wrote

for speed optimization. If you want to raise the exception on the correct location you should insert an fwait opcode after every floating point operation which is very expensive.

Is there a way to enable this in FPC? Sometimes i get weird FP exceptions that i'm not sure they point at the proper place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130709/f0876945/attachment.html>

FPC does this by default. So if this is the problem, it is in external code (e.g. C libs/DLLs) or assembler.

"Marco van de Voort" wrote

On Tue, Jul 09, 2013 at 10:27:59AM +0200, Kostas Michalopoulos wrote: > > for speed optimization. If you want to raise the exception on the > > correct location you should insert an fwait opcode after every

floating

> > point operation which is very expensive. > > > > Is there a way to enable this in FPC? Sometimes i get weird FP

exceptions

> that i'm not sure they point at the proper place. FPC does this by default. So if this is the problem, it is in external

code

(e.g. C libs/DLLs) or assembler.

No, it does not as mentioned by Jonas in this bug report: http://bugs.freepascal.org/view.php?id=19368
But maybe (not tested) this directive can help:
http://www.freepascal.org/docs-html/prog/progsu69.html

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130709/c76287dd/attachment.html>

But maybe (not tested) this directive can help: http://www.freepascal.org/docs-html/prog/progsu69.html

Thanks, this is what i was asking for :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130710/63cef6d3/attachment.html>

I consider that a special case. I was talking about the general case.

Without it, the ability to convert hardware FP exceptions to language excpetions makes n osense.

I have searched the compiler's source. It emits FWAIT only in three cases:

* Trunc
* Round
* Store of floats if SafeFPUExceptions is set

So it's definitely not the general case. :)

Regards,
Sven

Then how do we get Delphi compatibility in this case? Does it only matter for older CPUs or so?