|
Anzeige
|
Memory Leaks
Gast
#449235
Hallo, ich programmiere einen MC in C. Das Programm enthält viele dynamisch erzeugte Strukturen, die ich auch alle wieder mit free() freigebe. Nun würde ich trotzdem gerne wissen ob im Speicher irgendwelche memory leaks entstanden sind. Gibt es eine Möglichkeit das harauszufinden? Sprich eine C-Funktion oder Ähnliches die solche leaks erkennt. Vielen Dank schon mal. Gruss Nein, gibt es nicht. Zumindest nicht in Standard-C. Allerdings kann man sich sowas selber bauen: Jeder malloc wird über eine Zwischenfunktion geführt, die mitprotokolliert, welcher Speicherbereich mit wievielen Bytes belegt wurde. Die Umkehrung dann in einem selbst geschriebenen free(). Aus dem Protokoll wird die Freigabe wieder herausgestrichen. Am Ende darf nichts mehr im Protokoll enthalten sein. Ist ne nette Übung. Nicht weiter schwer. Das Hauptproblem ist die Speicherverwaltung für das Protokoll. Wenn du ungefähr weist, wieviele Allokierung im Maximum gleichzeitig zu erwarten sind, kannst du das ganz einfach als statisches Array dimensionieren. Für den allgemeienen Fall müsste man das Protokoll selbst wieder dynamisch verwalten (Array in Blöcken anlegen).
Gast
#449309
Zuverlässige Embedded Systems und dynamische Speicherverwaltung passen nicht sonderlich gut zusammen. Kannst mal nach debug_malloc googlen. Gängige Technik ist, im Debug-Fall dem allozierten Speicher den Inhalt von _FILE__ und __LINE_ mitzugeben. Wenn das allerdings, wie oft, bloss eine eigene aufgesetzte Allokatorfunktion ist, bringt das nichts. Ausserdem braucht das reichlich mehr Platz.
Gast
#449317
Man kann der Software nicht immer trauen. Besser du schickst den MC nach Programmende in einen Halt-Zustand, der sämtliche RAM-Leitungen in einen Tristate versetzt. Nun kannst du mit einer einfachen Schaltung (CPLD oder einfacher Zähler) sicherstellen, dass alle RAM-Zellen auf 0x0000 zurückgesetzt sind. Es bleibt die Möglichkeit, dass noch Speicherbereiche alloziert sind, die aber auf 0 gesetzt sind. Das macht jedoch nichts, da die Nullen auch bei Mehrfachallozierung nicht schaden. @Hans Wer oder was sollte deiner Meinung nach die RAM-Zellen auf 0 setzen?
Gast
#449343
also erst mal danke für die antworten. @hans an der HW kann ich leider nichts rumbasteln, das sollte schon möglichst in der software passieren @kh die idee mit den eigenen malloc funktion ist net schlecht. werdmich mal daran versuchen gruss
Gast
#449367
@Karl heinz Buchegger er schrieb, dass er seine Strukturen mit free() wieder freigibt.
Gast
#449381
>Das Programm enthält viele dynamisch erzeugte Strukturen ...
Genau das ist der Fehler.
So'n Teufelszeug braucht man nicht bei "embedded" Programmierung auif
uP.
Das ist was für PC's mit Gigabyte Speicher und MMU und sonstnochwas.
Man verwendet nur statische Arrays oder "auto" Variablen (Stack).
Keinen "Heap".
Wenn die 1 kByte Ram nicht reichen, kauft man eben einen etwas größeren
uP mit 4 oder 16 KByte.
> er schrieb, dass er seine Strukturen mit free() wieder freigibt.
Und?
free() setzt den Speicher, den es freigibt nicht auf 0.
Gast
#449410
@ ingeniör: Was für einen uC verwendest du? Wie gross ist der RAM? Welche IDE(Compiler)? Was für eine Anwendung?
Gast
#449412
@ ingeniör: Manche Debugger müssten das können.
Gast
#449414
> Und? > free() setzt den Speicher, den es freigibt nicht auf 0. In manchen Systemen schon.
Gast
#449424
@sepp ich verwende den XC161 von infineon mit 2k ram. als compiler keil uVision3. die anwendung braucht strukturen da eine verkettete liste realisiert wird. gruss
Gast
#449518
malloc() und free() beissen sich nicht mit eine uC. Es gibt genügend zuverlässige Algorithmen dafür. Dazu wurde die letzten 20 Jahre genügend geforscht, auch speziel für kleine Heaps. Hans wrote: >> Und? >> free() setzt den Speicher, den es freigibt nicht auf 0. > > In manchen Systemen schon. Das ist dann ein Grund diese Systeme zu meiden :-) Im Ernst: Ausser bei speziellen Debug-Builds wirst du kaum ein System finden, dass bei einem free() den Speicher ausnullt. Sowas würde auch komplett der C Philosophie widersprechen. Getan wird nur das Allernotwendigste was für den Job notwendig ist. malloc() nullt den Speicher nicht aus. Wenn ich das will, muss ich calloc() benutzen. Den Speicher auszunullen macht für free() überhaupt keinen Sinn, daher macht das auch Keiner. Ganz im Gegenteil: Wenn ich 200 MB allokiere und free() müht sich, unter heftigem Pagen, durch den Speicher um den auf 0 zu setzen, dann würde der Compilerhersteller mächtig Ärger kriegen. Wenn ich das will, muss ich vor dem free() explizit einen memset() benutzen. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
