Schreibschutz für Objekte???

[Leanahtan]

Ok, das Thema ist vielleicht nicht so ganz aussagekräftig, aber mir ist nichts besseres eingefallen. Also ich habe folgendes Problem. In unserem Projekt benutzen wir eine ISO-Engine (auf Basis von Delphix). Im Laufe der Jahre hatten wir immer mal Fehler, die wir nicht wirklich erklären konnten, und wo wir lediglich vermutet haben, dass eventuell eine der DXDraw-Funktionen Bereiche im Arbeitssspeicher überschreibt. Das Problem trat aber nur sehr selten auf, und konnte nie reproduziert werden. Jetzt hab ich einige Änderungen an der ISO-Engine vorgenommen - während bisher alle Tile-Grafiken in einem einzigen Surface gespeichert wurden, hat jetzt jedes Tile sein eigenes Surface.
Allerdings ist jetzt der Fehler mit dem Überschreiben anderer Bereiche im Arbeitsspeicher nahezu reproduzierbar (man muss nur 1-2 Minuten ausprobieren). Im aktuellen Zustand wird im Laufe der Zeit ein eigentlich unabhängiges Surface (Soldatenportraits) überschrieben, was sich zuerst durch Darstellungsfehler bemerkbar macht, und irgendwann einen Crash verursacht. Leider habe ich keine Ahnung, wie man in so einem Fall die Ursache suchen sollte. Zu Delphix gibt es ja kaum eine ordentliche Doku. Außerdem hat Jim_Raynor vor Jahren eine Menge Änderungen vorgenommen, um z.B. Alphablending zu beschleunigen - ein Update auf die aktuelle Version von (un)Delphix ist also auch nicht möglich. Ich selbst hab eigentlich keine Ahnung von Delphix ^^. Meine einzige Idee war bis jetzt, den Speicherbereich für das Surface der Soldatenportraits irgendwie schreibgeschützt zu machen (und diesen Schreibschutz nur bei Bedarf aufzuheben), um so eine Zugriffsverletzung auszulösen, sobald irgendwo eine Funktion in diesen Speicherbereich schreiben will. Ist sowas irgendwie möglich? Oder habt ihr noch andere Ideen, wie man einem solchen Fehler auf die schliche kommen könnte?

[mkinzler]

Ich würde eher den Fehler im Programm suchen

[Leanahtan]

Genau deshalb will ich ja den Schreibschutz. Wenn es eine Zugriffsverletzung gibt, hätte ich eine Möglichkeit den Fehler zu debuggen. So habe ich überhaupt keinen Ansatzpunkt für den Fehler. Ich weiß nichteinmal, ob es wirklich mit den Zeichenroutinen zusammenhängt, oder ob an einer ganz anderen Stelle ein fehlerhafter Pointer auf das Surface zeigt.

[mjustin]

Zitat von Leanahtan:

Oder habt ihr noch andere Ideen, wie man einem solchen Fehler auf die schliche kommen könnte?

Exotische Fehler (wie zum Beispiel das Überschreiben von Speicher) kann man mit FastMM4 aufspüren, wenn die entsprechenden Features aktiviert sind.

Cheers,

[Medium]

Das wird bei DirectX noch zusätzlich dadurch verkompliziert, dass Texturen in unterschiedlichen "Pools" residieren. Prinzipiell können sie im VRAM, und im Host-RAM liegen, die Art des Pools definiert dann, wie DirectX mit der Textur umgehen soll wenn gerendert und/oder vom Host gelesen und/oder geschrieben wird. Ans VRAM kommst du spätenstens nicht mehr ran.
Es wäre aber auch SEHR ungewöhnlich, wenn DirectX da was verhackstückeln sollte. Sobald also die Daten über die API als Textur/Surface korrekt geladen sind, ist es fast sicher, dass das Problem dahinter sitzt - also entweder in deinem Code, oder in dem von DelphiX. In beiden Fällen jedoch müsste dafür eine Änderung am Surface bewusst vorgenommen werden, so dass DirectX entsprechend neue Daten aus dem Host-RAM in die Textur übernimmt.
DX Ressourcen sind nur änderbar, wenn sie zuvor gelockt wurden. Da wäre dann evtl. dein Ansatzpunkt: Alle Stellen, an denen etwas zwischen einem Lock und Unlock auf ein Surface ausgeführt wird, sind potentielle Kandidaten. Sowohl in deinem Code, als auch im Source von DelphiX. Mit viel Pech hast du es dann sogar mit einem Multi-Threaded Problem zu tun, bei dem ein Thread über seinen "Kompetenzbereich" hinweg kritzelt, während irgendwo anders ein Lock aktiv ist. Das wäre schon ziemlich ekelig . Erste Amtshandlung bei sowas: Bereichsprüfung anschalten, und wenn die wo anschlägt ist man meist fast schon am Ziel.

[Leanahtan]

Danke für die Antworten. Konnte damit den Fehler lokalisieren. Hing mit einer Compilerschalter-abhängigen Fallunterscheidung zusammen, wo ich einen der beiden Fälle noch nicht richtig umgesetzt hatte.

Delphi-Quellcode:

        {$IFDEF NOCLIPPING}
        Figur.Draw(Surface,Mem,XPos,Ypos,X,Y)
        {$ELSE}
        Figur.Draw(Surface,fTempMem,XPos,Ypos,X,Y)
        {$ENDIF}

fTempMem gehört zu einem anderen TDirectDrawSurface - die entsprechende Neuzuweisung für Surface fehlte aber noch.