Unter Windows Abstürz

system · 4. Mai 2007 um 12:53

Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.

orit_s · 4. Mai 2007 um 12:53

Unter Windows Abstürz
Unter Linux geht, unter Windows stürzt ab.
Ich versuche Program zu starten, dann bricht es ab mit den folgende Fehlermeldung

Unhandled exception at 0x023b0342 in offroad.exe: 0xC0000005: Access violation reading location 0x0400e008.
und bei Disassemly wird folgene Zeile ausgegeben

023B0342 fld qword ptr [esi+10h]

Woran kann das liegen. Mein Übungspartner sagt, dass im Cip bei ihm geht.

Ford_Prefect · 4. Mai 2007 um 13:24

Debugger hilft.

orit_s · 4. Mai 2007 um 13:46

Es scheint an der Stelle
if( (errCode = glGetError() ) != GL_NO_ERROR )

zu krachen

orit_s · 4. Mai 2007 um 13:49

es kommt von Err::PrintGLError()
ich habe auskommentiert, dann stürzt bei
glGetIntegerv(GL_MATRIX_MODE, &a);
ab

orit_s · 4. Mai 2007 um 17:13

Das Problem ist erst bei zweiter Aufgabe aufgetaucht. Ich habe an Code nichts geändert. Bei PlainTerrain geht, bei BruteForceTerrain stürzt ab. Also mein Code kann nicht der Grund dafür sein… Oder?

orit_s · 4. Mai 2007 um 17:14

Ist bei jemandem, der unter Windows arbeitet auch so ein Problem aufgetaucht, oder läuft alles einwandfrei.

orit_s · 4. Mai 2007 um 18:04

ich habe versucht das Programm von der Kommandozeile zu starten, dann kommt raus:

I/O warning : failed to load external entity “contactdb.xml”
Could not open contactdb.xml!

J_Suessmuth · 4. Mai 2007 um 19:11

Wahrscheinlich unterstützt deine Graphikkarte keine VBOs (Wir haben die Extension-Tests ja auskommentiert), versuchs auf jeden Fall mal mit einem neuen Treiber.

Der Kommandozeilenstartfehler hört sich so an, als ob du aus dem falschen Verzeichnis startest. Immer
release\offroad starten,
nie
cd release; offroad

Gruss, Jochen

orit_s · 4. Mai 2007 um 19:28

wir haben in der ersten Aufgabe mit VBO Buffer gearbeitet. Außerdem habe ich GeForce 7600 GS, also wenn an der nicht geht…

J_Suessmuth · 4. Mai 2007 um 19:44

In welcher Klasse tritt der Fehler denn auf? Die oben angegebenen Code Schnipsel kann ich nämlich in BruteForceTerrain nicht finden?

Gruss, Jochen

orit_s · 4. Mai 2007 um 20:38

also es geht so:
renderactionstd.cpp

if ( Game::param.renderFlags & Game::TERRAIN ) {
(*m_ppTerrain)->Render(cam, fulldetail);
}

springt in Render von BruteForceTerrain, am Ende steht:

Err::PrintGLError( "after BruteForceTerrain render: " );

springt in error.cpp PrintGLError

if( (errCode = glGetError() ) != GL_NO_ERROR )
Fehlermeldung: Unhandled exception at 0x01d6f4c2 in offroad.exe: 0xC0000005: Access violation reading location 0x03dca008.
Eine weitere Fehlermeldung: There is no source code available for the current location.

orit_s · 4. Mai 2007 um 20:48

Message.Log

– using scene map scene_assignment_2_shader
XML::ParseFlag(): Warning: Empty property dayloop, returning false!
XML::ParseFlag(): Warning: Empty property pos_global, returning false!
XML::ParseFlag(): Warning: Empty property pos_global, returning false!
XML::ParseFlag(): Warning: Empty property pos_global, returning false!
XML::ParseFlag(): Warning: Empty property pos_global, returning false!
XML::ParseFlag(): Warning: Empty property pos_global, returning false!
XML::ParseFlag(): Warning: Empty property pos_global, returning false!
XML::ParseFlag(): Warning: Empty property pos_global, returning false!
XML::ParseFlag(): Warning: Empty property pos_global, returning false!

weiter geht ganz OK. bis zur
done (hud elements)
… Initialize() done

orit_s · 4. Mai 2007 um 21:21

Ok. Ich habe jetzt reines Skeleton geladen und es geht. Also liegt es doch an unserem Code vermutlich.

orit_s · 5. Mai 2007 um 11:24

Ich weiß jetzt woran es liegt. In DrawElementMesh haben wir VBO Buffer benutzt und es scheint irgendwie in Konflikt zu VBO in BrutForseTerrain zu stehen. Ich habe jetzt DrawElementMesh ohne Verwendung von VBO benutzt und es läuft.

F.Enders · 5. Mai 2007 um 16:49

Hi,

ich hab mir mal den Code angeschaut und hier ein paar kleine Kommentare dazu:

VBO in DrawElementMesh
Nette Idee, aber die Kombination von VBO UND Displayliste ist nicht unbedingt noetig. Entweder oder, aber beides zusammen ist nicht sinnvoll.
Wenn ihr VBOs benutzen wollt, dann fangt bitte, bitte nicht an, euch die Funktionspointer unter Windows selbst zu holen. Dafuer ist die InitExtensions in basis/glsetup.cpp da! Wenn ihr die Funktionsaufrufe glGenBuffer, etc., ohne ARB verwendet haettet, haettet ihr das auch gar nicht gebraucht. VBOs sind seit OpenGL 1.4 oder 1.5 Standard und wir initialisieren eh alles fuer 1.5. Also die Funktionen fuer die VBOs einfach plain verwenden und schon kann man sich das Funktionspointer-Geschubse sparen.
Wenn ihr VBOs verwendet, dann auch immer am Ende wieder abstellen. Das habt ihr in eurer Displayliste nicht gemacht, weswegen der eigentlich hier besprochene Fehler aufgetreten ist. Folgendes fehlt in DrawElementMesh.

	glBindBuffer(GL_ARRAY_BUFFER_ARB, 0);
	glDisableClientState(GL_VERTEX_ARRAY);
	glDisableClientState(GL_NORMAL_ARRAY);
	if (textured)
	{
		glDisableClientState(GL_TEXTURE_COORD_ARRAY);
	}

BTW, das ganze ist eh ein wenig exotisch (siehe 1.). Die ganzen Buffer- und ClientState-Befehle werden nicht in die Liste Compiliert. OpenGL wird nur die per VBO abgesetzen Daten neu kapseln. Daher sind die VBOs hier der totale Overhead. Normale Arrays haetten IMHO exakt den selben Effekt.

Wenn ihr VBOs verwendet, solltet ihr auch fuer deren Freigabe sorgen. Das geschieht nicht automatisch! In diesem Fall haette das gleich hinter der Generierung der Displayliste geschehen koennen (siehe 3.), spaetestens aber im Destruktor.
m_pSphere im DrawElementMesh wird in der Basisklasse geloescht, wenn es gesetzt wurde. Ihr loescht es schon im eigenen Konstruktor. Ist OK, aber dann auch den Pointer auf 0 setzten, sonst krachts beim Beenden.
Wie schafft ihr es eigentlich, ein nicht konstantes Array im Skydome unter Windows zu kompilieren?

vec3d vektoren[resolution*3][resolution];

Unter Linux geht das meines Wissens glatt durch, aber VS? Mein Compiler frist das nicht, was bedeutet, dass man das Ding dynamisch anlegen und natuerlich auch wieder loeschen muss.

Da auch gleich noch einen Kommentar an die Allgemeinheit(auch auf die Gefahr hin, dass ich mich mit dem ein oder anderen Kollegen anlege g): Wenn ich noch einmal einen erwische, der malloc verwendet … wir schreiben C++ Code. Also ist hier new gefragt und Kombis wie malloc und delete, bzw. new und free sind erst recht nicht gerne gesehen. Das Weglassen jeglicher Speicherfreigabe-Routinen ist uebrigens auch nicht rechtens!!!

Ich hoffe das hilft euch und auch allen anderen weiter. Das ganze ist auch NICHT auf ein Team bezogen. Ich hab diverse solche Dinge bei einigen Abgaben gesehen. Ist also mehr als allgemeiner Leitfaden zu versehen.

Schoenes WE. Gruss
Frank