Probleme mit malloc / free (DAMAGE: after Normal block (#142) at 0x00B65A20.)

lunatic82

Da es sich um eine Klasse handelt in der der die Methode implementiert ist, denke ich, dass C+++ das richtige Forum ist.

Zumal das Problem auch mit new und delete auftaucht.

lunatic82 schrieb:

Da es sich um eine Klasse handelt in der der die Methode implementiert ist, denke ich, dass C+++ das richtige Forum ist.

Zumal das Problem auch mit new und delete auftaucht.

Du darfst new , delete (C++ Funktionen) und malloc , free (C Funktionen) nicht mischen!

Schreibe deinen Quellcode um, und beschränke dich auf new und delete .

Registrierter Troll

Hallo,

lunatic82 schrieb:

Da es sich um eine Klasse handelt in der der die Methode implementiert ist, denke ich, dass C+++ das richtige Forum ist.

rein formell hast du wohl recht. Dein Code ist allerdings sehr viel näher an C als an C++ (C++ ist nämlich mehr als C mit class -Keyword), und lässt außerdem jedem C++-Programmierer die Haare zu Berge stehen und schreiend davonlaufen. Es wird auch kaum einer Lust haben, deinen tollen Code für dich zu debuggen.

Zumal das Problem auch mit new und delete auftaucht.

Du meinst natürlich new[] und delete[] , aber wir wollen ja nicht kleinlich sein.

Vielleicht helfen dir diese Links weiter:
http://www.cplusplus.com/reference/string/
http://www.cplusplus.com/reference/iostream/stringstream/

lunatic82

BBBB schrieb:

Du darfst new , delete (C++ Funktionen) und malloc , free (C Funktionen) nicht mischen!

Schreibe deinen Quellcode um, und beschränke dich auf new und delete .

Also, ich sehe in der Methode oben kein new und kein delete. Das war nur ein Beispiel, dass es damit ebenso wenig geht wenn man die Befehle entsprechend ersetzt.

lunatic82 schrieb:

BBBB schrieb:

Du darfst new , delete (C++ Funktionen) und malloc , free (C Funktionen) nicht mischen!

Schreibe deinen Quellcode um, und beschränke dich auf new und delete .

Also, ich sehe in der Methode oben kein new und kein delete. Das war nur ein Beispiel, dass es damit ebenso wenig geht wenn man die Befehle entsprechend ersetzt.

Wie und vorallem wo gibst du den reservierten Speicher wieder frei? Lass mich raten. Du nimmst vermutlich delete?

lunatic82

BBBB schrieb:

Wie und vorallem wo gibst du den reservierten Speicher wieder frei? Lass mich raten. Du nimmst vermutlich delete?

Nö, sondern hier:

void StringTokenizer::flush(int count, char** arr) {
  for(int j=0; j < count && arr[j] != NULL; j++) {
     free(arr[j]);		
     assert(_CrtCheckMemory());
  }

  // Im Debug-Modus kommt die Meldung, dass es sich um eine 
  // invalide Adresse für free handelt.
  if(arr != NULL) {		
    free(arr);		
    assert(_CrtCheckMemory());
  }
}

Und wie ich schon schrieb, er stirbt beim malloc und nicht beim "befreien" des Speichers. Bis dahin kommt er nämlich nicht einmal.

Im übrigen weiß ich, dass man free / malloc nicht mit delete / new mischen kann, weil es unterschiedliche Speicher im System sind.

Was soll eigentlich folgendes bewirken?

while (buf[i] != '\0') {
    if(arr[sc] == NULL) {
      printf("Konnte keinen Speicher reservieren.\n");
      return sg;
  }

i wird ja gar nicht verändert.

Tachyon

Ein Array der Größe N hat einen Index-Range von 0..N-1 . Guck Dir Deinen Code noch mal genau an.
Btw. gibts für sowas (wenns denn unbedingt C sein soll) strtok aus <cstring>

lunatic82

BBBB schrieb:

Was soll eigentlich folgendes bewirken?
while (buf[i] != '\0') {
    if(arr[sc] == NULL) {
      printf("Konnte keinen Speicher reservieren.\n");
      return sg;
  }
i wird ja gar nicht verändert.

Doch wird es... Beim kopieren ist die Klammer } verrutscht. Die beendet, wenn man genau hinschaut die if-Bedingung und nicht die while-Schleife.

lunatic82

Tachyon schrieb:

Ein Array der Größe N hat einen Index-Range von 0..N-1 . Guck Dir Deinen Code noch mal genau an.
Btw. gibts für sowas (wenns denn unbedingt C sein soll) strtok aus <cstring>

Worauf bezieht sich dein Kommentar?

Tachyon

lunatic82 schrieb:

Tachyon schrieb:

Ein Array der Größe N hat einen Index-Range von 0..N-1 . Guck Dir Deinen Code noch mal genau an.
Btw. gibts für sowas (wenns denn unbedingt C sein soll) strtok aus <cstring>

Worauf bezieht sich dein Kommentar?

Guck Dir mal die Abbruchbedingungen Deiner for -Schleifen an.

lunatic82

Tachyon schrieb:

Guck Dir mal die Abbruchbedingungen Deiner for -Schleifen an.

for(i=0; i <= sg; i++) {
  *arr[i] = NULL;
  if(*arr[i] == NULL)
     *arr[i] = (char*) malloc(MAX_CHARS * sizeof(char));
}

Die Schleife ist meines Erachtesn korrekt, denn am Anfang werden die Separatoren gezählt. Ein ensprechender String kann z.B. so aussehen:

UNA+Hallo+Test+möp'

Gezählt werden drei Separatoren, ich benötige in meinem Array aber vier Elemente, um alle Zeichenketten speichern zu können, deswegen i <=sg.

Zum Thema strtok. Strtok funktioniert nicht so ganz einfach für den Anwendungsfall, denn z.B. ist ein ?+ kein Separator.

Tachyon

Dein Array ist aber nicht groß genug für i==sg.

lunatic82

Tachyon schrieb:

Dein Array ist aber nicht groß genug für i==sg.

Versteh ich nicht, denn i <= sg, beinhaltet auch den Fall i==sg.

Im übrigen fliegt der Code schon viel eher (schrieb ich auch) und zwar hier:

// Speicher bereit stellen
if(arr == NULL) {
   arr = (char**)malloc(sg * sizeof(char*));		
   if (arr == NULL) {
      printf("Konnte keinen Speicher reservieren.\n");
      return sg;
   }
}

Und das hat nichts mit einer Schleife zu tun.

Tachyon

lunatic82 schrieb:

if(arr == NULL) {
   arr = (char**)malloc(sg * sizeof(char*));		
   if (arr == NULL) {
      printf("Konnte keinen Speicher reservieren.\n");
      return sg;
   }
}

Und das hat nichts mit einer Schleife zu tun.

Dann machst Du schon verher was kaputt. Das oben stehende sollte gehen.

Nochmal:
Hier...

arr = (char**)malloc(sg * sizeof(char*));

...reserviertst Du für sg Elemente Speicher. Der Index geht von 0..sg-1 .

Hier hingegen...

for(i=0; i <= sg; i++) { ...

...greist Du auf 0..sg zu. Ein Element mit dem Index sg existiert aber nicht.

pumuckl

lunatic82 schrieb:

Tachyon schrieb:

Dein Array ist aber nicht groß genug für i==sg.

Versteh ich nicht, denn i <= sg, beinhaltet auch den Fall i==sg.

Eben drum. Von 0..sg sinds insgesamt sg+1 Schritte, und du reservierst nur Speicher für sg Pointer. Typischer Zaunlattenfehler

Im übrigen fliegt der Code schon viel eher (schrieb ich auch) und zwar hier:
// Speicher bereit stellen
if(arr == NULL) {
   arr = (char**)malloc(sg * sizeof(char*));		
   if (arr == NULL) {
      printf("Konnte keinen Speicher reservieren.\n");
      return sg;
   }
}
Und das hat nichts mit einer Schleife zu tun.

Da gibts zwei mögliche Gründe warums fliegt:

printf() - Unwahrscheinlich, aber ersetz es mal testweise mit cout bzw. cerr, schließlich machst du eh C++ bzw. gibst es mit deiner Klasse zumindest vor.
malloc() - auch unwahrscheinlich. Du könntest es allerdings zum Testen mal nurch ein new char*[sg+1] ersetzen.

Bist du tatsächlich mit dem Debugger durchgesteppt und hast rausgefunden dass es dort fliegt? Eventuell geht auch die Funktion die du im assert() aufrufst in die Hose, wäre zumindest ein idealer Kandidat dafür (heißt CheckMemory und du bekommst Memory check error...)

lunatic82

@Tachyon:
Ja stimmt, jetzt wird mir das auch klar. Manchmal ist man echt blind.

@pumuckl:
Aber selbst, wenn ich die Anmerkung von Tachyon berücksichtige, bricht er mir schon beim ersten malloc oder new, wenn ich die assert-Bedingung drin habe. Wenn ich die entferne, dann geht er bis zum zweiten malloc oder new und dann bricht er dort mit einer Exception ab.

printf ist es definitiv nicht
assert meldet schon korrekt, dass der Heap beschädigt ist, deswegen funktioniert das zweite malloc nicht. Wenn dort i=i ist, dann fliegt er eben an dieser Stelle.

Ich steppe in der Tat mit dem Debugger durch den Quelltext und schaue mir an, was dort passiert. Und es ist mir unerklärlich. split bzw. flush sind auch die einzigen Funktionen, die dynamisch in dem Code Speicher reservieren.

Gibt es noch andere konstruktive Ideen?

Registrierter Troll

lunatic82 schrieb:

Gibt es noch andere konstruktive Ideen?

Gibt es einen Grund dafür, warum du dich mit diesen altertümlichen und fehleranfälligen C-Konstrukten abquälst, statt die Sache sauber mit C++-Strings zu implementieren?

lunatic82

Registrierter Troll schrieb:

Gibt es einen Grund dafür, warum du dich mit diesen altertümlichen und fehleranfälligen C-Konstrukten abquälst, statt die Sache sauber mit C++-Strings zu implementieren?

Weil ich zum sauberen Verarbeiten der Informationen eh wieder alles in einen char** umwandeln muss und aus Gründen der Portabilität käme eh nur std::string und nicht CString in Frage.

Und std::string isst genau so ein Krampf.

Registrierter Troll

lunatic82 schrieb:

Weil ich zum sauberen Verarbeiten der Informationen eh wieder alles in einen char** umwandeln muss und aus Gründen der Portabilität käme eh nur std::string und nicht CString in Frage.

Selbst wenn du nachträglich alles in char-Arrays packen müsstest, was ich ehrlich gesagt für unwahrscheinlich halte, wäre die Suche und das letztendliche Zusammenbauen des Strings eine Sache von ein paar wenigen Zeilen - ohne Buffer overflows und sonstigen Newbie-Krebs.

Wer sagte eigentlich irgendwas von CString?

Und std::string isst genau so ein Krampf.

Du irrst dich gewaltig. Alle deine Probleme wären wie weggezaubert, weil du dich nicht mehr um die Speicherverwaltung kümmern müsstest.