Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Spiel stürzt immer ab, beim Debuggen aber nicht mehr

Werbeanzeige

patrick246

Treue Seele

  • »patrick246« ist der Autor dieses Themas

Beiträge: 328

Wohnort: nahe Heilbronn/BW

Beruf: TG Profil Informatik-Schüler

  • Private Nachricht senden

1

16.02.2013, 12:14

Spiel stürzt immer ab, beim Debuggen aber nicht mehr

Hallo Leute,
ich habe grade vorhin mein Spiel getestet, es lief bis ich auf den Start-Button gedrückt habe. Als ich das Spiel debuggen wollte, ging plötzlich alles wieder. Ich habs jetzt ziemlich oft getestet: Beim Debuggen funktioniert das Spiel, beim normalen Start (über den Windows-Explorer und Strg+F5) stürzt es an jener Stelle ab.

Jetzt habe ich es mit WinDbg versucht, das meldet mir folgendes:

Zitat

(13d4.1be0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=12deeaa8 ebx=12deebb8 ecx=003a0590 edx=00000000 esi=12deeaa0 edi=012f0000
eip=771a43d6 esp=0033f630 ebp=0033f658 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
ntdll!RtlpCoalesceFreeBlocks+0x26e:
771a43d6 8b12 mov edx,dword ptr [edx] ds:002b:00000000=????????

Allerdings kann ich damit nichts anfangen :(
Kann mir jemand helfen?

-p246

drakon

Supermoderator

Beiträge: 6 513

Wohnort: Schweiz

Beruf: Entrepreneur

  • Private Nachricht senden

2

16.02.2013, 12:26

Du hast eine Acces violation. Solche Probleme, die unterschiedliches Verhalten in Debug/Release verursachen kommen üblicherweise davon, dass du eine Variable nicht initialisiert hast. In Debug wird die dann auf 0 gesetzt und im Release nicht. Das heisst, dass so etwas hier die Ursache sein kann (und den Fehler, den du bekommst weist auch darauf hin):

C-/C++-Quelltext

 
1
2
3
4

int* p; // keine Initialisierung. In Debug wird das zu 0 initialisiert und in Release steht da irgendetwas drin.
...
if(p)
    cout << *p; // Access violation im Release, wenn p nicht auf einen wirklichen Wert gesetzt wurde.


Ich bin mir zu 99% sicher, dass es an so etwas liegt. Überprüf also mal, ob du alle Membervariablen deiner Klassen korrekt initialisierst!
http://www.drakon.ch | Weltweit 31. Bester Solitär Spieler (Standard XP)

patrick246

Treue Seele

  • »patrick246« ist der Autor dieses Themas

Beiträge: 328

Wohnort: nahe Heilbronn/BW

Beruf: TG Profil Informatik-Schüler

  • Private Nachricht senden

3

16.02.2013, 12:31

Kann man das verhalten ausschalten?
Ich hab mir nochmal das ganze angesehn, ich hab 2 Pointer

C-/C++-Quelltext

 
1
2

GUIView* m_gui;
RPGUtils::Player* m_pl;

Die beiden werden aber direkt im Konstruktor initialisiert

C-/C++-Quelltext

 
1
2

m_pl = new RPGUtils::Player();
m_gui = new GUIView(m_pl);

Und mit WinDbg kann ich auch nicht wirklich umgehen.

-p246

drakon

Supermoderator

Beiträge: 6 513

Wohnort: Schweiz

Beruf: Entrepreneur

  • Private Nachricht senden

4

16.02.2013, 12:39

Tja. Mit Debugger musst du lernen umzugehen!

Visual Studio hat einen recht guten Debugger und der ist auch einfach zu benutzen. In deinem Fall würde ich einfach einen Breakpoint in dem Code setzen, der ausgeführt wird nachdem du diesen "Start Button" drückst und dann mal schauen. wo genau er crasht (einfache Sachen lassen sich auch im Release debuggen!)
http://www.drakon.ch | Weltweit 31. Bester Solitär Spieler (Standard XP)

patrick246

Treue Seele

  • »patrick246« ist der Autor dieses Themas

Beiträge: 328

Wohnort: nahe Heilbronn/BW

Beruf: TG Profil Informatik-Schüler

  • Private Nachricht senden

5

16.02.2013, 12:56

Beim normalen Debuggen hat es ja problemlos funktioniert. Jetzt hab ich mich mal an den Prozess rangehangen. Anscheinend ist der Fehler irgendwo in der Funktion dbDeleteSprite(), die ist aber von DarkGDK. Der Sprite existiert aber und wird angezeigt. Zusätzlich ist das Änderungsdatum der Datei, in der die Zugriffsverletzung passiert, der 3. Februar. Bis heute morgen hat noch alles funktioniert. :(
Noch was zu Debug/Release: Als erstes hab ich alles in der Debug-Konfiguration ausprobiert und erst danach die Release. D. h. ich bin eigentlich immer bei Debug.

Tobiking

1x Rätselkönig

Beiträge: 1 231

  • Private Nachricht senden

6

16.02.2013, 13:24

Nur weil der Fehler im DarkGDK Code auftritt, heißt es nicht, dass dieser Code dafür verantwortlich ist. Wenn du dem DarkGDK einen uninitialisierten Zeiger übergibst (um dots Beispiel aufzugreifen), knallt es im DarkGDK obwohl dein Code den Fehler enthält. Schau dir doch mal den Call Stack an, und finde heraus welche Stelle in deinem Code für den Aufruf von dbDeleteSprite im DarkGDK sorgt.

patrick246

Treue Seele

  • »patrick246« ist der Autor dieses Themas

Beiträge: 328

Wohnort: nahe Heilbronn/BW

Beruf: TG Profil Informatik-Schüler

  • Private Nachricht senden

7

16.02.2013, 13:47

Der Aufruf von dbDeleteSprite findet in der onExit-Methode von MainMenuState statt. Das ist der GameState, der in der Main dem State-Manager übergeben wird. Wenn auf den Start-Button geklickt wird, dann wird ein neuer State auf den Stack gelegt und die onExit-Methode wird ausgeführt. DarkGDK arbeitet mit Handles, daher kann der Parameter nicht schuld daran sein. Es knallt ja nicht mal im DarkGDK-Code sondern in ntdll! Mein Programmteil hat sich wie gesagt seit dem 3. Feb nicht geändert, DarkGDK ist schon mehr als ein Jahr drauf und ntdll noch länger.
Nochmal zum Parameter: VC++ zeigt mir einen grünen Pfeil, beim drüberfahren sagt es mir, dass das die nächste Funktion ist, die ausgeführt wird. Also sollte der Fehler beim Aufruf davor liegen:

C-/C++-Quelltext

 
1

dbDeleteSprite(TEX_BG);

TEX_BG ist definiert als

C-/C++-Quelltext

 
1

static const int TEX_BG = 1;

Keine Pointer, die eine Zugriffsverletzung auslösen hätten können. Ich weis wirklich nicht mehr weiter.

-p246

EDIT:

Quellcode

 
1
2
3
4
5
6
7
8
9
10

    ntdll.dll!_RtlpCoalesceFreeBlocks@16()  + 0x1167 Bytes  
    ntdll.dll!@RtlpFreeHeap@16()  + 0x10b Bytes 
    ntdll.dll!_RtlFreeHeap@12()  + 0x54ed Bytes 
    kernel32.dll!_HeapFree@12()  + 0x14 Bytes   
    RPGGame1.exe!free(void * pBlock=0x1246ebc0)  Zeile 110  C
    RPGGame1.exe!CSpriteManager::DeleteJustOne()  + 0x11 Bytes  C++
    RPGGame1.exe!CSpriteManager::Delete()  + 0x28 Bytes C++
    RPGGame1.exe!CSpriteManager::GetList()  + 0x1a8e Bytes  C++
    RPGGame1.exe!dbDeleteSprite()  + 0xa Bytes  C++
    RPGGame1.exe!MainMenuState::onExit()  Zeile 41 + 0x7 Bytes  C++


EDIT2:
Die Funktion, auf die der Pfeil zeigt ist übrigens

C-/C++-Quelltext

 
1

dbDeleteSprite(TEX_BTN_START);

TEX_BTN_START ist definiert als (wer hätte es gedacht)

C-/C++-Quelltext

 
1

static const int TEX_BTN_START = 2;

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »patrick246« (16.02.2013, 14:08)

patrick246

Treue Seele

  • »patrick246« ist der Autor dieses Themas

Beiträge: 328

Wohnort: nahe Heilbronn/BW

Beruf: TG Profil Informatik-Schüler

  • Private Nachricht senden

8

16.02.2013, 15:14

So, hab mal alle Verweise auf meine DLL herausgenommen: Jetzt funktionierts! Nun meine Frage: Was hat das mit dem Aufruf von dbDeleteSprite zu tun??? ?(

Schrompf

Alter Hase

Beiträge: 1 470

Wohnort: Dresden

Beruf: Softwareentwickler

  • Private Nachricht senden

9

16.02.2013, 15:21

Gibst Du evtl. das Sprite ganz profan doppelt frei? Wenn die dbDeleteSprite()-Funktion das nicht intern abfängt, bekommst Du da auch einen Absturz.

Außerdem: Du benutzt da das Wort DLL. Beim Umgang mit DLLs muss man richtig vorsichtig sein. Wenn Du zum Beispiel Speicher in der DLL besorgst und den dann aber außerhalb der DLL freigibst, crasht es u.U. auch. Das passiert auch mit Typen, die intern dynamisch Speicher verwalten, also z.B. std::vector, std::string und viele weitere.
Häuptling von Dreamworlds. Baut aktuell an nichts konkretem, weil das Vollzeitangestelltenverhältnis ihn fest im Griff hat. Baut daneben nur noch sehr selten an der Open Asset Import Library mit.

patrick246

Treue Seele

  • »patrick246« ist der Autor dieses Themas

Beiträge: 328

Wohnort: nahe Heilbronn/BW

Beruf: TG Profil Informatik-Schüler

  • Private Nachricht senden

10

16.02.2013, 16:07

Oh oh, das mit dem Speicher reservieren und extern freigeben mache ich teilweise, aber nicht in der Klasse, die ich da verwendet habe. Doppelte Freigabe kann nicht sein, das Problem besteht ja nicht mehr, seit die DLL draussen ist.

Werbeanzeige

Ähnliche Themen