Hallo zusammen,

sehr strange. Bei einigen unserer Kunden tritt auf einmal in einem Programm beim starten ein ERangeError ( Fehler bei Bereichsprüfung ) auf.
Allerdings ist der Stand der Kunden teilweise Monate alt.
Vor allem melden sich immer mehr damit. Im Release Compile ist die Option in den Compileroptionen deaktiviert und war auch immer deaktiviert.
Noch kurioser. Das ist aktuell nur in einem Programm und ein Neustart von Windows löst das Problem temporär.

Windows Update? Noch jemand der aktuell damit zu tun hat?

Gruß

Das könnte ein Speicherproblem sein (Buffer Overflow,...). So etwas kann durch jegliche Änderung quasi zufällig auftreten, wobei da je nach Code auch schon das Datum ausreichen kann. Auch ein Windows Update kann das natürlich auslösen, weil auch dadurch die Positionen im Speicher anders sein können.

Vielleicht liegt es aber auch an falschen Werten, z. B. ein Zähler, der bei allen Kunden hochzählt.

Ein solcher Fehler sollte sich aber relativ gut finden lassen, wenn er öfter auftritt. Gibt es kein Logging mit Stacktraces? Auch ohne Debugsymbole kann man die Speicheradressen verwenden.

Ach ja, und auch wenn du die Option deaktiviert hast (was sich manchmal böse rächen kann), kann die Exception noch manuell geworfen werden oder in Code auftreten, der vorkompiliert ist, z.B. von Drittkomponenten.

Es mag jenen reRangeError geben, welcher als ERangeError angezeigt wird
und wo sich über die Projektoptionen entsprechende Prüfcodes dafür erzeugen lassen, z.B. für den Zugriff auf Arrays.

Aber der ERangeError wird an vielen Stellen auch direkt ausgelöst,
vor allem in vielen Listen-Klassen, mit einer manuellen Bereichsprüfung des Index-Parameters.
Und das ist unabhängig von der ähnlich klingenden Compiler-Option.



Alternativ kann es natürlich auch sein, dass diese Compiler-Option in einer Unit explizit aktiviert wird.
{$R+} bzw. {$RANGECHECKS ON}

Jaaaaa, oder es wird eine (falsche/alte) DCU verwendet, welche generiert wurde, als diese Projektoption aktiv war.




PS: In neu erstellten Projekten (DPROJ) ist seit ein paar Delphi-Versionen diese Option standardmäßig aktiv.
Entgegen der Dokumentation, dass für den Compiler selbst immernoch OFF der Standard ist.
https://quality.embarcadero.com/brow...S%20default%22
Optimal war diese Idee, bzw. deren Umsetzung IMHO nicht wirklich.

Zitat von himitsu:

Jaaaaa, oder es wird eine (falsche/alte) DCU verwendet, welche generiert wurde, als diese Projektoption aktiv war.

ok das mag sein. Ich mache einmal bei einem der Kunden ein Update mit neu kompilierten Programmen.
Mich wundert nur das Neustart von Windows das Problem zuverlässig behebt. Mir hat auch noch keiner gesagt ob der Fehler am gleichen PC danach erneut Auftritt.

Zitat von himitsu:

Gibt es kein Logging mit Stacktraces?

Tja. Nein
Ich muss mich damit einmal genauer beschäftigen bzw. hab mich gerade dort reingelesen.
Aktuell sind unsere Logs manuell. Keine Automatik und das macht die Suche ab und zu unnötig kompliziert.

Das oder sowas in der Art vielleicht? https://embt.atlassian.net/servicede...tal/1/RSS-2038

Wenn es zuverlässig reproduzierbar ist,
dann könnte man noch über ein RemoteDebugging nachgenken.

z.B. via VPN mit dem Computer verbinden und mit Delphi ins Programm reingucken. (TeamViewer und Andere bieten auch eine VPN-Funktionalität an)

Zitat von stalkingwolf:

Hallo zusammen,

sehr strange. Bei einigen unserer Kunden tritt auf einmal in einem Programm beim starten ein ERangeError ( Fehler bei Bereichsprüfung ) auf.
Allerdings ist der Stand der Kunden teilweise Monate alt.
Vor allem melden sich immer mehr damit. Im Release Compile ist die Option in den Compileroptionen deaktiviert und war auch immer deaktiviert.
Noch kurioser. Das ist aktuell nur in einem Programm und ein Neustart von Windows löst das Problem temporär.

Windows Update? Noch jemand der aktuell damit zu tun hat?

Gruß

You have uninitialized variable (!) as simple as it sound.

Find it and prevent it, if there is an exception and you got a name for it "ERangeError", then you must have an address to associate it with along with a call stack, start there.

Also you are lucky it is an exception and not a silent and hidden data corruption, which might be happening silently.

Problem ist nicht mehr aufgetreten.
Nach mehr Rückfragen bei den Anwendern schien das immer 1x nach dem Windows Update aufzutreten, welches die Tage ausgerollt wurde.
Nach (richtigem) Neustart von Windows war das Problem danach immer weg.

sehr strange.