0002149: Zugriffsverletzung im AI-Skript

Notes
(0003864) DirkF 31.05.09 13:31	Zusatzinfo: Die Triliir-Antigraveinheiten haben einen der höchsten ZE-Werte und gleichzeitig mit den Nadelwaffen schwächere aber besonders schnell schießende Waffen. Es dürfte keine andere Kombination geben, die eine annähernd gleich hohe Anzahl von Schüssen pro Runde erlaubt. Eventuell sollte man das bei der weiteren Fehlersuche im Hinterkopf behalten.

(0003878) Natter 02.06.09 04:46	So, ich hab mich jetzt mal etwas in "fortgeschrittenem Debbuging" versucht. Die Zugriffsverletzung tritt definitiv in TGameFigure.WaitForWeapObj auf, genuaer in while CheckForWeapObj and (counter<10) do ... Da ich die Exception an der Stelle abfange, gibt es zwar eine Fehlermeldung, aber das Skript wird erstmal nicht beendet. Bisher hat das bei mir keine Probleme gemacht, die eigentliche Ursache ist aber immernoch unbekannt.

(0003879) Natter 02.06.09 05:07	So, das Problem liegt irgendwo hier: try // wegen Bug 2149 if not Pause then begin { Objekte verarbeiten } for Dummy:=0 to fObjectList.Count-1 do begin if (TISOObject(fObjectList[Dummy]) is TWaffenObject) then for FrameDummy:=1 to Frames do begin if (not TISOObject(fObjectList[Dummy]).Deleted) and TISOObject(fObjectList[Dummy]).PerformFrame then NeedRedraw:=true; end; end; end; except on E: Exception do begin game_api_MessageBox('Eine Exception ist in TDXIsoEngine.PerformWeapObjFrame aufgetreten. ' + 'Genauer in "if not Pause then ..."'+ sLineBreak + 'dummy: ' + IntToStr(dummy) + sLineBreak + 'fObjectList.Count ' + IntToStr(fObjectList.Count) + sLineBreak + 'Die Meldung lautet:' + sLineBreak + E.message,'behandelte Exception aufgetreten'); raise; end; end; Dem angehängten Screen ist zu entnehmen, dass dummy=fObjectList.Count=7 ist ^^

(0003880) DirkF 02.06.09 06:59	Ich würde einfach mal die Variable umbenennen. alles immer "dummy" zu nennen was man nur vorübergehend braucht, ist ein gewisses Risiko - und ich gehe davon aus das die hier zugeschlagen hat. Denn die For-Schleife sollte dummy nicht höher als 6 laufen lassen, und da es soweit ich sehen kann innerhalb der Schleife nicht verändert wird, könnte das eine Überlagerung gleichnamiger Variablen sein. Die andere mögliche Ursache wäre das der fObjectList.Count durch Zerstörung von Objekten reduziert wird, während diese Schleife noch läuft. Speichere das mal temporär und lasse die Schleife bis zum gespeicherten Wert statt dem direkten Wert laufen, gebe dann den aktuellen und den Originalwert in der Meldung aus.

(0003881) Natter 02.06.09 14:38	Ich nenne den Counter eigentlich immer i ;) Ist von anderer Stelle kopiert (also hat das vermutlich Christian geschrieben). Da AitForWeapObj ziemlich übersichtlich ist, glaube ich nicht, dass der Name der Variablen das Problem ist. Wenn der Fehler reproduzierbar wäre, wäre das Problem wesentlich besser einzugrenzen. So muss ich meinen Spielstand ca. 30 Minuten immer wierder neu Laden, bis das Problem mal auftaucht. Eigentlich kann ich mir nur vorstellen, das eines der Listenelemente irgendwo gelöscht wird - aber ich habe kein Ahnung, wo das passiert. Normalerweise erfolgt das Löschen erst in einer nachfolgenden Schleife (hier wird höchstens deletetd auf true gesetzt). Ich hatte schon überlegt, ob es mit dem Tode einer EInheit zu tun haben könnte. Aber ich bilde mir ein, einen Screenshot zu haben, wo der Fehler zwar auftritt, aberr alle 4 Soldaten noch leben (das könnte aber auch durch ein noch ausstehendes redraw bedingt sein). Außerdem werden getötete Einheiten ja erst am Einsatzende wirklich gelöscht. Ich werde versuchen, das Ganze noch weiter einzugrenzen, aber da es nicht reproduzierbar ist, könnte es dauern. A ndererseits - die Funktion wi rd nur per Skript genutzt, und der Zugriffsfehler kommt beim lesen - man könnte durchaus überlegen, die Exception in der veröffentlichen Version zu ignorieren (mache ich ja eigentlich schon jetzt - da der Fehler behandelt wird, läuft das AI-Skript ungestört weiter).

(0003882) Natter 03.06.09 01:06	Wie der letzte Screen deutlich belegt, kann sich an den Objekten in der Schleife jede Menge ändern. Selbst meine Überlegung mit dem down to könnte daher nicht ausreichend sein. Eventuell baue ich vor jedem Einsatz der Zählervariable nochmal eine Prüfung ein, ob die>=count ist. Mir ist trotzdem noch nicht klar, wie es dazu kommt. Dass ist insofern blöd, weil die Funktion für die Objekte von anderer Stelle kopiert wurde. Genau das Gleiche wird nämlich auch in TISOEngine.PerformeFrame gemacht. Und da diese Funktion nicht per Skript aufgerufen wird, würde der Fehler dort vermutlich zu einem Spielabsturz führen.

(0003888) Natter 04.06.09 14:46	if (not TISOObject(fObjectList[Dummy]).Deleted)... um (dummy<fObjectList.Count) erweitert. Das gleiche hab ich auch in PerformFrame gemacht, auch wenn es dort meines Wissens noch keine Probleme gab. Ich hoffe, damit ist das Problem in der b02 beseitigt. Wenn nicht, bitte nochmal melden.

Issue History
Date Modified	Username	Field	Change
29.05.09 13:39	Natter	New Issue
31.05.09 13:28	Natter	Relationship added	related to 0002156
31.05.09 13:31	DirkF	Note Added: 0003864
02.06.09 04:46	Natter	Note Added: 0003878
02.06.09 05:07	Natter	Note Added: 0003879
02.06.09 05:08	Natter	File Added: error3.png
02.06.09 06:59	DirkF	Note Added: 0003880
02.06.09 14:38	Natter	Note Added: 0003881
02.06.09 23:34	Natter	File Added: error5.png
03.06.09 01:06	Natter	Note Added: 0003882
04.06.09 14:43	Natter	Relationship replaced	has duplicate 0002156
04.06.09 14:46	Natter	Status	new => resolved
04.06.09 14:46	Natter	Fixed in Version	=> V0.915b02
04.06.09 14:46	Natter	Resolution	open => fixed
04.06.09 14:46	Natter	Assigned To	=> Natter
04.06.09 14:46	Natter	Note Added: 0003888
11.06.09 20:19	DirkF	Relationship added	related to 0002189
05.07.09 03:00	Gast	Status	resolved => closed