Unbehandelte Ausnahme: Zugriffsverletzung beim Lesen

[NoxMortem]

Unbehandelte Ausnahme bei 0x01367409 in Game_Debug.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0xfeeefef6.
Eine Ausnahme (erste Chance) bei 0x01367409 in Game_Debug.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0xfeeefef6.
Unbehandelte Ausnahme bei 0x01367409 in Game_Debug.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0xfeeefef6.

Das Programm lässt sich aber starten und verwenden. VS10 zeigt an, dass die Verletzung in std::vector auftritt.

size_type size() const
{    // return length of sequence
return (this->_Mylast - this->_Myfirst);
}

[Teretrus]

Wenn du siehst, wo das Problem auftritt, nehme ich an dass Visual Studio dort kurz ein "Halt" macht. Du kannst im Debugging Menü unter Windows den CallStack ansehen.
Der CallStack zeigt dir von wo die Funktion in diesem Moment aufgerufen wurde (und von wo die Funktion, welche in diesem Fall size() aufgerufen hat, aufgerufen wurde, usw.).

Klick einfach auf die "äußere" Funktion und schau dir die Variable (über Debugging -> Windows -> Watch -> Watch1) an, die den std::vector halten sollte, für welchen du size() aufrufst.

Ich würde darauf tippen, dass ein pointer entweder NULL/nullptr ist, oder vielleicht sogar nichtmal initialisiert wurde (sprich random daten im pointer stehen).

Aber du kannst auf jeden Fall mal herausfinden wo dein Fehler auftritt (std::vector ist ja nicht die Quelle des Fehlers, sondern nur das "Symptom").

[NoxMortem]

Danke. Wir hatteb zuerst ein "delete game" und dann deletes die sich auf Variablen in game bezogen haben.

[NoxMortem]

oooookay. Jetzt haben wir eine Zugriffsverletzung, für die aber nichtmal Quellcode verfügbar ist. Ich habe zwar 2 neue Dateien erstellt aber diese werden noch nirgends verwendet.

user32.dll!75ad7a24()
[Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für user32.dll]
user32.dll!75ad79df()
HydraDMH.dll!1000d6c6()
HydraDMH.dll!10009d6d()
HydraDMH.dll!1000d6c6()
HydraDMH.dll!10005318()
user32.dll!75ad8336()
user32.dll!75b26a58()
user32.dll!75ac6e44()
ntdll.dll!774f010a()
user32.dll!75ac9a6a()
> Game_Debug.exe!__glfwPlatformGetProcAddress() + 0x1d94 Bytes C
Game_Debug.exe!__glfwPlatformOpenWindow() + 0x190 Bytes C
90900004()

[mOfl]

In solchen Fällen kann dir keiner helfen, der den Code nicht selbst auführt. Setze einen Breakpoint ganz am Anfang deines Programmes, starte im Debug-Modus und gehe Schritt für Schritt (F10 für komplette Calls, F11, um in aufgerufene Methoden zu springen, sofern verfügbar, und F5, um zum nächsten Breakpoint zu springen) durch, bis die Exception auftritt. Wenn du die genaue Zeile kennst, siehst du oft schon, wo der Fehler liegt - im Debug-Modus kannst du den Wert/Pointer von Parametern und Variablen auslesen, da passt dann oft irgendwas nicht. Wenn es sich bei der entsprechenden Zeile um einen GLFW-Call handelt, wäre das natürlich ungünstig.

[NoxMortem]

if (glfwOpenWindow( width,height,
0,0,0,0,
24, 8,
GLFW_WINDOW) != GL_TRUE) {
cerr << "Failed to initialize OpenGL window." << endl;
glfwTerminate();
return 1;
}

glfwSetWindowTitle("Galaxy Conquest V0.1");

Der Fehler tritt bei glfwOpenWindow() auf. Aber mir ist absolut nicht klar, was ich da falsch gemacht haben könnte.
Edit2: Mein Kollege hat das Problem aber scheinbar nicht!

Jetzt stellt sich halt die Frage ob ichs einfach ignorieren und "weiterarbeiten" soll? Ist ja doof wenn man schon beim Fensteröffnen gleich mal den ersten Fehler bekommt.

Edit3: Wenn ich den HydraGrid (ATI DesktopManager) beende gibts im Programm keinen Fehler mehr. Ich wüsste jetzt nicht wie ich das ausbessern soll, also werde ich es wohl einfach ignorieren.

[mOfl]

Rufst du

glfwInit();

auf, bevor du GLFW verwendest? Die Argumente von glfwOpenWindow sehen sonst recht normal aus, du könntest statt 0, 0, 0, 0 auch 8, 8, 8, 0 oder 8, 8, 8, 8 schreiben (0 bei den Farben heißt Default-Größe, 0 beim Alpha-Kanal heißt kein Alpha-Kanal), aber korrekt ist es auch so schon. Setzt du vorher noch irgendwelche Window Hints? Ich weiß jetzt nicht, was passiert, wenn man Hints setzt, die von der Hardware nicht unterstützt werden, z.B. OpenGL 3.2 Core Profile Context.

[don_durito]

was beim debuggen auch hilfreich sein kann, sind die verwendeten magic numbers vom visual studio debug mode: http://stackoverflow.com/questions/1...epresentations

Damit kann man normalerweise das Problem etwas eingrenzen.