Hallo,

ich habe folgendes Problem: Wenn ich mein recht großes Programm debugge, kommt es ab und zu vor, dass eine Gleitkommadivision durch 0 nicht sofort vom Debugger gemeldet wird (auch Getlasterror ist 0). Das ist erst der Fall bei dem nächsten mal, dass ich trunc aufrufe. Ich kann den eigendlichen Fehler also nur finden indem ich zeilenweise trunc einsetze...

a:=trunc(a);
procedureA;
a:=trunc(a);
ProcedureB;
a:=trunc(a);
...

Das ganze ist nun mal ziemlich kompliziert und ich wollte mal fragen, ob da schon jemand was ähnliches erlebt hat. Ich benutze Delphi5 prof und WinXP...

Wir hatten das Problem, das bei einigen AMD-Prozessoren gar keine Exception bei Division durch 0 kam, dementsprechend nur Müll in der Zielvariable stand.

D.h. -> Division durch 0 vermeiden, also vorher prüfen, ob eine Division durch 0 stattfinden wird. Wenn ja, definierten Zielwert von Hand setzen oder was weis ich.

Ist ne Menge arbeit, aber hilft garantiert.

Moin BomberBB,

nehmen wir mal folgenden Code:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TForm1.DoDivisionByZero();
var
  Res: Integer;
begin
  Res := 5 / 0;
end;

procedure TForm1.DoSomething();
begin
  ShowMessage('Before');
  DoDivisionByZero();
  ShowMessage('After');
end;

Der Cursor wird beim zweiten ShowMessage haengen bleiben, bzw.: er bleibt bei der ersten Anweisung nach dem Fehler haengen. Z.B.:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TForm1.DoDivisionByZero();
var
  Res: Integer;
begin
  Res := 5 / 0;
  ShowMessage('Don''t go any further'); //Hier bleibt der Cursor stehn
end;

procedure TForm1.DoSomething();
begin
  ShowMessage('Before');
  DoDivisionByZero();
  ShowMessage('After');
end;

Wenn die fehlerhafte Anweisung die letzte in einer Funktion ist, so bleibt der Cursor an der Zeile nach dem Aufruf stehn.

Greetz
alcaeus

Hallo,

ich habe gestern noch einige Zeit im Internet verbracht und bin nach langem Suchen auf die Lösung gekommen. Die Variable Default8087CW stand auf $133F, was die FPU-Fehlermedungen unterdrückt. nach dem Aufruf von

Set8087CW($1332);

funktioniert wieder alles so wie es soll. Ich habe auch nachgeschaut, wo das gesetzt wird. Und zwar habe ich einen OpenGLHeader eingebunden, in diesem wird diese FPU-Fehlerüberprüfung ausgeschaltet
(Sie soll wohl zu ungenau für gewisse 3D-Berechnungen sein).

BomberBB

p.s.: Danke für die Antworten!!!

das ist richtig, auf diese Stelle sind wir damals auch gekommen. Wir hatten auch erst die entsprechende Funktion in unsere Software eingebaut. Nur ist diese FPU-Variable von Prozessor zu Prozessor verschieden gesetzt und am System herumreparieren war uns dann zu ...

Deswegen fährt man mit obiger Variante besser (unabhängiger).

Zitat von Bomberbb:

ich habe folgendes Problem: Wenn ich mein recht großes Programm debugge, kommt es ab und zu vor, dass eine Gleitkommadivision durch 0 nicht sofort vom Debugger gemeldet wird (auch Getlasterror ist 0). Das ist erst der Fall bei dem nächsten mal, dass ich trunc aufrufe. Ich kann den eigendlichen Fehler also nur finden indem ich zeilenweise trunc einsetze...

Hast Du evtl. einen HP-Drucker-Treiber installiert oder machst Du etwas mit DirectX?
In beiden Fällen kann es AFAIK vorkommen das das Exception-Handling vom BS aus Performance-Gründen/Programmier-Fehlern teilweise ausgehebelt/abgeschaltet wurde. (Siehe Thread im Entwickler-Forum

Hallo Bernhard,

wie gesagt, ich habe den Fehler bereits lokalisiert. Im Initialisierungsteil des von mir benutzten OpenGlHeaders steht die Zeile

Set8087CW($133F);

Und fiese schaltet die Fehlerbearbeitung in der FPU aus. Nach setzen von

Set8087CW($1332);

läuft alles wieder normal...

...aber dovan ab, hör auf mit HP-Treibern... , da kann ich ein Lied von singen...