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

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.

lunatic82

Das stimmt natürlich, bei dem nackten C-Code isst es aber etwas weniger Overhead. Ist aber aucch egal, denn es funktioniert ja nun und sieht auch mehr nach C++ aus.

Trotzdem werden wir uns hier langfristig mal einen anderen Compiler zulegen müssen - vor allem wenn es die Mitarbeiter weniger Nerven kostet.

Registrierter Troll

lunatic82 schrieb:

Das stimmt natürlich, bei dem nackten C-Code isst es aber etwas weniger Overhead.

Was zu beweisen wäre. Dafür müsstet du ja erst einmal funktionierenden Code geschrieben haben, um das überhaupt messen zu können. Kaputten Code mit Funktionierendem zu vergleichen ist nicht sinnvoll.

Wenn du mal den "Overhead" misst, den du durch dein Gefrickel erzeugt hast - also die Zeit die unnötigerweise dafür drauf ging, den ursprünglichen Code zu debuggen - dürfte es deinen Arbeitgeber teurer gekommen sein, dich für diese verplemperte Zeit zu bezahlen, als wenn du es gleich Richtig^TM gemacht hättest.

pumuckl

Registrierter Troll schrieb:

Wenn du mal den "Overhead" misst, den du durch dein Gefrickel erzeugt hast - also die Zeit die unnötigerweise dafür drauf ging, den ursprünglichen Code zu debuggen - dürfte es deinen Arbeitgeber teurer gekommen sein, dich für diese verplemperte Zeit zu bezahlen, als wenn du es gleich Richtig^TM gemacht hättest.

Wenn er gut ist, kann er es so argumentieren dass vor allem der bescheuerte VC6 dran schuld ist. Dann wäre es für n guten Zweck verplempert

lunatic82

Registrierter Troll schrieb:

Wenn du mal den "Overhead" misst, den du durch dein Gefrickel erzeugt hast - also die Zeit die unnötigerweise dafür drauf ging, den ursprünglichen Code zu debuggen - dürfte es deinen Arbeitgeber teurer gekommen sein, dich für diese verplemperte Zeit zu bezahlen, als wenn du es gleich Richtig^TM gemacht hättest.

War ganz einfach zu beweisen, indem man den Code komplett unter g++ erstellt bzw. den Intel Compiler nutzt...

Und vertane Arbeitszeit war das auch nicht. Wir mussten uns so mal mit den unterschiedlichen Speicherverwaltungen im Debug- und Release-Mode auseinander setzen, haben gelernt das der VC6.0-Compiler für den Arsch ist und werden nun auf Eclipse, CDT, Intel-Compiler umstellen.

Fehlt nur noch ein gescheiter Debugger. Schön wäre so etwas wie das in XCode integrierte Frontendd für den gdb. Das ist echt praktiscch, hab ich aber für die Windows-Plattform noch nicht gefunden.

Übrigens, gibt es keinen richtigen Weg. Die Methode, die ich gepostet habe, funktioniert schon seit Ewigkeiten auf meinem Mac und ist extra portabel gehalten.

Dein std::string und std::vector bekommst Du ja niemals auf einem Embedded-System an den Start. Die meisten Compiler für diese Systeme kennen nämlich keine Strings.

Registrierter Troll

lunatic82 schrieb:

Übrigens, gibt es keinen richtigen Weg.

In C++ mit malloc und free zu hantieren ist aber garantiert der Falsche^TM.

Die Methode, die ich gepostet habe, funktioniert schon seit Ewigkeiten auf meinem Mac und ist extra portabel gehalten.

Uh, sorry, aber...

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

Dieser Code ist einfach nur kaputt und wenn der jemals irgendwo funktionierte, dann war das pures Glück. Und das ist nicht die Schuld des Compilers, auch wenn du das gerne so hättest.

Dein std::string und std::vector bekommst Du ja niemals auf einem Embedded-System an den Start.

Nochmal sorry, aber WTF? Warum wurde dann überhaupt C++ gewählt, wenn die Plattform noch nicht einmal das Minimum hergibt?

pumuckl

lunatic82 schrieb:

Wir mussten uns so mal mit den unterschiedlichen Speicherverwaltungen im Debug- und Release-Mode auseinander setzen, haben gelernt das der VC6.0-Compiler für den ***** ist und werden nun auf Eclipse, CDT, Intel-Compiler umstellen.

Durchaus positiver Effekt \o/

lunatic82

Registrierter Troll schrieb:

Dieser Code ist einfach nur kaputt und wenn der jemals irgendwo funktionierte, dann war das pures Glück. Und das ist nicht die Schuld des Compilers, auch wenn du das gerne so hättest.
[...]
Nochmal sorry, aber WTF? Warum wurde dann überhaupt C++ gewählt, wenn die Plattform noch nicht einmal das Minimum hergibt?

Ja der Code ist kaputt, aber es kommt drauf an, was der Compiler damit macht. Sind die Optimierungen aus, dann funktioniert es problemlos...

Du kennst den Rest der Software nicht, der in C++ geschrieben ist. Warum sollte ich eine Funktion, die bereitss existiert noch einmal neu schreiben... Da ist nur die Klassendefinition drum gepackt worden.

Registrierter Troll

lunatic82 schrieb:

Ja der Code ist kaputt, aber es kommt drauf an, was der Compiler damit macht. Sind die Optimierungen aus, dann funktioniert es problemlos...

Das kannst du nicht ernst meinen?

Du kennst den Rest der Software nicht, der in C++ geschrieben ist.

Wenn ich dich richtig verstehe, war die Software vorher in C geschrieben, ja? Und die Plattform unterstützt C++ bestenfalls sehr rudimentär, richtig? UND Visual C++ 6.0 unterstützt diese Plattform? Und der Intel-Compiler ebenfalls?

Dann wäre es interessant zu wissen, welche Plattform das sein soll. Und (nochmal), warum zum Geier die Software nun in C++ geschrieben wird, wenn die Plattform das überhaupt nicht hergibt?

Warum sollte ich eine Funktion, die bereitss existiert noch einmal neu schreiben...

Da fällt mir ein verdammt guter Grund ein: weil die existierende Funktion kaputt ist.

Da ist nur die Klassendefinition drum gepackt worden.

Ja, ich seh schon. Hoffentlich muss ich niemals bei euch arbeiten.

Tachyon

lunatic82 schrieb:

Übrigens, gibt es keinen richtigen Weg. Die Methode, die ich gepostet habe, funktioniert schon seit Ewigkeiten auf meinem Mac und ist extra portabel gehalten.

Da in der Methode ein grober Fehler war, kann ich mir das kaum vorstellen. Wenn es tatsächlich doch ging, dann war das pures Glück.

lunatic82

Registrierter Troll schrieb:

lunatic82 schrieb:

Ja der Code ist kaputt, aber es kommt drauf an, was der Compiler damit macht. Sind die Optimierungen aus, dann funktioniert es problemlos...

Das kannst du nicht ernst meinen?

Doch kann ich. Ich seh schon, Du kennst dich gut mit optimierenden und korrigierenden Compilern aus und weisst auch wie unterschiedlich Speicher reserviert wird. Der VC6 kann das alles nicht, dass ist mir nun auch klar. Im übrigen gibt der Intel-Compiler für den geposteten Code in der Tat eine Bounding-Warnung aus, weil der inzwischen (wie man es von Smalltalk und Java kennt) eine saubere Quellcode-Analyse durchführt.

Registrierter Troll schrieb:

Wenn ich dich richtig verstehe, war die Software vorher in C geschrieben, ja? Und die Plattform unterstützt C++ bestenfalls sehr rudimentär, richtig? UND Visual C++ 6.0 unterstützt diese Plattform? Und der Intel-Compiler ebenfalls?

Dann wäre es interessant zu wissen, welche Plattform das sein soll. Und (nochmal), warum zum Geier die Software nun in C++ geschrieben wird, wenn die Plattform das überhaupt nicht hergibt?

Du kannst nicht richtig lesen. Die Funktion/Methode die ich geschrieben habe, kann auch auf Embedded-Systemen genutzt werden. Nur um die geht es hier. Die wurde wiederum nun in eine Software integriert die in C++ geschrieben ist. Normalerweise sollte so ein Codemisch kompatibler Sprachen möglich sein und ist er ja auch...

Registrierter Troll schrieb:

lunatic82 schrieb:

Da ist nur die Klassendefinition drum gepackt worden.

Ja, ich seh schon. Hoffentlich muss ich niemals bei euch arbeiten.

Stimmt besser ist das, wenn Du das Rad immer neu erfinden würdest. Für mich ist das Thema nun an dieser Stelle erledigt, weil nun alles zufriedenstellend läuft. Im übrigen machen deine bevorzugten Strings und Vektoren nix anderes als die Quelltextpassage und das sogar noch viel häufiger, wenn man sich das mal im Debugger ansieht. Es macht die Arbeit nur für die ganz Faulen einfacher.

lunatic82

Tachyon schrieb:

lunatic82 schrieb:

Übrigens, gibt es keinen richtigen Weg. Die Methode, die ich gepostet habe, funktioniert schon seit Ewigkeiten auf meinem Mac und ist extra portabel gehalten.

Da in der Methode ein grober Fehler war, kann ich mir das kaum vorstellen. Wenn es tatsächlich doch ging, dann war das pures Glück.

Der sich, wie ich nun gesehen habe, erst bei der Anpassung auf der Arbeit eingeschlichen hat. Zu Hause gibt es keinen Vergleich i <= sg sondern nur i < sg. So kann das eben gehen, wenn man zu sehr rumfummelt, um den Fehler zu finden...

Registrierter Troll

lunatic82 schrieb:

Doch kann ich.

Der VC6 kann das alles nicht, dass ist mir nun auch klar.

Das ist haarsträubender Unsinn. Und ganz schlechter Stil, den Compiler für die eigene Unfähigkeit verantwortlich zu machen.

Du kannst nicht richtig lesen.

Entweder das, oder du kannst dich nicht richtig ausdrücken. Oder, was wahrscheinlicher ist, du weißt einfach nicht so recht wie du aus der peinlichen Nummer wieder rauskommen sollst, ohne zugeben zu müssen, dass du eigentlich keine Ahnung hast. Und setzt deshalb auf eine Verwirrungstaktik - eine Variation der berühmten Chewbacca-Verteidigung.

Registrierter Troll schrieb:

Ja, ich seh schon. Hoffentlich muss ich niemals bei euch arbeiten.

Stimmt besser ist das, wenn Du das Rad immer neu erfinden würdest.

Hoffentlich bleibt dir die Ironie in dieser Aussage nicht auf ewig verborgen.