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

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.

pumuckl

Da _CrtCheckMemory kein Standard-C++ ist kann ich jetzt nur wilde Vermutungen anstellen was es macht und warum es vielleicht Probleme hat:

Nach der Ausgabe sind da 4 Werte im Speicher, die alle direkt hintereinander sitzen und alle den Wert 0 haben, aber 0xFD erwartet wird. Ich hab mal nach CrtCheckMemory gegooglet und dieses Wunderwerk an gebabelfischtem Ex-Englisch gefunden: http://support.microsoft.com/kb/833608/de
Man kann dort mit etwas Mühe herausinterpretieren, dass CrtCheckMemory bei neu allokiertem Memory eine 0xFDFDFDFD-Belegung erwartet, malloc diese aber nur liefert wenn man vorher _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF); aufruft (musst also das alloc_mem_df-Flag mit deinen anderen Flags verodern).

lunatic82

Ich habe es dann doch mit malloc und free aufgegeben, weil der VC6.0-Compiler grundsätzlich ein Problem damit hat.

Ich bin dann doch auf die Variante mit Strings und Vektoren umgestiegen - auch wenn das bedeutet, dass etwas Speicher verschwendet wird.

pumuckl

lunatic82 schrieb:

VC6.0-Compiler

Uh. Hättest du das Ding schon früher erwähnt dann wär der Thread nicht so lang geworden. Der VC6 hat mit vielen Dingen ein Problem und ist ein ziemlicher Krampf. Wenn wir das gewusst hätten dann hättest du 5 Posts á la "besorg dir einen aktuellen, ordentlichen Compiler" bekommen und keine Hilfsversuche - die sind bei VC6 nämlich häufig allzu fruchtlos.

lunatic82

Im Unternehmen verwenden wir den leider und deswegen bin ich darauf angewiesen

Privat würde ich den nie benutzen...

Simon2

lunatic82 schrieb:

...Ich bin dann doch auf die Variante mit Strings und Vektoren umgestiegen - auch wenn das bedeutet, dass etwas Speicher verschwendet wird.

Keine Sorge: Der wird nicht im Hinterhof verbrannt. Den bekommst Du wieder und dort werden auch nicht die Lottozahlen vom letzten Jahr eingetragen, sondern Informationen, die zur Speicherverwaltung und/oder zur Performanceoptimierung nötig sind - sprich: Die Du höchstwahrscheindlich ebenfalls irgendwo abgelegt hättest.

Gruß,

Simon2.