Division durch 0 -> NAN

[Gruber_Hans_12345]

Hallo, habe ein blödes problem,
Auf meinem Entwicklungssystem, bekomme ich nun statt einer Exception wenn ich durch 0 dividiere die "Zahl" NaN raus, meine Kunden, jedesmal eine Exception, nun ist es zum Fehlersuchen sehr mühselig, das zu finden.

ich habe schon probiert, ein

Delphi-Quellcode:

    SetExceptionMask(GetExceptionMask + [exZeroDivide]);

zu machen, aber das bringt erstens nix, und zweitens war es schon gesetzt, wenn ich mir den wert mit GetExecptionMask anschaue ...

Was kann das noch sein, hat da wer eine Idee?

[Forlan]

Hi,
Könnte es evtl. sein, dass das Problem betriebssystemabhängig ist?
Siehe hier

Gruß,

[Gruber_Hans_12345]

möglich, habe diese seite auch schon gesehen

Allerdings die letzten Jahre über bekam ich auf dem selben system immer diese Exception und nun siet ca. 1-2 wochen nicht mehr ....

[himitsu]

Man könnte natürlich auch so programmieren, daß soeine Berechnung erst garnicht durchgeführt und über die Eingabewerte schon frühzeitig abgefangen wird. :angel2:

[Forlan]

Welches Betriebssystem wird denn genutzt?
Wurden evtl. Updates geladen?
Eine andere Möglichkeit als ein Windowsupdate fällt mir dann auch im Moment nicht ein...

Wäre ja nicht das erste Mal das ein Windowsupdate komische Dinge tut... :mrgreen:

[Namenloser]

Probier es mal mit Set8087CW.

[Forlan]

Zitat:

Zitat von NamenLozer

Probier es mal mit Set8087CW.

...Obwohl es denke ich sinnvoller wäre Himitsus Vorschlag in die Tat umzusetzen. ;)

[Bernhard Geyer]

Zitat:

Zitat von Gruber_Hans_12345

Allerdings die letzten Jahre über bekam ich auf dem selben system immer diese Exception und nun siet ca. 1-2 wochen nicht mehr ....

Hast du einen neuen Drucker oder Druckertreiber installiert? HP-Treiber sind bekannt dafür den Defaultwert für das Exception-Handling der Fließkommaeinheit der CPU zu verändern.

[Gruber_Hans_12345]

ist ein win2000 Rechner

und ja, ich will diese sachen ja vermeiden, aber es ist halt um einiges leichter, wenn der compiler in der entwicklungsumgebnung dann mit der exception dort stehen bleibt, wo es auftritt, und nicht einfach weitergeht mit dem wert NaN.

Es ist nun einfach schwierig diese Bugs aufzuspüren ...

also, das brachte auch nix

Delphi-Quellcode:

    System.Set8087CW(Default8087CW);

[bassman]

Hallo Hans,

habe folgendes:

I think I gave you the wrong code. A clear bit allows the exception, a
set bit masks it. Try the following instead:

SetExceptionMask(GetExceptionMask - [exZeroDivide]);

Now it should give you a divide by zero error. What did Format('$%.4X',
[Get8087CW]) result in, in your case?

hier gefunden: https://forums.codegear.com/thread.j...ssageID=163649

Hoffe dies hilft dir weiter.

Gruss, Jörn

[Gruber_Hans_12345]

hmmmmmmm

also, wenn ich

Delphi-Quellcode:

SetExceptionMask(GetExceptionMask - [exZeroDivide]);

direkt VOR meiner division stelle, dann passt es
aber schon beim nächsten aufruf ist es schon wieder umgestellt.

Wie finde ich nun heraus welches programm oder sonstige mir das ständig umstellt?

[himitsu]

Wird diese Maske nicht eigentlich nur für jeden Prozess/Thread privat gesetzt?
Wenn, dann dürften doch Femdprogramme daran nichts ändern können. (ok, abgesehn von irgendwelchen Hooks, eingeschmuggelten DLLs usw.)

Such doch mal in deinem Projekt, ob irgendwo etwas derartiges gesetzt wird?

Strg+Shift+F
Suchwort= "(SetExceptionMask|Set8087CW|FLDCW)"
RegEx aktiviert
im Projektverzeichnis

Eventuell auch mal einen Haltepunkt auf die beiden Prozeduren SetExceptionMask und Set8087CW, mit Debug-DCUs,
wobei natürlich direkte ASM-Aufrufe so nicht entdeckt werden.


Du könntest auch "exZeroDivide in GetExceptionMask" in die überwachten Variablen aufnehmen und wärend des Debuggens immer mal einen Blick drauf werfen.

[Gruber_Hans_12345]

hmmmm, das komische ist, das die fertige compilierte exe auf dem anderen rechner ja diese div/0 exceptions aufruft ... bzw timmt nicht ganz, es sind nun ja "unghültige gleitkommaoperation" exceptions ....
werde am monetag das ganze noch ein mal testen, auch den rechner mal neu starten, bzw BDS mal neu starten ...

[rollstuhlfahrer]

a) mal alle kompilierten Dateien löschen und b) mach das doch mal in einem leeren Projekt. Dann zeigt sich, ob es am Rechner hängt, oder an dem Programm direkt.

Bernhard

[Gruber_Hans_12345]

soooooo ....

habe mal einiges ausprobiert
Neues Projekt -> da macht ers anscheinend nicht.

Im aktuellen projekt, habe ich mal Breakpoints auf die Funktion gesetzt (Set8087CW)
und mir die werte angeschaut
ich alsse mir die 3 werte ausgeben beim breakpoint (Get8087CW, NewCW, Default8087CW)
wenn ich den Wert $137B setze, dann ist

Delphi-Quellcode:

NewCB = $137B
Default8087CW = $137F
Get8087CW = $137F

kurz danach ist es immer noch so
aber dann so eine sekunde später
ist es dann

Delphi-Quellcode:

NewCB = $137F
Default8087CW = $1378
Get8087CW = $137F

dass heisst für mich, das der Wert ausserhalb von Delphi geändert worden is, bzw per ASM, da es nur so geht, das der Default8087CW nichts davon mitbekommt ...

wie finde ich das nun raus?

[rollstuhlfahrer]

Zitat:

Zitat von Gruber_Hans_12345

habe mal einiges ausprobiert
Neues Projekt -> da macht ers anscheinend nicht.
[...]
dass heisst für mich, das der Wert ausserhalb von Delphi geändert worden is, bzw per ASM, da es nur so geht, das der Default8087CW nichts davon mitbekommt ...

So, am Rechner liegts also nicht. Auch nicht an bestimmten Treibern o.ä. denn sonst müsste der Fehler ja reproduzierbar sein. Meiner Meinung nach müsste irgendwas in dem Programm dafür sorgen, dass

Zitat:

Zitat von Gruber_Hans_12345

wie finde ich das nun raus?

Hast du in deinem Programm irgendwelchen hochtrabenden Grafik-Schnickschnack? - Embarcadero schlägt nämlich vor, die FPU-Exceptions bei der Verwendung von OpenGL zu deaktivieren. Ansonsten könnte das auch irgendeine Komponente verursachen. Was allerdings fraglich ist, ist weiterhin, warum der Wert immer wieder auf seinen alten Wert zurückgesetzt wird.

Bernhard

[himitsu]

Ob es am Programm oder am System liegt, kann man ja relativ leicht rausfinden.
> auf anderen PCs, mit anderer Hardware und eventuell anderem OS mal ausprobieren

[rollstuhlfahrer]

Ich finde, es ist schon bestätigt, dass es am Programm liegt. Einerseits kommt ja bei anderen eine Exception (siehe #1) und hier kommt mit einem anderen Programm auch eine Exception. Dies lässt also nur noch den Schluss zu, dass es am Programm liegen muss. Oder besser gesagt an der Programm-Rechner-Kombination. Oder ist das nur eine neue Version, die spinnt?

Bernhard

[himitsu]

Zitat:

Ich finde, es ist schon bestätigt, dass es am Programm liegt.

Bestätigt ist nichts.

Es kann ja sein, daß hier im Programm was verwendet wird, wodurch etwas externes so reagiert.

z.B. könnte ein DLL verwendet werden, welche wiederrum was anderes läd/auslöst, welches "nur" auf diesem PC etwas "anders" reagiert.

[Gruber_Hans_12345]

Also, Entwicklungsrechner neu starten brachte keine Besserung.

Jetzt habe ich das Phänomen auch auf meinem zweiten Rechner (Kann auch sein, das der es vorher auch schon hatte und nicht auffiel)

Ich habe in die Titelleiste eingebaut, das er mir immer den Status des CW anzeigt, per Timer - alle 100ms
und einen Button mit dem ich das CW rücksetzen kann.

Dann sieht man schön, rückgesetzt auf den richtigen Wert. Dann zwischen ein paar ms und 2 sekunden, steht wieder der falsche Wert im CW drinnen ...