JLI Spieleprogrammierung

[Fetze]

Ich kann seit kurzer Zeit im Releasemodus keine fehlerfreien Anwendungen mehr kompilieren. Ich bastele an einem Modulkomplex mehrerer miteinander in Verbindung stehender Projekte, die aufeinander aufbauen und eine Art Referenzkette bilden. Ich weiß nicht, wieso, aber seit kurzem funktioniert das "Endprogramm" nur noch im Debugmodus, im Releasemodus erscheint die folgende Fehlermeldung:



Exakt der gleiche Code funktioniert einwandfrei wenn von Visual Studio aus gestartet, lässt das Programm aber mit unbehandelter Exception abstürzen, wenn ich es nach "Neu Erstellen" ohne Visual Studio starte.

Ich verwende keine COmpilerdirektiven, die mit dem Debug- oder Releasemodus in Verbindung stehen.

Der Fehler tritt in der folgenden Zeile auf (Habe das per Console-Logs nach und vor jeder Zeile getestet):

[Dr. Best]

Genau kann ich es dir nicht sagen, aber es wird darauf hinauslaufen, dass du irgendwo undefiniertes Verhalten hast. Eine Zugriffsverletzung (lesen oder schreiben mit ungültigem Pointer) oder falsche delete-Aufrufe könnten die Ursache sein. Eine weitere Möglichkeit ist, dass du irgendwo Variablen nicht definierst bevor du daraus liest (so dass du willkürlichen Datenschrott darin hast, der dann später Probleme machen kann). Undefiniertes Verhalten ist eben durch den Programmcode allein nicht festgelegt. Es hängt von Faktoren wie momentanem RAM Inhalt und Speicherverwaltung ab und daher ist es nicht ungewöhnlich, dass es sich nur unter bestimmten Umständen bemerkbar macht.

Um es in solchen Fällen, wo es im Debugmodus nicht auftritt, besser analysieren zu können habe ich mir neulich noch einen kleinen Trick ausgedacht (der bei mir zumindest ein mal funktioniert hat). Ich habe einfach auf dem Stack ein völlig funktionsloses, aber ziemlich großes Array angelegt. So in der Art:

[Fetze]

Falls ich das noch nicht gesagt habe, vllt hilft es weiter:
Wenn ich die betroffene .dll durch die der debuversion ersetze (und alle anderen Dateien so lasse wie sie sind), dann läuft das Programm insgesamt völlig fehlerfrei.

Bevor ich diesen Fehler hier hatte trat auch schon ein anderer in derselben Methode auf (recht nah an der jetzigen Zeile), beim Versuch, Assembly.GetExecutingAssembly() oder GetCallingAssembly() aufzurufen. Ich habe die jeweilige Zeile durch GetAssembly(Type t) ersetzt und es lief wieder einwandfrei.
Hier die vorherige Fehlermeldung:





Zu deinem Post:
Nun, Zugriffsverletzungen sind eher schwierig, wenn man keine Pointer und nur managed code verwendet.. was meinst du mit falschen delete-Aufrufen?

Sollte sich bei nicht definierten Variablen nicht schon VOR dem Kompilieren der Debugger melden? (In welchen Fällen nicht?)

Danke für deinen Tip, aber bei mir tut sich da nichts. :/
Ich habe ein Array mit "int[] debug = new int[zahl];" initialisiert, ein kleines Stück vor der Fehlerbehafteten Stelle, zu Beginn der jeweiligen Methode (ist etwas größer). Entweder passiert gar nichts, oder - wenn ich das Array immer größer mache - es tritt ein OutOfMemory- oder Overflow-Fehler bei dr Initialisierung des Debugarrays auf. Was aber nru verständlich ist und mich nicht weiterbringt :/

Vorschläge?

[Dr. Best]

Oi, Managed Code. Ich mag Garbage Control nicht, aber naja, kein off-topic. Mit dem Debuggen von Managed Code habe ich noch nicht viel Erfahrung, aber vielleicht kann ich dir ja trotzdem helfen.

Falsche delete-Aufrufe sind bei Managed Code natürlich nicht machbar. Aber dass du nirgendwo Pointer verwendest kommt mir leicht unglaubwürdig vor ^_^ . Du wirst ja wohl gelegentlich Heapspeicher nutzen, da kommst du ohne Pointer doch garnicht aus. Außerdem braucht man für Zugriffsverletzungen nicht zwangsläufig Pointer (zumindest nicht explizit). Array look-ups mit ungültigen Indizes können auch Zugriffsverletzungen verursachen. Mal ein Beispiel, bei dem auch noch uninitialisierte Variablen vorkommen. Ist zwar Unmanaged C++ Code und nicht schön, aber müsste trotzdem ganz gut übertragbar sein:

[Fetze]

Okay, vielen Danke schonmal für deine Antwort. Ich habe deinen Beispielcode mal umgesetzt und eigentlich erwartet, das sich VS schon vor dem kompilieren über undefinierte Variablenwerte beschwert.. aber Fehlanzeige! Problem: Ich habe mich seit Projektbeginn darauf verlassen, dass VS das tut (weil das ja hin und wieder doch der Fall ist!) und das ist mittlerweile mehr als ein Jahr her.

Einen ähnlichen Fehler hatte ich schoneinmal, er verschwand jedoch irgendwann kommentarlos wieder.. jetzt muss ich also mal schauen, dass ich nach entsprechenden Stellen suche und diese eliminiere. Da der Fehler bereits in der Init-Funktion des Moduls auftritt, bleibt die Fehlerquelle glücklicherweise recht gering.

Gibt es weiterhin bestimmte "Suchtaktiken" oder vllt ein Programm, das Quellcode genau auf nichtinitialisierte Variablen prüft? Das wäre jetzt enorm hilfreich.


Edit: Mich beschleicht gerade das Gefühl, dass meine Programme teilweise auch via "Neu Erstellen" im Deubgmodus kompiliert werden, da ich - anders als vor eingier Zeit - keinen Performanceunterschied mehr zwischen Debug- und Releaseversion feststelle.. oO
Ich verwende Visual Studio C# Express 2005. Die Buildkonfiguration ist "Release", aber ich habe zwecks Umstellung auf x86-Prozessoren auch schonmal an den projektfiles rumgespielt.. wobei ich da nur ebendieses Attribut hinzugefügt habe.

Hier ein Ausschnitt aus der .csproj-Datei:

[Dr. Best]

Dass der Compiler sich bei im Konstruktor uninitialisierten Klassenmembern nicht beschwert macht schon Sinn. Wenn du z.B. eine sehr primitive Klasse, wie eine Klasse für 3D-Vektoren hast wäre das ziemlich unerwünscht. Wenn du ein Array mit 10000 Vektoren erstellst und der ersteinmal bei jedem einzelnen die Elemente auf Standardwerte setzen würde wäre das eben eine ziemliche Verschwendung. Außerdem kommt es immer mal wieder vor, dass bestimmte Member nur dann relevant sind, wenn die Instanz der Klasse in einem bestimmten Zustand ist. Wenn man z.B. eine Klasse für alle drei D3D Lichttypen hat, ist bei einem direktionalen Licht das Member für die Position egal und es ist in Ordnung wenn da Datenschrott drin ist. Eventuell kannst du aber in den Compilereinstellungen, dafür sorgen, dass bei uninitialisierten Variablen eine Warnung ausgegeben wird (müsstest du mal ein bisschen rumsuchen).

Ansonsten könntest du auch den manuellen Weg gehen. Jeden Konstruktor in jeder Klasse mit einer vollständigen Elementinitialisierungsliste versehen. Ist natürlich eine Sisyphusarbeit, aber wenn du es ein bisschen geschickt angehst kannst du damit in ca. zwei Tagen durch sein und bist das Problem und alle vergleichbaren dann immerhin los. Ich hatte mal etwas ähnliches. Hatte die schlechte Angewohnheit immer einfach in jeden Konstruktor

[Fetze]

Okay, langsam komme ich der Verzweiflung doch immer näher.

Habe mein Projekt als Backup gespeichert und dann beim ausgeführten Projekt den gesamten unwichtigen code hrausgeschmissen bis nur noch etwa 10 zeilen drin waren. Fehler besteht weiterhin. "Gut", dachte ich mir, "muss es am verwendeten Modul und nicht dem Programm selbst liegen". Da das ganze schon während der Init-Funktion abstürzt, bleibt mir glücklicherweise 99% des Debuggings erspart.. allerdings ist e mir ein Rätsel, wie das ganze schon dort abstürzen kann.

Nicht initialisierte Variablen fallen weg, da dort aus keiner einzigen Variable gelesen wird, nur geschreiben (wenn überhaupt). Ich habe festgestellt, dass das Projekt einwandfrei im Releasemode läuft, wenn ich den folgenden part auskommentiere dessen Aufgabe es ist, eingebettete Dateien zu extrahieren und als "eigenständige" Dateien abzuspeichern. Daraufhin werden sie eingelesen und wieder gelöscht.

[Dr. Best]

Ist jetzt nur so eine Idee, aber vielleicht hilft es ja. Die Zeilen hier kommen mir so vor, als könnten sie falsch sein:

[Fetze]

Ich hab das mal ausprobiert (auch im Vorherigen Codeabschnitt), allerdings besteht der Fehler weiterhin - das wars also nicht, trotzdem danke

[AFE-GmdG]

Ist das Thema noch aktuell?

Ich bin ein sehr guter C#-ler, das kann ich ohne rot zu werden von mir behaupten.

Zum (vor)letzten Post:
Strings in C# sind nicht NullTerminiert - sondern eine Klasse, welche die Länge und die Daten getrennt verwaltet speichert.
_________________

[Fetze]

Mittlerweile hat sich das Problem gelöst, es war ein externes Modul - genauergesagt: Eine fehlerhafte Implementierung eines externen Moduls in C#. Durch die auskommentierung zweier unwesentlicher Zeilen (Bestimmung der Modulversion) funktioniert alles bestens

[AFE-GmdG]

alles klar.
_________________