Problem beim Debuggen
-
Hallo,
also ich muss(soll) ein programm von nem kollegen mal überprüfen, da es einige exceptions bringt!
Hab schonmal nen schock bekommen als ich mir nur den code angeschaut habe: unkommentiert, durcheinander, keine klaren regeln, teilweise wirre variablennamen!
ok nach abklärung mit ihm ist mir der code soweit! klar.
Zum programm:
es ließt VDA Dateien (haben bestimmtest schema) aus und zeigt die daten in entsprechenden feldern an
Zu den fehlern:
Das programm stürzt sporadisch beim öffnen der dateien ab (keine speziell lange oder kurze datei)
manchmal nach dem 2ten öffnen, manchmal erst nach dem 10 mal
auch lässt sich plötzlich eine datei öffnen die vorher absturz verursacht hat usw... .und beim beenden bekommt er oft eine exception (ungültiger Zeiger oder Zeigeroperation)
diese lässt mich schon eben auf zeigerprobleme schließen, nur hab ich soweit da noch keinen durchblick im programm, da er auch nur eine einzige selbstdefinierte zeigervariable benutzt!
Also hab ich mich erstmal mit dem debugger rangesetzt, mir nen haltepunkt beim öffnen gesetzt und alle wichtigen variablen überwacht (2 integer, 1 int* , 1 StringList usw)
solang er die dateien öffnet stehen korrekte daten in den variablen, beim absturz sagt mir das überwachungsfenster bei jeder variablen, das sie nicht vorhanden wäre?!
Wie muss ich das interpretieren?
Ich will euch jetzt erstmal nicht den code um die ohren hauen, aber wenn ihr ihn wollt, sagt beischeid!
-
Wenn du schon mit dem Debugger dransitzt, kannst du bestimmt auch sagen, an welcher Stelle das Programm abstürzt.
Ist es immer die selbe?
Und wenn du die Stelle hast, an der etwas schief läuft, wäre etwas Quellcode nicht schlecht.
-
beim absturz sagt mir das überwachungsfenster bei jeder variablen, das sie nicht vorhanden wäre?!
Bei einem Absturz kann der Debugger auch nicht mehr in derart helfen, dass er noch Variablen zuordnen könnte. Dann ist nur noch das CPU Fenster mit dem gerade fälligen Assemblerbefehl verfügbar.
Hier musst du versuchen die Stelle zu finden, die wo und wann den Absturz verursacht.
Dabei könnte helfen
- debuggen mit Durchlaufzählern
- debuggen in Abhängigkeiten von Variableninhalten
- vielleicht auch mal CodeGuard ranlassenWichtig wäre auch das Programm im "Debug-Modus" zu haben -> keine Optimierungen usw.
-
ok, also ich glaube der fehler muss hier auftreten:
int __fastcall TForm1::FillIndexMap() { delete[] startnext; startnext=0; debuglog<<"12_Einstieg in Funktion\t <FillIndexMap()> in Zeile: \t"<<__LINE__<<endl; int counter = 0; for(int i=0;i<VDAList->Count;++i) { if(VDAList->Strings[i].SubString(0,3)=="512") counter++; } //ShowMessage("Indexmap gefüllt mit Werten: " +IntToStr(counter)); startnext = new int[counter]; debuglog<<"12_1FillIndexMap()\t Status in Zeile: "<<__LINE__<<" [startnext] hat "<<counter<<" Felder"<<endl; int indexer=0; for(int i=0;i<VDAList->Count;++i) { if(VDAList->Strings[i].SubString(0,3)=="512") { startnext[indexer]=i; indexer++; } if(VDAList->Strings[i].SubString(0,3)=="519") { startnext[indexer]=i; indexer++; } } debuglog<<"12_Ausstieg aus Funktion\t <FillIndexMap()> in Zeile: \t"<<__LINE__<<"\t mit Wert(indexer): "<<indexer<<endl; return indexer-1; }diese funktion sucht nach dem vorkommen des schlüssels 512 (der einen neuen satz beginnt), legt ein array dynamsich mit der größe der anzahl an!
Also startnext[2] wenn eben 2mal 512 gefunden wurde
startnext[10] wenn 512 10mal gefunden wurde usw...und es wird die position des gefunden 512 an die positionen geschrieben (indexer)!
jedoch ist indexer meist genausogroß wie counter, was ja bedeutet das wenn counter 2, und indexer 2, das er in startnext[2] schreibt, obwohl es garnicht soweit geht!
Ich vermute, es liegt wohl daran, weil er den counter nur mit den gefunden 512 initialisiert, aber die 519(Dateiende) die er unten noch reinschreibt, vergessen hat?!
ist das increment dex indexers überhaupt richtig, nachdem schon ein wert in startnext geschrieben wurde?
Ich sehe den wald vor lauter bäumen nicht mehr!
-
aber die 519(Dateiende) die er unten noch reinschreibt, vergessen hat
seh ich auch so.
Tip: Mit CodeGuard findet man sowas ganz gut.