ich habe mir eine kleine Klasse geschrieben, die einen String splitten kann und ein dynamisch allokiertes Array zurück gibt. Der Aufruf der Methode in der Klasse kann beispielsweise so aussehen:

char** composite = NULL;
int y = StringTokenizer::split('+', '?', buf, composite);

In der eigentlichen Methode kommt es nun zu einem Problem, wenn ich den dynamischen Speicher allokiere (malloc -> äußere Felddefinition). Der Debugger meldet mir dann:

`

memory check error at 0x00B65AE4 = 0x00, should be 0xFD.

memory check error at 0x00B65AE5 = 0x00, should be 0xFD.

memory check error at 0x00B65AE6 = 0x00, should be 0xFD.

memory check error at 0x00B65AE7 = 0x00, should be 0xFD.

DAMAGE: after Normal block (#142) at 0x00B65A20.

Normal located at 0x00B65A20 is 196 bytes long.

Detected memory leaks!

`

Die entsprechende Methode sieht wie folgt aus:

int StringTokenizer::split(char delim, char cast, char* buf, char** &arr) {
  unsigned int i=0, j=0;		// Hauptzähler für den Array-Aufbau
  unsigned int sg=0;		// Segment-Zähler, Anzahl der Elemente im Array
  arr = NULL;

  int tmpFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG );
  tmpFlag |= _CRTDBG_LEAK_CHECK_DF;
  _CrtSetDbgFlag( tmpFlag );

  if (buf == NULL) return sg;

  // Anzahl der Separatoren zählen
  for(i=0; buf[i] != '\0' || i < strlen(buf); i++) {
     if (buf[i] != cast && buf[i+1] == delim) ++sg;
  }

  // kein Segment gefunden
  if (sg == 0) return sg;

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

  // Speicher mit Inhalten füllen	
  for(i=0; i <= sg; i++) {
    arr[i] = NULL;
    if(arr[i] == NULL)
      arr[i] = (char*) malloc(MAX_CHARS * sizeof(char));
  }
  assert(_CrtCheckMemory());

  int sc=0; i=0;

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

  arr[sc][j++] = buf[i]; 

  if (i > 1 && buf[i] == delim && buf[i-1] != cast) {			
    arr[sc][--j] = '\0';	// Durch Eintrag wird das Split-Symbol gelöscht
    arr[sc] = (char*)realloc((char*)arr[sc], (j+1) * sizeof(char));
    assert(_CrtCheckMemory());
    sc++;	// Neues Segment	
    j=0;	// Zähler zurücksetzen						
  }
		             i++;												
  } 

  // Nach dem Sprung aus der Schleife muss das letzte Element auch 
  // noch einmal neu berechnet werden
  arr[sc][j] = '\0';
  arr[sc] = (char*)realloc((char*)arr[sc], (j+1) * sizeof(char));	
  assert(_CrtCheckMemory());

  return sg+1;	
}

Kann mir jemand sagen, was ich hier falsch mache?

Grüße
Björn

lunatic82 schrieb:

Kann mir jemand sagen, was ich hier falsch mache?

Du bist im C++-Forum. Dein Code ist aber C.

Edit: na gut, eher sowas ähnliches wie C.

Zumal das Problem auch mit new und delete auftaucht.

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 .

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/

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.

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?

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.

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

i wird ja gar nicht verändert.

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.

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

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.

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.

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.

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:

1. 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.
2. 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...)

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

1. printf ist es definitiv nicht
2. 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?

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?

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.

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.

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

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

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.

Privat würde ich den nie benutzen...