Ungültige Gleitkommaoperation nur bei bestimmten PC's

[HCB]

Hallo, 5 User nutzen mein Programm.
Bei einer Suchfunktion mit z.B. Werten die nicht gefunden werden können, da nicht vorhanden, kommt bei 2 PC's die korrekte Messagebox dass der Suchbegriff nicht gefunden wurde.
Die anderen 3 PC's zeigen statt die MessageBox die Fehlermeldung "Ungültige Gleitkommaoperation", die MessageBox wird aber nicht gezeigt.
Ich muss dazu sagen, das mit dummy:= StrToInt(eingabetext) geprüft wird, ob Nummern eingegeben werden, dementsprechend wird die except Routine ausgeführt.

Kennt Ihr so ein Verhalten, dass mit den selben Programm das Ergebnis auf verschiedenen Rechnern anders aussieht?

Über Tipps würde ich mich freuen.

LG Harry

[jaenicke]

Ein Thema könnte das FPU control word sein, mit dem Einfluss auf Gleitkommaberechnungen genommen werden kann.
https://docwiki.embarcadero.com/RADS...ntrol_Routines

Die Frage ist aber eher, wo das konkrete Problem liegt. Deine Prüfung mit StrToInt kann da kaum eine Rolle spielen, denn es geht ja um eine Gleitkommaoperation. Welche Zeile wirft denn den Fehler?

Ein beliebter Fehler ist z.B., einen Wert auf "= 0" zu prüfen, statt IsZero zu verwenden.

[HCB]

Ich habe schon gedacht dass es am jeweiligen Bertriebssystemstand liegt. Fällt aber auch aus, da der eine PC- Stand 22H2 19045.3693 hat und es ohne Fehlermeldung läuft, während der andere PC mit dem selben Betriebssystemstand die Fehlermeldung bringt.
Ich vermute, dass irgend etwas an der Rechnerkonfiguration sich unterscheidet. Nur was????

LG Harry

[haentschman]

Zitat:

Welche Zeile wirft denn den Fehler?

:wink: Code?

[LoZe]

ich hatte mal ein ähnliches Problem bei mir waren die jeweiligen Rechner im Windows nicht auf Region Deutschland eingestellt Sondern Englisch, Chinesisch oder Slowakisch.

[Sinspin]

Zitat:

Zitat von LoZe (Beitrag 1530969)

ich hatte mal ein ähnliches Problem bei mir waren die jeweiligen Rechner im Windows nicht auf Region Deutschland eingestellt Sondern Englisch, Chinesisch oder Slowakisch.

Dem gebe ich auch 100 Punkte.
Länder Einstellungen, Format Einstellungen. Habe ich regelmäßig Probleme mit.

Ich würde generell mit StrToIntDef arbeiten da hier keine Exceptions kommen, sondern der angegebene Defaultwert wenn etwas schief geht.

[DeddyH]

StrToInt hat aber doch mit Gleitkomma nichts zu tun, ansonsten würde ich eher mit einem EConvertError rechnen, wenn man Stringumwandlungen versucht.

[HCB]

Die Variable dummy ist vom Typ cardinal, ich werde es mal auf Integer oder LongInt umstellen und sehen was dann passiert.
Fragt sich nur warum es bei 2 Rechnern ohne Fehlermeldung läuft.???

[himitsu]

Ihhh, eine Exception zur Flusssteuerung.

OK, wenn sowieso abgebrochen werden soll und der der Benutzer die Meldung sehen soll, dann ja,

aber sonst TryStrToInt oder StrToIntDef, jenachdem wie die Fehleingabe behandelt werden soll.


Aber ein Fließkommafehler bei einer Ganzzahloperation? :gruebel:

[Delphi.Narium]

Wenn statt einer MessageBox, außerhalb der Fehlerbehandlungsroutine zur Flusssteuerung, eine andere Fehlermeldung kommt, liegt die Vermutung nahe, dass die andere Fehlermeldung nicht von dort kommt, wo du es vermutest oder gerne hättest, sondern von einer anderen Stelle.
Oder die Fehlerbehandlung selbst enthält einen Fehler, so dass dort nicht die gewünschte Fehlerbehandlung erfolgt, sondern ein Folgefehler sichtbar wird.

haentschman bat um Code. Wie wäre es damit? Dann hätten wir sogar 'ne Chance die Fehlerstelle mal anzuschauen, den Fehler nachzuvollziehen, für Abhilfe zu sorgen, statt einfach nur in Mutmaßungen zu stochern.

Zitat:

Zitat von himitsu

Aber ein Fließkommafehler bei einer Ganzzahloperation?

Wie kommst Du dadrauf? ;-) ;-) ;-)

StrToInt(eingabetext) suggeriert zwar, dass hier die Eingabe zu 'nem Integer werden soll, aber ob die Eingabe ein Integer ist, wissen wir nicht.

Ist Eingabetext auf manchen Systemen ein Integer mit Tausenderpunkt, der auf anderen Systemen zu 'nem Dezimaltrenner mutiert? Oder ist die Eingabe zwar für StrToInt ein "richtiger" Integer, für die weitere Routine aber nicht?

Und was kommt hier auf welchem Weg nach Eingabetext? TEdit, TMemo, TMaskEdit, InputQuery, InputBox, ...

Und wo sucht die Suchfunktion? In 'ner Ini, im Arbeitsspeicher, 'ner StringList, 'ner Datenbank? Passen da die Ländereinstellungen überall zusammen?

Delphi mit Tausenderpunkt, Datenbank mit Tausenderkomma? Integer mit Tausenderpunkt ist Integer. Mit Tausenderkomma aber eventuell bei der DB dann nicht mehr. Oder was weiß wer da sonst noch so alles schiefgehen könnte, ...

[HCB]

Hier der Code-Ausschnitt:

Delphi-Quellcode:

           try
            dummy:=StrToInt(edt_SearchEdit.Text); //prüfen ob artikelnummer eingegeben wurde, sonst except ausführen
            Q_sArtikel.close;
            Q_sArtikel.SQL.Text:='select * from Artikel where ArtNr like '+ QuotedStr(edt_SearchEdit.Text+'%')                   
            Q_sArtikel.open;                
           except on E: EConvertError do   ShowMessage('Keine gültige Artikelnummer';
           end;

LG Harry

[Bernhard Geyer]

HP Treiber installiert?
(gab es jedenfalls mal vor Jahren, das diese "ein paar Einstellungen" für alle Programme beeinflusst haben.

[himitsu]

Zitat:

Zitat von Delphi.Narium (Beitrag 1530976)

StrToInt(eingabetext) suggeriert zwar, dass hier die Eingabe zu 'nem Integer werden soll, aber ob die Eingabe ein Integer ist, wissen wir nicht.

Es ist egal, was übergeben wird, es kann auch garnichts, oder der Name "Hans Peter" sein.
Es wird als Ganzzahl interpreziert und demnach auch so behantelt.
Sollte es nicht passen, dann kommt ein anderer Fehler, aber eben nichts bezüglicgh Fließkomma.

Und ja, natürlich kann (oder wird vermutlich auch) der Fehler von wo Anders her kommen.

[Klaus01]

.. du kannst Dein Edit auch so einstellen, dass es nur Zahlen/Ziffern akzeptiert.

Grüße
Klaus

[HCB]

Im Suchfeld sollen Artikelnummern und Produktbezeichnungen eingegeben werden können, wobei wenn Artikelnummern eingegeben werden eine andere SQL abfrage gestartet wird.
Ich habe das ganze jetzt mal auf "tryStrToInt" umgestellt und statt der var cardinal Integer zugewiesen. Mal sehen obs dann richtig läuft.
Gebe auf jedenfall morgen bescheid. Drückt mir die Daumen.

LG Harry

[himitsu]

bis 9 bzw. 10 Dezimalstellen
TryStrToInt
TryStrToUInt

bis 19 bzw. 20 Dezimalstellen
TryStrToInt64
TryStrToUInt64

[Benmik]

Ich würde auch nochmal den Hinweis von LoZe abprüfen. Und zwar habe ich auf einem Rechner ein chinesisches Programm, das ein Gerät ausliest, das nur dann korrekte Zahlen liefert, wenn man das Zeichen für den Dezimaltrennpunkt auf Komma umstellt. Hat was mit einer Fotovoltaikanlage zu tun. Hab ich gemacht, natürlich vergessen zurückzustellen und ein paar Tage später beinahe 120.000 € überwiesen. Die Ländereinstellung ist weiterhin auf "Deutschland" und es ist nichts verändert, außer dem Dezimalzeichen. Den Betrag hatte ich kopiert und eingefügt, so kann zwanglos eine Gleitkommazahl in eine Textbox kommen.

[jaenicke]

Bist du sicher, dass die Exception an der Stelle auftritt? Wie lautet diese ganz genau?

Dass diese dort nicht abgefangen wird, liegt daran, dass du nur EConvertError abfängst, alle anderen Exceptions aber nicht. Du solltest besser TryStrToInt verwenden und nur Exceptions in den Zeilen mit der SQL-Abfrage behandeln, dort dann aber alle.

[haentschman]

Hallöle...8-)
[OT]

Delphi-Quellcode:

try
  dummy := StrToInt(edt_SearchEdit.Text); //prüfen ob artikelnummer eingegeben wurde, sonst except ausführen
  Q_sArtikel.Close;
  Q_sArtikel.SQL.Text := 'select * from Artikel where ArtNr like '+ QuotedStr(edt_SearchEdit.Text+'%')
  Q_sArtikel.Open;
except 
  on E: EConvertError do ShowMessage('Keine gültige Artikelnummer';
end;

Delphi-Quellcode:

'select * from Artikel where ArtNr like '+ QuotedStr(edt_SearchEdit.Text+'%')

bietet SQL Injection einen perfekten Spielplatz. :kotz: https://de.wikipedia.org/wiki/SQL-Injection
Immer mit Parametern arbeiten. :warn:

Delphi-Quellcode:

try
  dummy := StrToInt(edt_SearchEdit.Text); //prüfen ob artikelnummer eingegeben wurde, sonst except ausführen
  Q_sArtikel.Close;
  Q_sArtikel.SQL.Text := 'select * from Artikel where ArtNr like :ANN';
  Q_sArtikel.ParamByName('ANN').AsString :=  QuotedStr(edt_SearchEdit.Text+'%');
  Q_sArtikel.Open;
except 
  on E: EConvertError do ShowMessage('Keine gültige Artikelnummer';
end;

[/OT]

:wink:

[DeddyH]

Entweder SQL-Parameter(dringend empfohlen) oder QuotedStr, beides zusammen ist doppelt gemoppelt.

[haentschman]

Zitat:

QuotedStr

...CopyPaste. :duck:

Delphi-Quellcode:

Q_sArtikel.ParamByName('ANN').AsString := edt_SearchEdit.Text + '%';

[Phoenix]

Okay, die SQL-Injection haben wir jetzt gelöst. Die Exception noch nicht.

Die Exception "Ungültige Gleitkommaoperation" bei der Eingabe von Nummern riecht für mich auch Extrem nach einer Locale-Thematik.
Also wirklich checken:
- Welche Region ist auf den jeweiligen PCs eingestellt?
- Welche Sprache nutzen die jeweiligen Rechner?
- Welches "Regional Format" ist eingestellt?

Mir ist mal eine Fremdprogrammierte Java-Vereinsmanagementsoftware jedes mal bei einer Zifferneingabe abgeschmiert, weil mein System English (US) war und mein Regional Format German (Date/Time, Tausender- und Nachkomma-Trennzeichen), und der Entwickler dort halt nur auf reinen German-Systemen gearbeitet hat und der übliche Vereins-Verwaltungs-Typ maximal auch ne Deutsche Windows-Kiste hatte und das da nie vorgekommen ist.

[HCB]

So jetzt das Ergebnis :(
Region, Sprache etc. alles ok, bei allen Rechnern gleich.
Nochmals zur Klarstellung:
Der Fehler wird nur auf manchen Rechnern geworfen wenn man Z.B. unsinniges wie "hehfehehefgh" eingibt (nicht Zahlen!) das natürlich nicht gefunden werden kann!
Das ist kurios warum die Exception "Ungültige Gleitkommaoperation" angezeigt wird.
Die Änderungen auf TryStrToInt hat auch nichts gebracht. Gleiche Fehlrmeldung!!

Vielleicht sollte ich mal Änderungen bei Region vornehmen, speichern und wieder auf "Deutschland" einstellen. Manchmal verhält sich Windows "merkwürdig".

LG Harry

[Uwe Raabe]

Ist offenbar noch nicht nach gefragt worden: Sind Threads im Spiel?

[Jasocul]

Zitat:

Zitat von HCB (Beitrag 1531006)

Das ist kurios warum die Exception "Ungültige Gleitkommaoperation" angezeigt wird.
Die Änderungen auf TryStrToInt hat auch nichts gebracht. Gleiche Fehlrmeldung!!

Bist du dir sicher, dass du den Fehler an der richtigen Stelle suchst?
Mit TryStrToInt sollte keine Exception mehr ausgelöst werden und der SQL-Abfrage ist es egal, was in dem String steht. Abgesehen davon würde bei einem SQL-Fehler eine andere Exception ausgelöst werden.

[Delphi.Narium]

Zitat:

Zitat von himitsu (Beitrag 1530982)

Zitat:

Zitat von Delphi.Narium (Beitrag 1530976)

StrToInt(eingabetext) suggeriert zwar, dass hier die Eingabe zu 'nem Integer werden soll, aber ob die Eingabe ein Integer ist, wissen wir nicht.

Es ist egal, was übergeben wird, es kann auch garnichts, oder der Name "Hans Peter" sein.
Es wird als Ganzzahl interpreziert und demnach auch so behantelt.
Sollte es nicht passen, dann kommt ein anderer Fehler, aber eben nichts bezüglicgh Fließkomma.

Und ja, natürlich kann (oder wird vermutlich auch) der Fehler von wo Anders her kommen.

Das ändert nichts daran, dass wir nicht wissen (wussten), welche konkrete Eingabe zum konkreten Fehler führt(e).

Es ist klar, das dummy nach dem StrToInt 'nen Integer enthält oder eine Ausnahme ausgelöst wird. Enthält dummy einen Integer, wird eine Abfrage mit dem Inhalt von Eingabetext erstellt. Von welchem Type die Artikelnummer in der Datenbank ist, wissen wir nicht, durch die Nutzung von Like könnte hier aber (datenbankseitig) eine implizite Typumwandlung erfolgen, die aber höchstwahrscheinlich nicht zum genannten Fehler führen wird.

Zitat:

Zitat von HCB

Im Suchfeld sollen Artikelnummern und Produktbezeichnungen eingegeben werden können, wobei wenn Artikelnummern eingegeben werden eine andere SQL abfrage gestartet wird.
Ich habe das ganze jetzt mal auf "tryStrToInt" umgestellt und statt der var cardinal Integer zugewiesen. Mal sehen obs dann richtig läuft.
Gebe auf jedenfall morgen bescheid. Drückt mir die Daumen.

Die gezeigte Quelltext lässt vermuten, dass es sich hier um eine andere SQL abfrage, der Abfrage nach Artikelnummer, also um die andere Abfrage, handelt.

Der Fehler tritt aber auf, wenn man unsinniges wie "hehfehehefgh" eingibt. Also bei der Abfrage, deren Verarbeitung wir im Quelltext nicht sehen können.

Wir wissen, dass mit einer Datenbank gearbeitet wird, wir wissen aber nicht welcher. Stimmen die Ländereinstellungen, ... der Datenbanken auch alle überein?

Der genannte Fehler könnte z. B. eventuell auch auftreten, wenn Client und Datenbank Komma und Tausenderpunkte unterschiedlich interpretieren. Dann könnte er beim Open der Abfrage auftreten, wenn der Client einen Integer erwartet, aber 'nen Gleitkommawert erhält oder andersherum oder irgendsowas, was leicht bis mittelstarkt durcheinandergeraten ist. Fehlerverursacher muss jedenfalls nicht zwingend die Artikelnummer sein, sondern könnte auch aus einem (wie auch immer gearteten) Konvertierfehler einer der anderen im select * from enthaltenen Spalten resultieren.

Zitat:

Zitat von Jasocul

Bist du dir sicher, dass du den Fehler an der richtigen Stelle suchst?

Ich bin mir (fast) sicher, dass der Fehler an der falschen Stelle gesucht wird.

[HCB]

Das blöde daran ist, dass ich auf dem Entwicklungsrechner nichts feststellen kann, da das ja auf diesem funktioniert. Ich muss erst die exe auf die anderen Rechner übertragen um festzustellen, dass es dort bei einem läuft, bei anderen aber nicht.
Ich setze mal im Code einige ShowMessages ein um genau zu sehen bei welchen Codeabschnitt die Exception bei den betroffenen Rechnern auftritt.

LG Harry

[rabatscher]

my 2 cents:
wir hatten grad ein Problem mit dem FPU Control Word :
Beim laden der fbClient.dll kam es zu einem netten Nebeneffekt, der das FPU control word so gesetzt hat,
dass die FPU Exceptions maskiert wurde - das lag jetzt mal nicht in erster Linie an Firebird (die hatten
genau diesen Fehler ausgemerzt) aber an 3rd Party dll's, die auf manchen Systemen dazugeladen wurde.
-> Bei uns hatte das genau eine FPU exception maskiert und auf anderen Rechnern Exceptions verursacht.

-> mal checken (da ich ja evt. nicht ganz falsch liege, dass du Datenbanken benutzt).

Manche FPU exceptions werden nur bei einem "Wait" asm call geworfen also hast du evt. ein
paar Assemblersequenzen, die das nicht aufrufen?

Und dann wär noch die Routine Move... sie benutzt in win32 die FPU Register um Daten zu kopieren. Wenn jetzt vorher schon
mal eine FP Exception da war könnte das da hochkommen. Und... Move wird intern wirklich oft verwendent.

[BerndS]

Wenn du da nicht weiter kommst könnte MadExcept oder ähnliche Tools eine große Hilfe sein.

[Sherlock]

Und der Remotedebugger hilft auch immer wieder.

[Phoenix]

Zitat:

Zitat von HCB (Beitrag 1531019)

Ich setze mal im Code einige ShowMessages ein um genau zu sehen bei welchen Codeabschnitt die Exception bei den betroffenen Rechnern auftritt.

🙈 Hast Du kein richtiges Logging?
Billigste Variante:
Bei Unhandled Exceptions schön den Stacktrace rausloggen.

Ansonsten im Trace-Mode einfach bei jeder Method den Ein- und den Ausgang loggen.
Dann siehst Du sinnvoll auch im Log wo der Fehler geworfen wird und welche Methoden da drüber aufgerufen wurden.

[himitsu]

Zitat:

Zitat von Phoenix (Beitrag 1531033)

🙈 Hast Du kein richtiges Logging?

siehe GetIt : CodeSite, QuickLogger, ...


oder miniamal
*

Delphi-Quellcode:

TFile.AppendAllText('C:\irgendwo\Datei.log', 'peng'#10);

*

Delphi-Quellcode:

OutputDebugString(PChar('peng'));

ins Logfenster des Delphi
*

Delphi-Quellcode:

var LogFile := TFile.AppendText('C:\irgendwo\Datei.log');

LogFile.WriteLine('peng');
LogFile.WriteLine('peng');

//LogFile := nil; {kann, aber muß nicht, weil wird eh automatisch}

JAAAAA, oder die uralte TEXT-FileAPI (AssignFile), TStringStream, usw.

[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! :evil:
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.

[QuickAndDirty]

Logge alle inputs beim Kunden.
Wenn du weist bei welche inputs der Fehler passiert, hole dir die Kundendatenbank und alle Einstelldateien auf deinen Rechner.
Stelle den input der zu dem problem führt nach.