dbgheap.c Zugriffsverletzung
-
Hallo,
ich weiß nicht genau wo das Thema hin soll, also habe ich es mal ganz allgemein hierhin geschrieben.
Wenn ich mein Programm debuggen möchte, spuckt mir der Kompiler von Visual Studio 2010 folgende fehlermeldung aus:
Eine Ausnahme (erste Chance) bei 0x1031723c (msvcr100d.dll) in OpenGL.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0xfffffffc.
Unbehandelte Ausnahme bei 0x1031723c (msvcr100d.dll) in OpenGL.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0xfffffffc.und werde in dbgheap.c auf folgende Zeilen verwiesen:
extern "C" _CRTIMP int __cdecl _CrtIsValidPointer( const void * pv, unsigned int nBytes, int bReadWrite ) { return (pv != NULL); }Ich meinen Code Stück für Stück auskommentiert, die Fehlerquelle aber nicht gefunden. Auch habe ich es mal Probiert 945 Schritte rückgängig zu machen. Allerdings bestand der Fehler dann immer noch.
Da mein Projekt über 1000 Zeilen lang ist, möchte ich nicht alles hier rein posten. Falls ich es doch tuen soll, sagt es bitte.
Kennt jemand diesen Fehler, oder gibt es eine Möglichkeit die Fehlerquelle zu finden?
-
Pikkolini schrieb:
Da mein Projekt über 1000 Zeilen lang ist, möchte ich nicht alles hier rein posten. Falls ich es doch tuen soll, sagt es bitte.
-
Sehr große Sachen am besten bei pastebin pasten und den Link posten.
http://pastebin.com/
-
Den Fehler spuckt nicht der Compiler, sondern der Debugger aus.
Du solltest im Callstack (unten rechts im Visual C++ Fenster) nachsehen, wo dein Code diese Funktion aufruft.
Solche Zugriffsverletzungen entstehen wenn du einen gelöschten/ungültigen Zeiger dereferenzierst/deletest.
-
Tu Es Tu Es! schrieb:
Pikkolini schrieb:
Da mein Projekt über 1000 Zeilen lang ist, möchte ich nicht alles hier rein posten. Falls ich es doch tuen soll, sagt es bitte.
Ok, ok

Falls jemand denkt, der Code kommt einem bekannt vor, das liegt daran, dass ich ihn aus ein paar Tutorials zusammengebastelt habe.
Hier der Code von der Main.cpp:
Main.cppIch habe von Zeile 14 bis 402 alles auskommentiert, aber fehler besteht immer noch. Deswegen denke ich auch, dass es nicht an Opengl liegt.
Dann der Code von dem Texturlader:
Textur.cppUnd die dazugehörigen Header Dateien:
tga.h
texture.hPS: Falls jetzt jemand sagt, es sind keine 1000 Zeilen, es sind nur 862. Hab mich ein bisschen verschätzt.

-
Oberon_0 schrieb:
Den Fehler spuckt nicht der Compiler, sondern der Debugger aus.
Du solltest im Callstack (unten rechts im Visual C++ Fenster) nachsehen, wo dein Code diese Funktion aufruft.
Solche Zugriffsverletzungen entstehen wenn du einen gelöschten/ungültigen Zeiger dereferenzierst/deletest.Wenn du damit die Aufrufhierachie meinst, spuckt die immer diese Meldung aus:
Die Funktion mit dem Namen "xy" wurde nicht gefunden.
-
Sorry wegen Dreifachpost. Ich hab mich jetzt mal registriert, damit ich meine Beiträge editieren kann.
Also aus dem Callstack werde ich nicht wirklich schlau...
Ich habe mal ein Screen gemacht, damit ihr ihn auch mal sehen könnt:
[http://img231.imageshack.us/img231/5536/callstack.th.pngWenn ich das Projekt allerdings als Release kompiliere, funktioniert es auch so wie es soll und der Compiler spuckt keien Warnung oder Ähnliches aus...
EDIT:
Der Debugger spuckt auch noch folgendes aus:
http://msdn.microsoft.com/de-de/library/360csw6a%28VS.80%29.aspx
-
Pikkolini schrieb:
Sorry wegen Dreifachpost. Ich hab mich jetzt mal registriert, damit ich meine Beiträge editieren kann.
Also aus dem Callstack werde ich nicht wirklich schlau...
Ich habe mal ein Screen gemacht, damit ihr ihn auch mal sehen könnt:
[http://img231.imageshack.us/img231/5536/callstack.th.pngWenn ich das Projekt allerdings als Release kompiliere, funktioniert es auch so wie es soll und der Compiler spuckt keien Warnung oder Ähnliches aus...
Wenn deine Zeilen angeben richtig sind, dann steht da genau an welcher stelle das Problem herscht und zwar in Zeile 113 bei diesem Aufruf:
free(texture[loop].imageData);Ich versteh nur noch nicht wieso du denn das free() im Loop aufrufst, du rufst das LoadTGA ja auch nur einmal auf, könnt aber auch schon an der Uhrzeit liegen wieso ich es nicht verstehe :-).
Hmm wieso im Release nichts angegeben wird, kann ich dir leider nicht sagen. Könnte wenn dann nur mit sowas wie Assert zusammen hängen, welcher auch nur in den Debug-Version Meldungen liefern.
Pikkolini schrieb:
EDIT:
Der Debugger spuckt auch noch folgendes aus:
http://msdn.microsoft.com/de-de/library/360csw6a%28VS.80%29.aspxKönnte genaus mit oben angegebenen loop zu tun haben, wenn der 2te ins Nirvana zeigt und du dieses Objekt auflösen möchtest.
PS: Wenn du in der Aufrufliste auf eine Zeile doppelt klickst kommst du genau zu der angewählten Funktion in die entsprechende bearbeitende Zeile, kann manchmal sehr hilfreich sein.
Mfg marco
-
Marc-O schrieb:
PS: Wenn du in der Aufrufliste auf eine Zeile doppelt klickst kommst du genau zu der angewählten Funktion in die entsprechende bearbeitende Zeile, kann manchmal sehr hilfreich sein.
Mfg marco
Da komm ich ja zu der Funktion CheckBytes() in dbgheap.c.
Marc-O schrieb:
Wenn deine Zeilen angeben richtig sind, dann steht da genau an welcher stelle das Problem herscht und zwar in Zeile 113 bei diesem Aufruf:
free(texture[loop].imageData);Ich versteh nur noch nicht wieso du denn das free() im Loop aufrufst, du rufst das LoadTGA ja auch nur einmal auf, könnt aber auch schon an der Uhrzeit liegen wieso ich es nicht verstehe :-).
Jetzt versteh ich endlich die Aufrufliste, wieder was dazu gelernt.
Und danke, dass war wirklich der Fehler
Nur wundert mich das etwas, da das ganze so wie es da steht schon etliche male vorher geklappt hat..
Aber da der TGALoader das ja schon übernimmt dürfte es eigentlich kein Problem sein, die Zeile zu entfernen.Jetzt kann ich endlich wieder weiter machen

-
Hallo,
nochmal ich^^
Ich bin zwar gerade glücklich, dass alles läuft, aber die Anwendung hakt ein klein wenig. ALs ich nachgeschaut habe, hab ich gesehen, dass sie 100% der CPU bei einem 3Ghz P4 schluckt...
Wie kann man denn bei solchen Anwendungen die CPU-Last verringern, denn normal finde ich das nicht, dass sowas kleines so viel CPU schluckt.
-
Doch, ist normal.
Sonst bau threads ein oder setz nen sleep(1) irgendwo hin
-
Cool funktioniert super. Von 100 auf 0 Prozent

Allerdings habe ich öfters gelesen, dass das nicht die "eleganteste" Methode ist. Wird das Programm dann nicht unterschiedlich schnell auf unterschiedlichen Computern, weil die eien andere Zeitauflösung haben?
-
Nein nicht wegen Sleep, da gibst du die Zeit ja in Millisekunden an, nicht in Ticks. Und wenn dann nur um ein paar Millisekunden wegen der Auslastung des Rechners.
Mfg marco