Unerklärliche external SIGSEGV

[fpGUIcoder]

Hallo,

ich sthe vor einem mir unerlärlichen Problem. Ich erhalte eine external SIGSEGV an einer Stelle, wo eine Multiplikation stattfindet. Jedenfalls springt der Debugger auf solch eine Programmzeile. Eine Division durch könnte ich als Ursache nachvollziehen und den Quellcode anpassen, aber bei einer Multplikation? AUf einer CPU, in der der mth. Coprozessor integriert ist???

Ich lade mal einen Screenshot hoch, wo zu sehen ist, was ich meine:

Die Exception tritt im Demoprogramm agg_canvas_test.lpr der fpGUI 1.2 auf.

Was ist da los?

[TBug]

Ich kann DIr zwar momentan nicht helfen, aber teste einmal den unten stehenden Code und Du wirst eine ähnliche Überraschung erleben.

Code: Alles auswählen

 
unit Unit1;
 
{$mode objfpc}{$H+}
 
interface
 
uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs;
 
type
 
  { TForm1 }
 
  TForm1 = class(TForm)
    procedure FormClick(Sender: TObject);
 
  private
    { private declarations }
  public
    { public declarations }
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.lfm}
 
{ TForm1 }
 
procedure TForm1.FormClick(Sender: TObject);
var
  lSingle: Single;
  lDouble: Double;
  lDummy: Integer;
begin
  lDouble := 0;
 
  lDouble := 888888888888888888888888888888888888888888888888888888888888888888888888888888888888;
 
  lSingle := lDouble * 0.5;
 
  lDummy := 0;
 
  lDouble := 0;
 
end;
 
end. 
 

Projekt project1 hat Exception-Klasse »External: SIGFPE« ausgelöst.
In Datei 'unit1.pas' in Zeile 46

.

[Socke]

Ich erhalte eine external SIGSEGV an einer Stelle, wo eine Multiplikation stattfindet. Jedenfalls springt der Debugger auf solch eine Programmzeile. Eine Division durch könnte ich als Ursache nachvollziehen und den Quellcode anpassen, aber bei einer Multplikation? AUf einer CPU, in der der mth. Coprozessor integriert ist???

Hier geht es nicht um eine SIGFPE sondern um eine SIGSEGV. Das heißt: die mathematische Operation ist nebensächlich. Es wird auf einen Speicherbereich zugegriffen, der deinem Programm nicht zugeteilt wurde (z.B. Objekt wurde bereits freigeben). Die Ursache für die SIGSEGV muss nicht dort liegen, wo der Debugger hin springt.

[TBug]

Die Ursache für die SIGSEGV muss nicht dort liegen, wo der Debugger hin springt.

Genau dies wollte ich mit meinem Beispiel verdeutlichen.

Auch in meinem Beispiel ist die Ursache des Fehlers nicht an der Stelle zu suchen, an der sie in Erscheinung tritt und in welche der Debugger springt. Die Ursache liegt schon weiter oben im Code.


.