[C++, ASSIMP] Debug geht, Release nicht (mal wieder)

[ponx]

Hallo zusammen,
ich versuch gerade (immer noch :) ) den Render-code aus dem assimp-viewer in eine eigene Library, bzw. erstmal eigene Klassen auszulagern. Das sieht auch schon ganz gut aus, nur die Release-Version stürzt leider ab, mit "access violation writing location 0x0000000". Hier mal der CallStack beim Crash, falls es was nützt:

• memcpy(unsigned char * dst=0x00000000, unsigned char * src=0x08c66610, unsigned long count=16) ASM
• _aiGetMaterialFloatArray() + 0x1cd bytes C++
• _aiGetMaterialColor() + 0x23 bytes C++
• AssimpRendererD3d::CMaterialManager::CreateMaterial(AssimpRendererD3d::AssetHelper::MeshHelper ...) C++
• ...

Das Tückische ist, sobald ich in der gleichen Configuration die Debug-Library von Assimp benutze, funktioniert wieder alles ! In der gleichen Configuration muss ich dann auch als Runtime Library "Multi-threaded-Debug" anwählen, damit ich keine Linker-Fehler bekomme, aber ansonsten änder ich nichts.
Jetzt die Frage: Wie debuggt man sowas ? Ich kann nur bedingt durchsteppen, da wo's interessant wird, seh ich dann nichts mehr. Was mir aufgefallen ist: Ich kann erstens nicht mehr überall breakpoints setzen. Manche markiert er dann im sourcecode als durchsichtig, mit dem balloon tip "this breakpoint will not be hit. Invalid file". Andere breakpoints in der selben Methode akzeptiert er dagegen problemlos. Ich hab noch keine Gesetzmäßigkeit erkannt, wovon das abhängt.

zweitens: er crasht anscheinend innerhalb der folgenden for-schleife:

Code: Alles auswählen

    for (unsigned int meshIndex = 0; meshIndex < pScene->mNumMeshes; ++meshIndex)
    {
           ...
     }

.. wenn ich im Debugger durchsteppe, steht meshIndex innerhalb der Schleife beim ersten Durchgang nicht auf 0, sondern auf 5160368 ! :shock: Mit der Obergrenze (mNumMeshes == 8) ist aber alles ok. Jetzt frag ich mich: Wird das in der Release Configuration nur nicht richtig angezeigt, oder geht tatsächlich was beim Initialisieren der Variable schief ?

Fragen über Fragen, ich hoff ich könnt mir helfen!

Vielen Dank für eure Zeit,
andy / ponx

[Helmut]

Versuch mal die Optimierungen zu deaktivieren. Wenn es dann nicht abstürzt, liegt es entweder an einem Compilerbug oder daran, dass euer Code undefiniert ist.

Wenn es dann immer noch abstürzt, kann es alles mögliche sein;) Raceconditions, uninitialisierte Variablen, #ifdefs...

Ciao

[Schrompf]

Das Debuggen von Release-Code ist allgemein knifflig. Variableninhalte sind unzuverlässig und der Programmablauf springt gern mal hin und her oder lässt Zeilen und Abschnitte ganz aus. Das ist normal, den Fehler wirst Du anderswo suchen müssen.

Release vs. Debug ist, wie Helmut schrieb, üblicherweise eine Folge uninitialisierter Variablen oder auch von OffByOne-Arrayzugriffen. In der Debug haben diese Operationen alle definierte Werte, weil der Compiler Dir da Notfallwerte reinschreibt. Im Release ist das Ergebnis mehr oder minder zufällig. Schau mal nach uninitialisierten Variablen auf Deiner Seite, speziell bools sind da anfällig.

Nebenbei: auch dem Callstack kann man nur bedingt trauen in Release-Builds. Du solltest Dich zur Sicherheit auch per printf() drumrum an die vermutete Crash-Stelle herantasten.

[kimmi]

Man könnte für den Release-Build PDBs mit erstellen, dann wäre zumindest der CallStack relativ zuverlässig. Einfach unter Linker->Debug->Gernerate Debug Info auf Yes stellen. Falls das eh schon der Default ist, den Tipp ignorieren und weitermachen.
Ansonsten würde ich genau wie von Schrompf angeraten auf die guten alten printf's setzten, die lügen selten.
Vielleicht weiß Aramis Rat?

Gruß Kimmi

[Krishty]

Warum immer printf()? Benutzt OutputDebugString(), das geht auch ohne Konsole oder Fenster :)

[kimmi]

Die Funktion OutpuDebugString wird in der ASSIMP-Library bereits für das Loggen benutzt ( sofern der Stream attached ist ). Und ich benutze die auch gern zum Tracen von Fehlern in Engines bzw. GUI-Applikationen.

Gruß Kimmi

[ponx]

vielen Dank für eure Hilfe ! Ich hab damit angefangen, erstmal die Optimierungen auszuschalten - dann lief's ! Dann hab ich sie probehalber wieder ausgeschaltet - lief immernoch ! Mit release lib, und allem drum und dran. Manchmal versteh ich den Rechner nicht.. hat der Kaltstart geholfen ? Ich fürchte, es ist was Nicht-Initialisiertes und beim nächsten Hochfahren sieht die Welt schon wieder anders aus.. egal ich freu mich ich jetzt einfach mal und hoffe das bleibt so. Wenn nicht hab ich jetzt eure wertvollen Tipps, vielen Dank nochmal an euch alle !!

andy / ponx

[Aramis]

Wie immer kann ich nur noch den Ratschlag anfügen, in jedem Fall auf die aktuellste Revision zu aktualisieren, falls noch nicht geschehen. Letztens habe ich noch einige Konfigurations-Mismatches beseitigt die zu Crashes aufgrund zueinander unpassender STL/CRT-Versionen führten.

Der aktuelle Master-Trick besteht darin Assimp in einer DLL zu verwenden. Wenn ich mich richtig erinnere, hattest du aber genau damit Probleme. Mittlerweile hat sich der DLL-Build aber etabliert, etliche Programme nutzen ihn und kommen damit klar. Die Bugs von damals scheinen also gefixt zu sein.

Alex