Warning: ob_start(): function 'compress_handler' not found or invalid function name in /www/htdocs/xfmantis/core.php on line 18
0002149: Zugriffsverletzung im AI-Skript - Mantis
Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0002149 [X-Force] Bodeneinsatz major random 29.05.09 13:39 05.07.09 03:00
Reporter Natter View Status public  
Assigned To Natter
Priority normal Resolution fixed  
Status closed   Product Version V0.915b01
Summary 0002149: Zugriffsverletzung im AI-Skript
Description Das AI-Skript erzeugt manchmal eine Zugriffsverletzung, und wird dadurch vorzeitig beendet. Laut Fehlermeldung tritt der Fehler in ShotAsLongAsPossible bei Figure.WaeitForWeapObj auf. Leider konnte ich auch nach länerem Suchen die Ursache bisher nicht finden.

Das Problem ist auch nicht sicher reproduzierbar. Ich hab es im GalWar mit 2 AntiGrav-Einheiten mehrfach beobachtet, wenn ich in einem Haus in Deckung ging, und die Aliens erstmal die Wände wegschossen. Ich kann nicht sagen, ob es damit zusammenhängt. Allerdings ist das Problem bei mir noch nie beim ersten Schuss aufgetreten.
Additional Information
Attached Files  error3.png [^] (30,396 bytes) 02.06.09 05:08
 error5.png [^] (116,088 bytes) 02.06.09 23:34

- Relationships

SYSTEM WARNING: Creating default object from empty value

has duplicate 0002156closed Natter X-Skript Bodeneinsatz AI Fehler 
related to 0002189closed Natter X-Force Fehler bei PerformWeapObjFrame (und der AI-Skriptfunktion auch) 

- 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


Mantis 1.0.7[^]
Copyright © 2000 - 2007 Mantis Group
Powered by Mantis Bugtracker