Ungültige Gleitkommaoperation nur bei bestimmten PC's

[HCB]

Vielen herzlichen Dank für euere Mithilfe. Ich habe bemerkt dass ich zur Geschindigkeitsmessung am Ende der Routine
> lbl_performance.Caption:= IntToStr(GetTickCount - startTime) + 'ms'; <
eingefügt habe. Die Variable starttime habe ich als Integer deklariert, sehe aber in der Delphi Hilfe dass es wohl von Typ cardinal sein soll.
Vielleicht liegt es daran. Was aber immer noch nicht klärt, warum es auf manche Rechnern funktioniert.

FPU??
Alle Rechner haben den gleichen Prozessor i5 4690 außer der Entwicklungsrechner hat i5 7xxx.

Ich werde morgen das ohne GetTickCount probieren und wieder berichten.

LG Harry

[himitsu]

Ja, Cardinal, schon immer,
aber nach 49,7 Tagen kann es dennoch knallen, wenn es zum Überlauf kommt, da Delphi ja neuerdings standardmäßig die Bereichsprüfung aktiv hat.

TStopWatch TStopWatch

[HCB]

Guten Morgen,
die Messung GetTickCount hab ich jetzt komplett rausgeschmissen und siehe da: ES FUNKTIONIERT IMMER NOCH NICHT!
Weiß der Teufel was da schief läuft.
Es ist verflucht schwierig einen Fehler auf dem Rechner zu finden, auf dem das Programm ja läuft. Verflixt!

[dummzeuch]

Was ist denn jetzt mit der Theorie, dass das FPU Control Word von einer DLL geändert wird und es deshalb zu Problemen mit Fließkomma-Berechnungen kommt? Das ist meiner Ansicht nach die wahrscheinlichste Ursache.

Werden irgendwelche speziellen DLLs benutzt?

Häufig hilft es, sie explizit mit SaveLoadLibrary zu laden, was sich um dieses Problem kümmert, zumindest wenn es durch die Initialisierung der DLL auftritt.

[HCB]

Es werden keine zusätzlichen DLLs verwendet, das Programm läuft allein nur mit der exe und einer .ini File.

[Jasocul]

Ich verstehe nicht, warum du den Fehler an Stellen suchst, die die Fehlermeldung nicht verursachen können.
Deine ersten Vermutungen haben schon gezeigt, dass dort nur Convert-Fehler oder SQL-Fehler entstehen können. Beim GetTickCount hättest du nur einen Überlauf-Fehler bekommen können.
Du sucht an Stellen, wo mit Cardinal und Integer gearbeitet wird. Die Wahrscheinlichkeit, dass dort der Fehler ist, tendiert gegen 0.

Schau dir den Source an den Stellen an, wo mit Double, Extended o.ä. gearbeitet wird.

[Kas Ob.]

Hi,

Also I think you are looking for this in the wrong place, i suspect something different and has to do with memory allocation, like using broken FastMove, or something else.

I suggest to build the EXE with RTL debug dcu, only then you might get closer or finer look where the exception is raised, this exception is hardware one and should be easier to catch and locate as it is limited to illegal operation.

[jaenicke]

Zitat von HCB:

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).