Merkwürdige Access-Violations

[Maliko]

Moin,

ich hab da irgendwie momentan ein sehr merkwürdiges Problem mit unserer Delphi Version. Dieses Problem tritt aber erst seit unserem letzten Windowsupdate auf. Und zwar habe ich ein TSqlQuery, welches mehrere Parameter hat. Doch sobald das Programm bei einem Parameter angekommen ist, bricht das ganze mit einer AccessViolation ab. Es existiert aber kein Fehler. Wenn ich über Delphi auf Bereinigen gehe und neu Compiliere dann ändert sich nichts, doch wenn ich manuell alle DCUs in dem Projekt lösche (ich benutze dafür ein kleines Script, welches alle Ordner in dem Projekt rekursiv durchsucht und einfach alle Dateien löscht die als Dateiendung DCU haben), dann Delphi neu starte (ich muss es einmal neu Starten) und dann wieder neu kompiliere, ist der Fehler plötzlich weg.

Das Problem habe ich erst seit unsere Admins unsere Systeme aktualisiert haben (neues Windows, plus einen Zusätzlichen Patch für Delphi). Die alte Windows-Version war Windows 10 1909 (Build: 18363.1016) und die die jetzt läuft ist Windows 10 21H2 (Build: 19044.1586). Dazu wurde das IDE Fix Pack 6.4.4 for Delphi 10.3 installiert. Wir entwickeln in VMs daher konnte ich die alte VM einfach starten und da funktioniert das ganze ganz normal. Also muss es irgendwie mit den DCUs in Verbindung mit dem Addon für Delphi + neue Windowsversion zu tun haben.

Hat von euch zufällig jemand so etwas auch schon beobachtet und kann mir sagen, wie ich das Problem umgehen kann? Weil dass tritt irgendwie immer mal wieder auf und ich kann schlecht mit jeder neuen gebauten Version jede einzelne Programmlogik ausprobieren, ob da irgendwo wieder ne DCU kaputt gegangen ist. Wir arbeiten mit Delphi 10.3.3 und nein, wir können auch nicht Updaten, da unsere Upgradelizenz abgelaufen ist.

Vielleicht kann mir jemand von euch da mal weiterhelfen und hat eine Idee was da schief läuft. Ich hab ihm Anhang auch noch mal nen Screenshot mit der Fehlermeldung angehängt. Wundert euch nicht über die Massiven Schwärzungen, aber an den Stellen befinden sich sensible Kundendaten, welche ich aus Datenschutzrechtlichen Gründen schwärzen musste (wir arbeiten mit Sozialversicherungsdaten).

Viele Grüße
Maliko

[TiGü]

Und die Zeilen rund um 1102 im Quelltext zu TPflegeerfassung.FormKeyDown willst du uns nicht zeigen?
Ihr prüft auf DeineSqlQuery.Params <> nil?

[haentschman]

Welche DB zu TSqlQuery? Treiber/DLL? Ich tippe auf ACCESS...

[Maliko]

Zitat von TiGü:

Und die Zeilen rund um 1102 im Quelltext zu TPflegeerfassung.FormKeyDown willst du uns nicht zeigen?
Ihr prüft auf DeineSqlQuery.Params <> nil?

Damit werdet ihr nix anfangen können, da in der ZEile lediglich die Exception geworfen wird und davor wird nur eine weitere Funktion aufgerufen, die wie schon gesagt normalerweise immer funktioniert (und in der alten VM funktioniert diese auch, nur in der neuen VM nicht, es sei denn ich lösche die DCUs manuell).

Zitat von haentschman:

Welche DB zu TSqlQuery? Treiber/DLL? Ich tippe auf ACCESS...

Nope. Wir arbeiten mit Oracle und benutzen dbExpress als Treiber.

[Blup]

Also im Prinzip passiert das hier:

Delphi-Quellcode:

var
  Query: TSqlQuery;
begin
  Query.Prepared := True;
  Query.ParamByName('XXX').AsInteger := x;
  // Parameter XXX existiert nicht (= nil)
  // nil.AsInteger führt zur Zugriffsverletzung

Warum das so ist können wir nur spekulieren.

[jaenicke]

Gehe doch einfach mal durch welche Params da sind. Vielleicht bringt diese Liste im Fehlerfall ja Licht ins Dunkel.

[Sinspin]

Leute, anstatt hier massenweise Vermutungen und Lösungen zu den Vermutungen hinzukippen, erstmal richtig lesen:

Zitat von Maliko:

... doch wenn ich manuell alle DCUs in dem Projekt lösche (ich benutze dafür ein kleines Script, welches alle Ordner in dem Projekt rekursiv durchsucht und einfach alle Dateien löscht die als Dateiendung DCU haben), dann Delphi neu starte (ich muss es einmal neu Starten) und dann wieder neu kompiliere, ist der Fehler plötzlich weg. ...

Wie oft musst Du das machen? Nach dem Wechsel auf eine neue VM? Oder immer wieder, seit dem Umzug auf die neue VM.

[Maliko]

Zitat von Sinspin:

Leute, anstatt hier massenweise Vermutungen und Lösungen zu den Vermutungen hinzukippen, erstmal richtig lesen:

Zitat von Maliko:

... doch wenn ich manuell alle DCUs in dem Projekt lösche (ich benutze dafür ein kleines Script, welches alle Ordner in dem Projekt rekursiv durchsucht und einfach alle Dateien löscht die als Dateiendung DCU haben), dann Delphi neu starte (ich muss es einmal neu Starten) und dann wieder neu kompiliere, ist der Fehler plötzlich weg. ...

Wie oft musst Du das machen? Nach dem Wechsel auf eine neue VM? Oder immer wieder, seit dem Umzug auf die neue VM.

Leider sehr unregelmäßig. Lässt sich auch nicht wirklich nachvollziehen. Wir arbeiten mit SVN. Wir haben im SVN nen neuen Tag erstellt und diesen dann ausgecheckt (Die DCUs werden nicht mit eingecheckt). Nachdem wir den Tag kompiliert haben trat der Fehler auf. Nachdem wir dann die DCUs gelöscht haben und noch mal neu kompiliert haben, trat der Fehler nicht mehr auf. Im Trunk funktionierte es die gesamte Zeit. Das ist ja das Merkwürdige.

Das Merkwürdige ist halt dass das Problem überhaupt erst auftritt, seit wir die neue Windowsversion plus das Pack für Delphi haben. Vorher hatten wir das Problem nie und auf der alten VM ohne das Pack haben wir das Problem auch weiterhin nicht. Der Fehler ist überhaupt nur aufgetreten, da wir die Version des Programmes getauscht haben und das die erste Version war, die vom neuen System erstellt wurde.

[MyRealName]

Hast Du denn Query überhaupt erzeugt ? Fehler sagt "Fehler beim Lesen von Adresse 00000010", was auf ein nicht-initialisiertes Objekt hindeutet.
Im Code, den Du uns zeigst, hast Du Query lokal deklariert und benutzt es, aber ich sehe kein Create.

Wenn es da ist, alles gut.. dann zum ParamByName. Zeig mal Dein SQL, vllt. hast Du den Param XXX auch wirklich nicht drin. Die sind normalerweise so ":XXX" zu erkennen

[jaenicke]

Zitat von MyRealName:

Wenn es da ist, alles gut.. dann zum ParamByName. Zeig mal Dein SQL, vllt. hast Du den Param XXX auch wirklich nicht drin. Die sind normalerweise so ":XXX" zu erkennen

Dann würde es kaum unregelmäßig auftreten.

Wahrscheinlicher ist, dass dort eine .dcu nicht korrekt erstellt wird bzw. eine irgendwo vorhandene falsche Unit verwendet wird. Deshalb mein Vorschlag, dass zu Debugzwecken irgendwo die vorhandenen Parameter abgelegt werden. Dann gibt es im Fehlerfall zwei Möglichkeiten: Die Parameterliste ist falsch oder leer, dann kann man dort weitermachen, oder aber die Debuginfo fehlt. Dann wurde die neue Version der Unit gar nicht verwendet.