Fünf Ursachen für unliebsame Firmware-Fehler
Rezepte fürs Bugfixing
Fortsetzung des Artikels von Teil 4
Speicherlecks
Speicherlecks, und seien sie noch so gering, sorgen dafür, dass dem betreffenden System mit der Zeit der Speicher ausgeht. Häufig werden legitime Speicherbereiche überschrieben, was erst zu einem späteren Zeitpunkt registriert wird. Speicherlecks hängen häufig mit dem Ownership Management zusammen. Aus dem Heap zugeordnete Objekte haben stets einen Urheber (Creator) – wie etwa eine Task, die malloc() aufruft und den resultierenden Zeiger anschließend per Message Queue an eine andere Task überträgt oder den neuen Puffer in ein Meta-Heap-Objekt wie etwa eine verkettete Liste einfügt. Gibt es aber für jedes zugeordnete Objekt auch einen vorgegebenen Destroyer, der den betreffenden Speicherbereich wieder freigibt? Welche andere Task ist verantwortlich und wie kann sie sicher sein, dass keine andere Task den Puffer noch benötigt?
Jobangebote+ passend zum Thema
Abhilfe: Eine einfache Möglichkeit zur Vermeidung von Speicherlecks besteht darin, die Eigentümerschaft oder die Lebensdauer von Heap-zugeordneten Objekten jeglicher Art klar zu definieren. Bild 3 illustriert ein gängiges Ownership-Muster mit Puffern, die von einer produzierenden Task (P) zugeordnet, über eine Message Queue übertragen und später von einer Consumer Task (C) wieder aufgehoben werden.
Das in der Abbildung gezeigte Konzept eignet sich übrigens nicht nur zur Vermeidung von Speicherlecks, sondern auch zur Abwendung von Out-of-Memory-Fehlern. Bei letzteren enthält der Puffer-Pool keine Pufferspeicher, wenn die produzierende Task eine Zuordnung versucht. Die Vorgehensweise ist wie folgt: Erstens wird für diese Art der Zuordnung ein bestimmter Pool aus beispielsweise 17-Byte-Puffern angelegt. Zweitens wird mit Hilfe der Queuing-Theorie die Message Queue so dimensioniert, dass sie niemals ganz voll wird. Drittens wird der Puffer-Pool so bemessen, dass zu Beginn für jeden Consumer, jeden Produzenten und jeden freien Slot in der Message Queue ein freier Puffer vorhanden ist.
Betrachtet man die potenziellen Kosten für das Aufdecken von Fehlern und die möglichen Haftungsrisiken bei unentdeckten Fehlern, so ist es am besten, Fehler gar nicht erst entstehen zu lassen. Die in diesem Beitrag beschriebenen Abhilfemaßnahmen helfen nicht nur, Fehler von vornherein zu vermeiden, sondern erleichtern auch die Erkennung und Beseitigung jener Fehler, die sich bereits in die Firmware von Geräten eingeschlichen haben.
Der Autor
|
Michael Barr |
|---|
| ist Mitbegründer und Chief Technical Officer der Barr Group, war als außerordentlicher Professor für Elektrotechnik und Informatik tätig und besitzt mehr als zehn Jahre Erfahrung im Design und in der Implementierung von Software. Er besitzt Bachelor- und Master-Diplome in Elektrotechnik und lehrte außerdem am Department of Electrical and Computer Engineering der University of Maryland, an der er darüber hinaus ein MBA-Diplom erwarb. |
- Rezepte fürs Bugfixing
- Race Conditions
- Nicht ablaufinvariante Funktionen
- Prioritätsinversionen
- Speicherlecks
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Unit-Tests
In der Theorie großartig, aber …
Echtzeitanwendungen deguggen
i.MX6-Adapter-Board für nicht-invasive Ablaufverfolgung
Betriebssysteme
Kostenlos - bis das Geschäft läuft
Einplatinen-Computer
Raspberry Pi für Profi-Anwendungen
Kithara Software
»RealTime Suite« unterstützt FlexRay
Einblick in die statische Code-Analyse:
Auf verschlungenen Pfaden
Video: Automotive Software und Bordnetz-Kongress…
»Software in den Mittelpunkt stellen«
Arduino, BeagleBone, Raspberry Pi
Schneller entwickeln mit Entwicklungskits
Low-power-Design
Schluss mit Energieverschwendung
