Software-Tracing bei Embedded-Linux
Mit LTTng dem Fehler auf der Spur
Fortsetzung des Artikels von Teil 1
Auswertung von LTTng-Traces
LTTng enthält zwei Trace-Recorder. Der Kernel-Tracer zeichnet das Thread-Scheduling, Systemaufrufe, IRQs, das Speichermanagement und weitere Aktivitäten auf der Kernelebene auf und nutzt dabei die existierenden Tracepoints im Linux-Kernel. Der User-Space-Tracer (LTTng-UST) dagegen kann individuelle Ereignisse aus dem User-Space-Code generieren, indem er beispielsweise neue Tracepoints hinzufügt.
Auch wenn LTTng auf der Software-Instrumentierung beruht, erfordert es kein Rekompilieren des Ziel-Quellcodes. Der Kernel ist an strategisch wichtigen Stellen bereits mit Tracepoints ausgestattet, und mit einem weiteren Feature von Linux ist das Tracing ausgewählter User-Space-Funktionsaufrufe möglich, ohne den Quellcode zu verändern. Dies geschieht durch Erstellen von Shared-Object-Dateien mit Wrapperfunktionen (Bild 1), die Tracepoints enthalten. Die Shared-Object-Datei wird beim Starten der Applikation in LD_PRELOAD angegeben. Dies beeinflusst den dynamischen Linkprozess und sorgt dafür, dass die Applikation anstelle der ursprünglichen Funktion nun die Wrapperfunktion aufruft. Diese zeichnet das betreffende Ereignis mithilfe des oder der Tracepoints auf und ruft anschließend die ursprüngliche Funktion auf. Das Funktions-Wrapping ist somit für den Applikationscode völlig transparent und muss nicht erneut kompiliert werden. Wird eine Wrapperfunktion das erste Mal aufgerufen, schlägt sie die Adresse der Originalfunktion nach und legt sie für spätere Aufrufe in einem Funktionszeiger ab.
Auswertung von LTTng-Traces
LTTng gibt die Trace-Aufzeichnungen in dem offenen »Common Trace«-Format aus. Dieses ist binär und erfordert deshalb ein Analysewerkzeug. Das LTTng-Tool »Babeltrace« kann zwar die Tracedaten in Textdateien umwandeln, jedoch ist es schwierig, sich aus den enormen Mengen in Textform vorliegender Tracedaten ein Gesamtbild zu machen. Ein Visualisierungswerkzeug vereinfacht die Analyse deutlich, da das menschliche Gehirn Bildmuster wesentlich leichter erkennen kann als Strukturen in Textdaten.
Unter dem Namen »Tracealayzer« bietet Percepio (Vertrieb: Embedded Tools) eine Familie von Trace-Visualisierungswerkzeugen an. Das Tool hält einen recht umfangreichen Bestand an grafischen Ansichten für eine einfachere Trace-Analyse bereit und wird für mehrere Embedded-Betriebssysteme angeboten, darunter Linux, VxWorks, Free¬RTOS, SafeRTOS, Micrium µC/OS-III und RTXC Quadros. Tracealyzer for Linux ist für das Visualisieren von LTTng-Trace-Daten konzipiert und unterstützt sowohl das aktuelle LTTng v2.x als auch ältere LTTng-Versionen (zum Beispiel die in Wind River Linux 5 enthaltene Version). Die Tracealayzer-Visualisierung wurde mit Microsoft .NET entwickelt. Der kommende Tracealayzer v2.7 läuft auf Linux auch unter der alternativen, quelloffenen .NET-Implementierung »Mono«.
Jobangebote+ passend zum Thema
Die Haupt-Trace-Ansicht von Tracealyzer (Bild 2) visualisiert die Verarbeitung der Threads entlang einer vertikalen Zeitachse und nutzt dafür farbcodierte Labels. Derartige Markierungen lassen sich auf unterschiedliche Art filtern. Das Tool passt deren Anordnung automatisch so an, dass sie sich nicht überlappen. An der Hintergrundfarbe der Labels können Entwickler Status und Typ der Verarbeitung ablesen. Rote Markierungen etwa kennzeichnen Systemaufrufe, die den aufrufenden Thread blockieren, während grüne Labels angeben, wo blockierende Systemaufrufe zur aufrufenden Instanz zurückgehen. Individuelle Applikationsereignisse aus dem User-Space-Tracer (LTTng-UST) sind so konfigurierbar, dass Tracealyzer sie entweder als Dienstaufrufe (zum Beispiel »malloc«) oder als User-Ereignisse, also als generische Debug-Meldungen (mit gelben Markierungen) darstellt.
Dennoch kann Tracealayzer weit mehr als ein einfacher Viewer. Das Tool erkennt und markiert Abhängigkeiten zwischen zusammenhängenden Ereignissen in den Tracedaten (beispielsweise das Senden und Empfangen ei-nes Semaphor-Signals). Hierdurch wird es einfacher, das Verhalten des Betriebssystems zu verstehen (zum Beispiel weshalb bestimmte Threads blockiert und andere getriggert werden).
Ein Beispiel ist in Bild 2 zu sehen. Darin ist ein blockierender write-Aufruf hervorgehoben. Dieser Aufruf erzeugt zwei LTTng-Ereignisse: eines zu Beginn des Aufrufs (Entry Event) und ein weiteres beim Rücksprung (Exit Event). Da der Aufruf den Thread blockiert hat, sind diese beiden Ereignisse durch Kontextwechsel und weitere Ereignisse voneinander getrennt. Tracealayzer erkennt, dass beide Ereignisse zusammenhängen und markiert beide (blaue Umrandung), sobald eines ausgewählt wird. Das Entry-Event (»write(FD-1) blocks«) teilt mit, dass die Blockierung des aufrufenden Threads »demo.out: 5133« durch eine write-Operation an FD-1, also an File Descriptor 1 (Standard Output) ausgelöst wurde. Der Thread wurde nahezu sofort ausführungsbereit (»Actor Ready: demo.out: 5133«), jedoch wurde die Verarbeitung erst 69 µs später fortgesetzt (»write(FD-1) returns after 69 µs«).
Die Hauptansicht wird durch mehr als zwanzig zusätzliche Ansichten ergänzt, die weitere Trace-Perspektiven wiedergeben. So zeigt das CPU-Usage-Diagramm den zeitlichen Verlauf der Auslastung des Gesamtsystems sowie der einzelnen Threads. Weitere Ansichten geben Statistiken über das Thread-Timing, Kernel-Blockierungen, die Scheduling-Intensität, die Kommunikation zwischen den Prozessen sowie Kommunikationsabhängigkeiten zwischen den Prozessen wieder (Bild 3). Ein Trace enthält häufig einen übermäßigen Umfang an Informationen zu immer wiederkehrenden, weniger interessanten Szenarien. Hier können sich die zahlreichen Ansichten von Tracealyzer bewähren, die unterschiedliche Perspektiven bieten und so dabei helfen, interessante Abschnitte aufzufinden, zum Beispiel wenn ein Systemaufruf fehlschlägt oder ein Thread für seine Beendigung mehr Zeit benötigt als normal.
In der Hauptansicht werden Applikationsereignisse als gelbe Labels (User Events) dargestellt. Sie können jedoch auch in einem separaten Log-Fenster erscheinen, das einen Überblick über das allgemeine Verhalten der Applikation gibt und beispielsweise über Aktualisierungen wichtiger Zustandsvariablen informiert. Wenn in das Applikations-Logging numerische Daten einbezogen sind (beispielsweise Pufferauslastung, Steuersignale oder Sensoreingänge), können diese grafisch dargestellt werden. Im Prinzip verfügt man hier über einen Software-Logikanalysator, der bei Entwicklungen verschiedener Art von Nutzen sein kann. Außerdem sind die Datenpunkte in den Diagrammen mit der Hauptansicht verknüpft: Nach einem Doppelklick auf einen beliebigen Datenpunkt wird die Hauptansicht so synchronisiert, dass sie das zugehörige Ereignis darstellt.
- Mit LTTng dem Fehler auf der Spur
- Auswertung von LTTng-Traces
- Thread-Priorisierung überprüfen
