Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » Fehler bei Speichereservierung

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 <
000
08.09.2008, 15:27 Uhr
~UweM
Gast


Ich habe ein Problem und sitze schon seit Tagen daran und finde einfach keine Lösung. Beim Debuggen des Code (s.u.) ist beim Erreichen der Punkte test1 = 1.
TTreeNode ist eine Klasse des C++Builders , ist für das Thema aber, glaube ich, uninteressant. Ich vermute mal, durch die Definitionen der Zeiger wird test1 an einer Speicherstelle definiert, die irgendwie schon belegt ist. Aber was kann das sein und wieso wird es nicht einfach überschrieben? Auf was muss ich im vorherigen Quellcode achten?
Schüttel ich den Code etwas durcheinander, so dass test1 eine andere Speicherzelle belegt, dann bleibt test1 = 0.


C++:
int TForm1::Beispiel(int k)
{
    int *m;
    int i=1,test1=0,test2=0,vgl;
    int *n = new int[1];
    TTreeNode *Node,*NodeN;
             ......
}




Vielen Dank, Uwe
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
08.09.2008, 16:01 Uhr
Guybrush Threepwood
Gefürchteter Pirat
(Operator)


Du könntest aus

C++:
int *n = new int[1];


folgendes machen

C++:
int *n = new int;


bzw einfach nur int n wenn es nicht aus irgendwelchen Gründen auf dem Heap liegen soll. Aber einen Fehler enthält das Codestück da nicht. Es passiert ja auch nicht viel.

Das Phänomän welches du beschreibst kann eigentlich nur dadurch passieren das du dir deinen Speicher schon an anderer Stelle zerstört hast...
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
08.09.2008, 21:34 Uhr
ao

(Operator)


Hm, gibts denn auch ein Problem mit dem Programmlauf? Es könnte nämlich sein, dass der Debugger dich irreführt, weil du Optimierungen eingeschaltet hast. Dann gibts keine 1:1-Entsprechung mehr zwischen Sourcecode und ausgeführten Statements, und auch nicht zwischen den vereinbarten Variablen und den tatsächlich existierenden Objekten, und das kann in der Debugger-Ansicht dazu führen, dass Variablen seltsame Werte haben oder überraschend den Wert wechseln.

Guck mal nach, ob du ein Debug-Build oder ein Release-Build untersuchst.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
09.09.2008, 15:00 Uhr
~UweM
Gast


Ich arbeite im Debug-Modus und vergleiche die Variable später auch noch. Also daran kann es nicht liegen.
Ich habe auch schon alles Mögliche auskommentiert um irgendwie dem Fehler auf die Schliche zu kommen. Dabei habe ich was Verblüffendes herausgefunden: Beginne ich mit dem Schritt-für-Schritt-Debuggen in der Kopfzeile der Funktion bleibt test1 = 0, beginne ich zwei Zeilen später verändert sich test1 zu 1. Ich stehe damit vor einem völligen Rätsel.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
09.09.2008, 15:38 Uhr
ao

(Operator)


Überprüf nochmal die Optimizer-Einstellungen. Zum Debuggen sollten alle Optimierungen ausgeschaltet sein, sonst kann man echte Überraschungen erleben.

Und nochmal die Frage: Läuft das Programm richtig? Vergiss mal für einen Moment den Debugger. Hat die Variable, wenn sie vom Programm ausgewertet wird, einen falschen Wert?
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
005
09.09.2008, 16:55 Uhr
~UweM
Gast


Ob das Programm richtig läuft, versuche ich ja gerade herauszufinden. In dieser Funktion hat es gekracht und ich bin mit dem Debugger rein.
Aber mein neuster Clou ist: Ich habe danach den Code eingefügt if (test1==0) {..} und if (test1==1) {..}. Bei Schritt-fürSchritt-Debuggen geht er in den test1==1 Zweig. Mit Breakpunkten entscheidet er sich für test1==0. Das nenn ich mal Fuzzy-Logik.
Ich schiebe es jetzt einfach mal auf den Debugger und hoffe das mein Code richtig ist.

Vielen Dank für eure Mühen
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
006
09.09.2008, 22:35 Uhr
ao

(Operator)


Wenns kracht, dann ist da irgendwo ein echter Fehler und kein Debugger-Murks.

Ist das Programm nebenläufig, d.h. hat es mehrere Threads? Könnte sein, dass ein anderer Thread den Speicher kaputtschreibt.

Oder zeig mal den Rest von TForm1::Beispiel.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
007
10.09.2008, 08:17 Uhr
~UweM
Gast


Nein, während des Debuggens war kein Fehler im restlichen Programm. Ich hatte alles auskommentiert. Im Prinzip stand nur noch das da:


C++:
int TForm1::Beispiel(int k)
{
    int *m;
    int i=1,test1=0,test2=0,vgl;
    int *n = new int[1];
    TTreeNode *Node,*NodeN;
    String txt="";
    if (test1==0) {
             txt = "richtrig";
    test1 = 32;
    } else {
     if (test1==1) {
         txt = "Müll";
                  test1 = 34;
    }
    if (test1==2) {
        txt = "noch mehr Müll";
        test1 = 75;
             }
   }
}




Mehrere Threads hatte ich selber im Programm nicht angelegt. Ich hatte noch versucht, die Funktion als letzte Anweisung im Konstrukor der Form aufzurufen- ohne Probleme. Über ein TButton auf der Form -ohne Probleme. Von mehereren Stellen eines TMainMenu - mit Probleme. Der Debugger springt nach dem Konstruktor der Form in die unit System die in Assembler und in Delphi geschrieben ist und allokiert munter Speicher. Aber da versteh ich nur Bahnhof.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
008
12.09.2008, 09:54 Uhr
xXx
Devil


Hmm. Guck dir mal das "else if" an, wie das geht. Und switch-case auch mal Hm in deinem Beispiel solltest du mal den Speicher wieder freigeben am Ende ... aber sonst ist in dem Teil eigtl. kein Fehler ersichtlich.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 <     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: