Aufgabe 3 Implementierung

[Airhardt]

---

Das hier könnte dich interessieren: http://duma.sourceforge.net/

[tempus_maximus]

---

Vielen Dank fuer den Link, schaut sehr sehr nuetzlich aus, werd mir mal den sourcecode anschaun und schaun wie sie des alles erreichen von wegen buffer-overflows erkennen, etc, wuerde mich interessieren. Hab im Moment fuer den Zweck ne bib von meinem Vater den des ganze auch genervt hat. Werds mir anschaun, danke.

[bulsa]

---

Heap Consistency Checking (The GNU C Library)

Another possibility to check for and guard against bugs in the use of malloc, realloc and free is to set the environment variable MALLOC_CHECK_. When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple errors, such as double calls of free with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be protected against, however, and memory leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort is called immediately. This can be useful because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down.

[rudis]

---

@tempus maximus

Aber zu den Abstuerzen: glaub mir, ich waere der erste der vor Dankbarkeit auf die Knie sinkt, wenn sich malloc so verhalten wuerde. Leider tut es das aber ja nicht. Es duempelt in diesem undefinierten Zustand rum(um die Manpages zu zitieren), bis es im best-case bei der Speicherfreigabe abstuerzt, und leider aber im worst-case ja 3000 code-zeilen weiter bei etwas was nichts mit unserem Problem zu tun hat. Wenn malloc, free, etc, in dem Moment wo eine solche Verletzung passiert in einen Zustand versetzt wuerden wo dann der naechste Aufruf abstuerzt waere das toll, da man dann genau weiss wo der fehler zu suchen ist.

Klar, zwischen Aufrufen von [m]malloc()[/m] oder [m]free()[/m] wird nichts geprüft, da läuft ja auch anderer Code und nicht die Freispeicherverwaltung. Aber sobald ein Fehler entdeckt wird, eben z.B. beim [m]free()[/m] wird abgebrochen. Früher geht es nicht, wenn es effizient sein soll.

@tempus maximus

Das Problem ist aber ja dass alles was nicht MAGIC ist als Pointer interpretiert wird, da wir das ganze im next-Feld speichern.

Es stimmt schon, dass der MAGIC-Schutz nicht perfekt ist. Aber es reicht zumindest bei schon allokierten Blöcken. Freie Blöcke müsste man noch extra prüfen, zum Beispiel durch eine Plausibilitätsprüfung der Pointer (sind sie innerhalb von [m]memory[/m]); das sollte die meisten unabsichtlichen Fehler abfangen.

@tempus maximus

Ausserdem hat die Implementierung meiner Meinung nach eben kein Wissen darueber welchen Speicher sie vergeben hat. Alles was sie kann ist dir im Nachhinein sagen ob sie den Speicher den du ihr gibst vergeben hat, aber nicht welchen sonst noch, wieviel, etc.

Das Wissen steckt in der Freispeicherliste - die muss man dazu durchlaufen. Falls sie beschädigt wird, kommt man an die Informationen natürlich nicht mehr ran.

@tempus maximus

Wie ja Airhardt schon gesagt ist von der Effizienz her meine Implementierung auch nicht besser, und in manchen faellen auch schlechter, aber sie erscheint mir persoenlich einfach als logischer (naheliegender). Zaehlt das? Ich wuerde sie natuerlich dann auch dokumentieren da ich die Standard-route nicht nehme.

Ich meinte mit Effizienz vor allem sowas wie Verschmelzung oder effizientere Verwaltung der Freispeicher"liste".

Die Implementierung mit der statischen Tabelle scheint mir nicht so sinnvoll, weil du damit eine feste Anzahl von Speicheranforderungen festlegst. Das sollte nicht der Fall sein. Und wo kopierst du du deine Tabelle hin wenn du mehr Platz brauchst? Du hast ja kein [m]malloc()[/m] zur Verfügung; und in [m]memory[/m] gibt es vielleicht nicht mehr genug zusammenhängenden Speicher.

[neverpanic]

---

Das hier könnte auch relevant sein:

• http://clang.llvm.org/docs/AddressSanitizer.html
• http://clang.llvm.org/docs/MemorySanitizer.html
  Ansonsten bleibt noch der Ansatz, den z.B. valgrind nutzt: Per LD_PRELOAD zum Debuggen die malloc-Implementierung austauschen. Es steht dir ja frei beliebige malloc-Implementierungen zum Testen zu benutzen und es gibt eine ganze Reihe von solchen Implementierungen, sicher auch ein paar, die robuster gegenüber Fehlern sind.