"Invalid floating point operation" und clibs

[Mathias]

Mir ist schon vielfach aufgefallen, wen man clibs nutzt, das es zu einem "Invalid floating point operation" kommt.
Der Klassiker dabei ist die GTKx.

Die kann man folgendermassen umgehen, was sehr unschön ist, das es dafür die unit math braucht.

Code: Alles auswählen

uses
  Math, ...;
 begin
  SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide, exOverflow, exUnderflow, exPrecision]);
  ...

Gibt es dafür eine elegantere Lösung ?

[Zvoni]

Anscheinend nicht:
https://wiki.freepascal.org/Multiplatfo ... exceptions

After this forum topic and answers on this bug report it became clear that nothing can be done about this, so we must know what actually these differences are.

[af0815]

Mir ist schon vielfach aufgefallen, wen man clibs nutzt, das es zu einem "Invalid floating point operation" kommt.
Der Klassiker dabei ist die GTKx.
...
Gibt es dafür eine elegantere Lösung ?

Ja, aber nur wenn du kein GTK2 verwendest. Genaugenommen musst du die Exception Mask bedingt einbinden, da ja scheinbar nur GTK2 betroffen ist.

Zitat aus dem Bugreport

GTK2 cannot be run with exceptions enabled because the C code assumes that exceptions are turned off. Windows gui libs does not make this assumption so exceptions can be left turned on. There is not much which can be done about this: so either use another gui library or turn on/off exceptions as your code needs them while not calling gui related stuff.

Und so wie es aussieht ist es auch wegen der Nähe zu Mathe-Koprozessoren bzw. Erweiterungsbefehle für die CPU in der Math eingebunden und sehr CPU-Typen abhängig.

[Zvoni]

Wenn man jedoch in den Quellcode von Math schaut, stellt man fest dass die zwei Exception-Klassen, welche in den zwei Funktionen verwendet werden, nur eine vorwärts-Deklaration aus der "System" ist.
Müsste man ausprobieren, inwieweit man die drei Funktionen/Prozeduren (welche in mathu.inc sind) da vielleicht extrahieren kann, und in eine eigene Unit bauen könnte,
wobei ich das bezweifle (ausser ClearExceptions, was Assembler ist).
Bin mal spasseshalber durchgegangen, und nach zwei Zeilen war ich schon in der dritten inc-Datei (mathh.inc und math.inc)

[Mathias]

Ja, aber nur wenn du kein GTK2 verwendest. Genaugenommen musst du die Exception Mask bedingt einbinden, da ja scheinbar nur GTK2 betroffen ist.

Es betrifft nicht nur GLIB und GTK, es sind auch andere betroffen.
Auch mit libxml2 scheitert es.
In meinen Augen ist die ein gravierende Bug von FPC, sowas darf nicht sein.

Und so wie es aussieht ist es auch wegen der Nähe zu Mathe-Koprozessoren bzw. Erweiterungsbefehle für die CPU in der Math eingebunden und sehr CPU-Typen abhängig.

Diese Exception müsste doch in FPC standardmässig ausgeschalten sein.
Oder wenigsten mit irgendeinem {$blabla off} ausschaltbar sein.

[af0815]

Hast du dir schon mal überlegt, das du hier ein C Problem nur importierst. Der FPC braucht nicht alle Blödheiten ähhh Spezialitäten ausbügeln.
Es ist kein Bug, sondern eine Besonderheit von verschiedenen C-Libs. Daher musst du als Programmierer die Besonderheiten beachten. Eine C-Lib ist halt kein natives Pascal.

[PascalDragon]

Wenn man jedoch in den Quellcode von Math schaut, stellt man fest dass die zwei Exception-Klassen, welche in den zwei Funktionen verwendet werden, nur eine vorwärts-Deklaration aus der "System" ist.

Unter der Annahme, dass du TFPUExceptionMask meinst, das ist keine Klasse, sondern eine Enumeration, bzw. allgemeiner ein Typ. Bitte verwende die richtigen Begrifflichkeiten, sonst verwirrt das nur.

Ja, aber nur wenn du kein GTK2 verwendest. Genaugenommen musst du die Exception Mask bedingt einbinden, da ja scheinbar nur GTK2 betroffen ist.

Es betrifft nicht nur GLIB und GTK, es sind auch andere betroffen.
Auch mit libxml2 scheitert es.
In meinen Augen ist die ein gravierende Bug von FPC, sowas darf nicht sein.

Nein, das ist kein Bug. Object Pascal unterstützt nun mal Fließkommaausnahmen und wenn C-Code unter *nix zu blöd dazu ist damit umzugehen ist das nicht FPC's Problem.

Und so wie es aussieht ist es auch wegen der Nähe zu Mathe-Koprozessoren bzw. Erweiterungsbefehle für die CPU in der Math eingebunden und sehr CPU-Typen abhängig.

Diese Exception müsste doch in FPC standardmässig ausgeschalten sein.
Oder wenigsten mit irgendeinem {$blabla off} ausschaltbar sein.

Nein. Außerdem erlaubt SetExceptionMask eine per-Thread Kontrolle über Fließkommaausnahmen.

[Mathias]

Nein, das ist kein Bug. Object Pascal unterstützt nun mal Fließkommaausnahmen und wenn C-Code unter *nix zu blöd dazu ist damit umzugehen ist das nicht FPC's Problem.

Stell dir vor, du entwickelst mit FPC und SDL2 ein Profigames. Dies läuft alles hervorragend. Die Entwickler von SDL2 machen ein Update, bei der libxml2 eingebunden wird. Die Bindung ist aber immer noch voll kompatibel. Der User macht ein Update von seinem Linux, dabei wir die SDLlib geupdatet und will sein lieblings Games starten und dann kommt ""Invalid floating point operation" und da wird sich einer nerven.

Generell ist es nervig, wen Programme wegen so naiven unwichtigen Fehlern knallhart abbrechen.
Man stellt sich vor man schreibt eine Diplomarbeit und das Programm bricht ab, nur weil das Laden eines Icones ein "Invalid floating point operation" auslöst. Die ganze Arbeit ist futsch !

[m.fuchs]

Stell dir vor, du entwickelst mit FPC und SDL2 ein Profigames. Dies läuft alles hervorragend. Die Entwickler von SDL2 machen ein Update, bei der libxml2 eingebunden wird. Die Bindung ist aber immer noch voll kompatibel. Der User macht ein Update von seinem Linux, dabei wir die SDLlib geupdatet und will sein lieblings Games starten und dann kommt ""Invalid floating point operation" und da wird sich einer nerven.

Bei einem Profigame wirst du ja hoffentlich immer wieder testen - und im Zweifelsfall schnell auf einen Bug reagieren.

Generell ist es nervig, wen Programme wegen so naiven unwichtigen Fehlern knallhart abbrechen.

Generell ist es nervig, wenn Entwickler Code schreiben bei dem durch 0 dividiert wird und sie das Problem ignorieren, weil "man ja das Exception-Handling deaktivieren kann". Vermutlich ist es in C default-mäßig nicht aktiv - ich meine mal gelesen zu haben, dass in C eine Division durch 0 zu undefiniertem Verhalten führt.

Ich bin auch schon bei der Benutzung von externen Libs auf dieses Problem gestoßen. Ist nicht schön, aber kein Bug von FPC.

[Zvoni]

Wenn man jedoch in den Quellcode von Math schaut, stellt man fest dass die zwei Exception-Klassen, welche in den zwei Funktionen verwendet werden, nur eine vorwärts-Deklaration aus der "System" ist.

Unter der Annahme, dass du TFPUExceptionMask meinst, das ist keine Klasse, sondern eine Enumeration, bzw. allgemeiner ein Typ. Bitte verwende die richtigen Begrifflichkeiten, sonst verwirrt das nur.

Whuuppps! Recht hast.
Asche auf mein Haupt.

Ich hatte halt eben nur die Vorwärts-Deklaration gesehen, und nicht weiter nachgeschaut.

[Mathias]

Generell ist es nervig, wenn Entwickler Code schreiben bei dem durch 0 dividiert wird und sie das Problem ignorieren, weil "man ja das Exception-Handling deaktivieren kann". Vermutlich ist es in C default-mäßig nicht aktiv - ich meine mal gelesen zu haben, dass in C eine Division durch 0 zu undefiniertem Verhalten führt.

Genau da habe ich so ein Klassiker, da würde überhaupt nichts passieren, wen cnt 0 wäre. Und dadurch w undefiniert wäre.

Code: Alles auswählen

uses
  crt;

  procedure Print(y,cnt: integer);
  var
    w, i: integer;
  begin
    w := 80 div cnt;
    for i := 0 to cnt - 1 do begin
      GotoXY(w * i + 1, y);
      WriteLn('X');
    end;
  end;

begin
  Print(4, 10);
  Print(5, 5);
  Print(6, 4);
  Print(7, 0); // runtime error 200
end.

Generell ist es nervig, wenn Entwickler Code schreiben bei dem durch 0 dividiert wird und sie das Problem ignorieren, weil "man ja das Exception-Handling deaktivieren kann". Vermutlich ist es in C default-mäßig nicht aktiv - ich meine mal gelesen zu haben, dass in C eine Division durch 0 zu undefiniertem Verhalten führt.

Genau in C ist es deaktiviert, ansonsten würde GTK nicht ohne SetExceptionMask laufen.

Ich habe gerade noch etwas festgestellt, bei die xlmlib kommt eine ganz andere Fehlermeldung als bei meinem obigen Beispiel

Code: Alles auswählen

An unhandled exception occurred at $000070F9A6CF7D8B:
EInvalidOp: Invalid floating point operation

[Mathias]

Ich habe jetzt folgendes eingebaut.
So wie es scheint ist dies nur ein Problem mit Linux auf Intel CPU.
Bei Windows, kommt der Fehler nicht. Ausnahmsweise hat da mal Windows die Nase vorn.
Auf dem Raspi gibt es den Fehler auch nicht.
Mit libxml2 würde dies laufen, mal gucken, ob es bei GLIB und GTK auch geht.

Code: Alles auswählen

  {$IFDEF Linux}
  {$IF defined(CPUX86) or defined(CPUX64)}
  procedure SetMXCSR;
  var
    w2: word = 8064;
  begin
    asm
                 Ldmxcsr w2
    end;
  end;
  {$ENDIF}
  {$ENDIF}

begin
  {$IFDEF Linux}
  {$IF defined(CPUX86) or defined(CPUX64)}
    SetMXCSR;
  {$ENDIF}
  {$ENDIF}

[af0815]

...

[Mathias]

Bei Windows, kommt der Fehler nicht. Ausnahmsweise hat da mal Windows die Nase vorn.

Ich muss mich korrigieren, es passiert auch unter Windows, aber weniger häufig.
Nur der ARM blieb bis jetzt verschont.