4. Probleme mit dem HEAP

Probleme mit dem HEAP

  • K

    edit:
    PROBLEM gelöst. Lösung in meinem letzten Beitrag. kyp

    Einen wunderschönen Sonntag abend!

    zuerst dachte ich es wäre ein Problem mit Listen, jetzt gibt VS 2005 aber immer Fehler solcher Bauart aus:

    HEAP CORRUPTION DETECTED: before Client block (#-1635531842) at 0x01748610.
    CRT detected that the application wrote to memory before start of heap buffer.
    Client located at 0x01748610 is 112 bytes long.
    Eine Ausnahme (erste Chance) bei 0x00683fe8 in Sonicwaves.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0xf8839149.
    Unbehandelte Ausnahme bei 0x00683fe8 in Sonicwaves.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0xf8839149.

    und

    HEAP[Sonicwaves.exe]: Dedicated (0006) free list element 0174B4F0 is wrong size (055f)
    Windows hat einen Haltepunkt in Sonicwaves.exe ausgelöst.

    Dies kann auf eine Beschädigung des Heaps zurückzuführen sein und weist auf ein Problem in Sonicwaves.exe oder in einer der geladenen DLLs hin.

    Weitere Analyseinformationen finden Sie möglicherweise im Ausgabefenster.

    Was hat das zu bedeuten? Ich hab schon versucht den HEAP zu vergrößern, was anderes fällt mir nicht ein.

    Viele Grüße
    Kyp

    0
  • Mod

    Das steht doch in deisem Satz:

    CRT detected that the application wrote to memory before start of heap buffer.

    Dein Programm hat Speicher überschreiben. Das heißt Du hast Heapspeicher allokiert die Speichergrenze überschrieben. Also z.B. hast Du 100 Bytes allokiert aber 200 Bytes kopiert...

    Also suche Deinen Programmfehler!

    AfxCheckMemory kann Dir dabei helfen!

    0
  • K

    Das wird schwer, denn ich habe keine Ahnung wie ich mehr Speicher schreibe als zu allokieren.
    Kannst du mir ein Beispiel geben, das dazu führt?

    Alles was ich mache sind die Operatoren new und delete zu verwenden, um neue Objekt zu erstellen und wieder zu löschen. Wie kann ich damit den Speicher falsch beschreiben?

    Herzlichen Dank für die Antwort.

    Kyp

    0

  • beispiel:

    dir fehlt ein kopierkonstruktor oder zuweisungsoperator, und du machst kopien von objekten, die zur laufzeit auch speicher allozieren.
    lese zu flacher und tiefer kopie.

    oder du gehst über arrays rüber.

    oder oder oder.. vielleicht gibst du auch referenzen zurück aus funktionen.

    du musst debuggen!

    0
  • K

    hi elise,
    was meinst du mit

    lese zu flacher und tiefer kopie.

    ?

    0
  • U

    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.

    0

  • 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 🙂

    0
  • K

    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?

    0
  • K
     

    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?

    0
  • K

    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?

    0
  • K

    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

    0

  • 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 😉

    0
  • Mod

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

    0

  • ??

    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.

    0

  • 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.

    0
Anmelden zum Antworten