Probleme mit dem HEAP

kyp

hi elise,
was meinst du mit

lese zu flacher und tiefer kopie.

?

Unix-Tom

Was denkst du was wir in so einem Fall machen.
Wir werfen den Debugger an und schauen wo es im Code ein Problem gibt.
Alles andere ist in eine Glaskugel schauen und vorhersagen machen. Da wir aber Softwareentwickler und keine Hexer/Hexen sind haben wir keine Glaskugel.
Dafür haben wir eine Debugger.

elise

schau in deinem buch nach kopierkonstruktor, schmöckere hier ein wenig
http://fara.cs.uni-potsdam.de/~kaufmann/?page=GenCppFaqs&faq=BigThree#Answ

und und und

kyp

Wir werfen den Debugger an und schauen wo es im Code ein Problem gibt.

Das mache ich auch, Schritt für Schritt. Nur ich kann mir nicht vorstellen wo das Problem liegt. In meiner Glaskugel sehe ich nur Nebel.
Eine offensichtliche Beschädigung tritt während einer Funktion auf, die nichts anderes macht, als Rechenoperationen auszuführen und einen Pointer auszulesen.

Und sie hat rein gar nichts mit dem beschädigten Objekt zu tun. Ich weiß einfach nicht mehr weiter und suche daher nach Ideen.

Für jeden Hinweis, wo nach lesen etc. wäre ich dankbar.
Lese gerade in dem Link von Elise nach.

Die Konstruktoren meiner Objekte scheinen alle in Ordnung zu sein.
Der Fehler tritt immer in Verbindung mit einer Liste vom Typ CTypedPtrList auf, die in einigen meiner Objekte Verwendung findet. Muss ich da eventuell etwas beachten?

kyp

double	Point::SET_X_PLACEHOLDER(double angle)
{
	x_ph = GET_X()*cos(angle) - GET_Y()*sin(angle);	
        ASSERT(AfxCheckMemory()); //bewirkt einen Fehler.
	return x_ph;
}

Nach dieser Funktion schlägt

ASSERT(AfxCheckMemory());

Alarm.

Was mache ich denn da großes?

Deklarationen fon GET_X() und GET_Y():

inline double	GET_X(void)							const	{return coor_x;}		
	inline double	GET_Y(void)							const	{return coor_y;}

Hilft euch das weiter?

kyp

Was heißt das wenn zur Debugzeit das hier ausgegeben wird für eine Variable:
(*pPoint).coor_x = 4.244817248628e-313#DEN

insbesondere das #DEN?

kyp

Meine letzte Frage ist zwar noch offen und ich würde mich immer noch über eine Antwort freuen, aber mein Problem habe ich jetzt im Griff dank Debugging Mechanismen.

Kurze Erklärung was ich gemacht habe:

1. einen neuen Header mit dem beispielhaften Namen "Debug_Info.h" erstellt.
2. Folgenden Code dort eingetragen:

#pragma once

#ifdef _DEBUG //ist nur im Debugmodus definiert, in der Release version nicht mehr

#define	CHECK_HEAP

#endif

3. in meinen eigentlichen Code in den verschiedenen .cpp Dateien folgendes eingefügt:

#include "Debug_Info.h"

und über den Code verstreut folgenden Dreizeiler:

#ifdef CHECK_HEAP
ASSERT(AfxCheckMemory()); //wird nur ausgeführt, wenn CHECK_HEAP definiert ist
#endif

4. diese Funktion

ASSERT(AfxCheckMemory());

gibt immer dann einen Fehler aus, wenn irgendwo ausserhalb des Programm Heaps etwas geschrieben wird. So konnte ich den Fehler eingrenzen und mir zusammenreimen, was es ausgelöst hat. Fehlerverursacher war ein

Pointer, der auf ein Objekt verwiesen hat, in dem ein anderer Pointer steht, dessen Objekt mit dem Operator

delete

zerstört wurde.
Immer dann, wenn ich dem letztgenannten Pointer eine Anweisung gab, kam es zu Veränderungen an ungewünschter Stelle, die die Funktion AfxCheckMemory() bemerkt hat.

Das Hilft den Cracks wahrscheinlich nicht, aber vielleicht spart es anderen noobs ne Menge Zeit. Bei mir wären es zwei Tage gewesen

Daher ist meine Bitte - wenn es angebracht erscheint - diesen Beitrag in die FAQ zu stellen.

Gruß
Kyp

elise

kyp schrieb:

Pointer, der auf ein Objekt verwiesen hat, in dem ein anderer Pointer steht, dessen Objekt mit dem Operator
delete
zerstört wurde.
Immer dann, wenn ich dem letztgenannten Pointer eine Anweisung gab, kam es zu Veränderungen an ungewünschter Stelle, die die Funktion AfxCheckMemory() bemerkt hat.

... und genau das weist auf fehlenden kopierkonstruktor und zuweisungsoperator hin.
bitte lern das nochmal nach und überprüfe dein programm daraufhin, denn nur das delete auskommentieren ist auf keinen fall eine lösung.
wenn es dieses ist, zeigen zwei zeiger auf die gleiche variable.. und es werden später schöne laufzeitfehler hageln.

ps: lieber einen hinweis auf die regel der großen drei in die faq

Martin Richter

Warum soll ein fehlender Kopier-Konstruktor soetwas auslösen?
Ich vermute eher, hier wird ein Zeiger mehrfach gelöscht!

elise

??

wenn ein objekt zur laufzeit auf dem freispeicher (zum bleistift im konstruktor über einen zeiger) alloziert und dann, bevor das objekt selbst zerstört wird, der destruktor den freispeicher wieder freigibt, und du eine zuweisung machst a la:

Objekt o;
Objekt x=o;

wirst du ein problem haben.

mag sein, dies ist ein anderes problem, als das, das der junge mann hatte.. aber war ja auch nur als beispiel gedacht.

ps: man kann keinen zeiger "löschen", delete gibt die stelle, auf die der zeiger zeigt, frei. und übrigens ist das hier genau so ein problem, nämlich, dass dann zweimal im destruktor die gleiche stelle versucht wird freizugeben.

elise

ach ja, im übrigen ist dieses ja leicht zu prüfen, indem man einfach mal kopierkonstruktor und zuweisungsoperator privat setzt.. läuft es dann, ist das problem woanders zu suchen, da keine kopie eines objektes (wie oben beschrieben, ein objekt mit zeiger und zur laufzeit noch vom heap alloziert) erstellt wird.