Ungültige Gleitkommaoperation nur bei bestimmten PC's

[jaenicke]

Zitat:

Zitat von HCB (Beitrag 1531043)

Es ist verflucht schwierig einen Fehler auf dem Rechner zu finden, auf dem das Programm ja läuft. Verflixt!

Das ist in 80-90% der Fehler gar nicht schwierig, bei den anderen 10-20% ist dann deutlich arbeitsintensiver. So weit bist du aber noch gar nicht, was daran liegt, dass du kein sauberes globales Exceptionhandling, Logging oder irgendetwas in der Richtung hast. Denn sonst wüsstest du schon längst, wo der Fehler konkret passiert.

MadExcept wurde ja schon vorgeschlagen. Das musst du im Grunde nur einbinden, damit du einen guten Fehlerbericht mit Stacktrace bekommst. Alle anderen Logging-Maßnahmen sind für den aktuellen Zweck viel aufwendiger, wenn man sie nicht von Anfang an vorgesehen hat.

[himitsu]

Tipp: Probehalber auch mal vorübergehend die Codeoptimierung abschalten, wenn irgendwas knallt und man nicht weiß woher. (falls du als "Debug" kompilierst und es dort aktiviert wurde)

Wenn es zuverlässig dort auftritt, dann mal via RemoteDebugging nachsehn (falls nicht vorhanden, kann man auch z.B. via TeamViewer ein VPN verwenden, um sich mit seinem Delphi mit dem Programm zu verbinden),
oder eine bessere Fehlerauswertung einbauen (Eurekalog, MadExcept oder so).

[hannsg]

Hallo!

Ich möchte noch anmerken, dass StrToInt nicht nur Zahlen im Dezimalformat erkennt, sondern bspw. auch Hex-Zahlen, also z.B. $fe oder 0xff.

D.h. dann wird beim StrToInt() keine Exception ausgelöst... aber vielleicht später im Code?

Gruß, Meik

[TigerLilly]

Das allererste Ziel muss sein, die exakte Zeile zu finden, wo der Fehler auftritt. Dazu kannst du zB vor jede Zeile in der vermuteten Umgebung eine Logging Ausgabe (siehe andere Posts dazu) einbauen. Bzw beim Eintritt und Austritt aus Methoden, dann hast billig den Aufrufbaum.

Ich hatte das mit dem FPU Control Word auch mnal, da war es ein Druckertreiber, der das geändert, aber nicht zurückgesetzt hat. Je nachdem, ob wer was gedruckt hatte oder nicht, kam der Fehler (bzw in dem fall kam eben KEINE Exception, obwohl erwartet).

Zweites Ziel muss sein, zu klkären, ob du das verlässlich reproduzieren kannst. Anhand von daten bzw anhand von Abfolgen. Und zwar in allen Kombinationen - Fehler ja/nein vs Rechner A und B.

[QuickAndDirty]

Ich wette der Fehler kommt aus Firebird.
Firebird liefert z.b. "ungültige Gleitkomma Operation", wenn man Strings einfügt die Länger als das Feld sind.
Deswegen jede Zeile loggen damit man weiß wo der Fehler passiert.

[HCB]

Es ist ja bekannt in welcher Procedure der Fehler auftritt!
Es ist nur noch nicht nachvollziehbar, warum diese Produdure den Fehler NUR bei einigen PC's auslöst, bei anderen nicht!
MadExcept 5 habe ich mal installiert, bringt mich auf dem Entwicklungsrechner auch nicht weiter, da keine Exception dort ausgelöst wird.

[jaenicke]

Zitat:

Zitat von HCB (Beitrag 1531064)

MadExcept 5 habe ich mal installiert, bringt mich auf dem Entwicklungsrechner auch nicht weiter, da keine Exception dort ausgelöst wird.

Auf dem Entwicklungsrechner hast du ja Delphi, da brauchst du ja normalerweise keinen Fehlerbericht.

Gedacht ist das Tool dafür, dass du die damit kompilierte Exe auf dem PC ausführst, auf dem der Fehler auftritt.

[Sinspin]

Du musst die Exe die damit kompiliert wurde schon deinem Kunden geben.
Falls Du noch nie mit MadExcept gearbeitet hast, solltest du mal selber bei dir zum Testen eine Exception auslösen, um zu sehen wie der Dialog aussieht und was der Kunde machen muss damit Du an den Report kommst.
Mit dem Report wird dir schnell ein Licht aufgehen.

Und, sei bitte so lieb dem Erfinder von MadExcept deine Dankbarkeit zu zeigen, falls das noch nicht erfolgt ist.

[Jasocul]

Zitat:

Zitat von HCB (Beitrag 1531064)

Es ist ja bekannt in welcher Procedure der Fehler auftritt!

Ganz sicher, dass edt_SearchEdit nicht doch noch ein OnExit hat oder irgendwo aus anderen Gründen ein Event ausgelöst wird?
Du wärest bestimmt nicht der Erste, der sowas übersieht und verzweifelt an der falschen Stelle sucht.

[HCB]

Guten Morgen, liebe Leute

nun sieht es so aus, dass ich den Verursacher der Fehlermeldung gefunden habe:

Delphi-Quellcode:

frm_Main.edt_Marge.Text:= Format('%3f',[DataMod.Q_sArtikelmarge1.AsFloat/DataMod.Q_sArtikelArtEKQuer.AsFloat*100]);

Dies war im OnDataChange Ereignis im Datenmodul. Wenn der Datensatz gewechselt wurde sollte die Marge neu berechnet werden. Dieser Wechsel findet auch statt,
wenn ein Produkt gesucht wird - aber nichts gefunden wurde. Wie im beschriebenen Fall. Da wurde trotzdem versucht die Marge zu berechnen obwohl kein EKPreis vorhanden.
Das wäre nun dank Euerer intensiven Hilfe geklärt. Ich habe aber tatsächlich immer an der falschen Stelle gesucht. VIELEN HERZLICHEN DANK.:-D

Warum die Exception aber nur auf manchen Rechnern ausgelöst wurde, bleibt aber weiterhin ungeklärt :(

LG Harry

[jaenicke]

Da lag ich mit dem IsZero aus der ersten Antwort ja gar nicht so falsch, nur dass die Prüfung nicht falsch, sondern nicht vorhanden war.

Zitat:

Zitat von HCB (Beitrag 1531091)

Warum die Exception aber nur auf manchen Rechnern ausgelöst wurde, bleibt aber weiterhin ungeklärt :(

Das kann durchaus am FPU control word liegen.

[HCB]

> Das kann durchaus am FPU control word liegen. <

Was bedeutet das??
Liegt es an der Hardware oder Windows Einstellungen auf den Rechnern wo es nicht läuft bzw. dass es der Fehler nicht auftritt?

[freimatz]

https://docwiki.embarcadero.com/Libr...stem.Set8087CW
das Ding ist recht global. Und wenn jemand anders das anders setzt als man es haben will ...

[Jasocul]

Zitat:

Zitat von HCB (Beitrag 1531091)

Delphi-Quellcode:

frm_Main.edt_Marge.Text:= Format('%3f',[DataMod.Q_sArtikelmarge1.AsFloat/DataMod.Q_sArtikelArtEKQuer.AsFloat*100]);

Vielleicht solltest du vor der Division eine Prüfung auf IsZero machen.
Ich stecke gerade nicht so tief drin, was AsFloat bei einer leeren Datenmenge macht, aber man muss dort zumindest mit einer Division durch "0" rechnen. Ungültige Gleitkommaoperationen kann ich mir dabei durchaus auch vorstellen. Mit der FPU muss das nicht zwingend etwas zu tun haben.

[HCB]

Also wenn ich das mit FPU {delphi] System.Set8087CW($133f);[/delphi] einsetze, dann wird auch auf den besagten Rechnern keine Exception ausgelöst.
Das Programm läuft dann auf allen PC's ohne Fehlermeldung. Es sollte ja richtigerweise aber auf ALLEN eine Exception ausgelöst werden.

Wieder bleibt das Problem: Warum laufen drei Rechner ohne die Exception und zwei mit??

[Blup]

Wenn kein Datensatz vorhanden ist oder die Query auf EOF steht, sind die Felder NULL.
AsFloat macht daraus 0.
Division durch 0 ist eine ungültige Gleitkommaoperation.

Warum der Fehler nicht auf dem Entwicklungsrechner auftritt kann alle möglichen Ursachen haben.
Versuch einfach den Fehler bewust in Q_sArtikelArtEKQuer hervorzurufen (Last; Next; -> EOF).

[Sinspin]

Zitat:

Zitat von HCB (Beitrag 1531098)

Das Programm läuft dann auf allen PC's ohne Fehlermeldung. Es sollte ja richtigerweise aber auf ALLEN eine Exception ausgelöst werden.

Ein keiner Koogel hätte sicher schneller Egebnisse gebracht als hier drauf zu warten ;-)

Set8087CW / Reset8087CW Sample