MÖGLICHKEITEN UND GRENZEN IN DER DYNAMISCHEN CODEANALYSE VON C++ SOFTWARE. Von Matthias Neumann

Transkript

1 MÖGLICHKEITEN UND GRENZEN IN DER DYNAMISCHEN CODEANALYSE VON C++ SOFTWARE Von Matthias Neumann

2 /35 Inhaltsangabe Einleitung Ausprägungen der dynamischen Codeanalyse Debugging Logging Testing Profiling Profiling im Detail Technische Realisierungsmöglichkeiten Messkriterien für Profiling Auswirkungen auf das zu analysierende Programm

3 Inhaltsangabe 3/35 Abgrenzung zur statischen Codeanalyse Definitionder statischen Codeanalyse Durch Menschen Durch automatisierte Werkzeuge Vergleich von dynamischer und statischer Codeanalyse Vor- und Nachteile der statischen Codeanalyse Vor- und Nachteile der dynamischen Codeanalyse Fazit

4 /35 EINLEITUNG

5 /35 Einleitung Komplexität von Software wächst stetig Trotz Komplexität muss Qualität gewährleistet werden Mängel müssen so früh wie möglich lokalisiert werden Dynamische und statische Codeanalyse unterstützen bei der Fehlersuche Dynamische Codeanalyse untersucht Laufzeit-Fehler

6 /35 Dynamische Codeanalyse brisantes Thema Jährliche Konferenz ( Workshop on Dynamic Analysis ) Relevant bei INFORM für ein Projekt am Frankfurter Flughafen Dabei müssen Zeitvorgaben bei der Verarbeitung von xml- Telegrammen eingehalten werden In der Ausarbeitung wurden deshalb die Möglichkeiten der dynamischen Codeanalyse evaluiert

7 /35 AUSPRÄGUNGEN der dynamischen Codeanalyse

8 Ausprägungen 8/35 Allgemeines Jegliche Analyse des Programms, die während der Laufzeit stattfindet Durch die Ergebnisse dieser Analyse können Schwachstellen im Code lokalisiert werden

9 Ausprägungen 9/35 Debugging Ist ein Hilfsprogramm, das die Variablenwerte darstellt und schrittweise den Programmcode durchläuft Aufruflisten geben Informationen über Aufrufhierarchien der Funktionen Option beim Kompilieren unter GCC Debug-Modus unter Visual Studio Zusätzliche Informationen werden im Executable hinterlegt (Dateigröße nimmt zu)

10 Ausprägungen 10/35 Logging Logger protokolliert die Aktionen eines Programms Auch nach Absturz Laufzeitinformationen Ausgabe der Logs benötigt Ressourcen (IO)

11 Ausprägungen 11/35 Testing Ausführung des Programms mit dem Ziel Fehler zu finden Black-Box-Testing Tester kennt innere Strukturen nicht Durch Eingaben werden die Ausgaben geprüft Glass-Box-Testing Tester kennt interne Logik Tester schreibt Tests, die bestimmte Passagen des Quellcodes durchlaufen

12 Ausprägungen 12/35 Profiling Externes Werkzeug Misst bestimmte Laufzeitdaten eines Programmes, wie z.b. die Anzahl der Aufrufe einer Funktion Laufzeiten von Funktionen Speicherauslastungen Speicherlecks Codeüberdeckungen

13 /35 PROFILING im Detail

14 Profiling 14/35 Technische Realisierungsmöglichkeiten Manuelle Instrumentierung Zusätzliche Instruktionen werden dem Programm hinzugefügt Findet zeitlich vor dem Kompilieren statt Programmintern werden Werte ermittelt, die nach außen getragen werden Muss eigenständig implementiert + Stark individualisierbar

15 Profiling Technische Realisierung 15/35 Instrumentierung zur Compilezeit Wie manuelle Instrumentierung, aber mit generiertem Code Compiler fügt zusätzliche Instruktionen vor dem Kompilieren ein Typischerweise werden Funktionsaufrufe und Hierarchien gemessen und aufbereitet Bspw: Visual Studio Eingeschränkte Individualisierbarkeit + Kein Programmieraufwand

16 Profiling Technische Realisierung 16/35 Binäre Instrumentierung Findet nach dem Kompilieren statt Auf binärer Ebene wird das Programm manipuliert, so dass es Messpunkte zur Laufzeit zur Verfügung stellt Bspw: ATOM Keine Anpassungsmöglichkeiten + Keine Optionen beim Kompilieren + Kein manueller Aufwand

17 Profiling Technische Realisierung 17/35 Laufzeitinstrumentierung Programm läuft in einer virtuellen Maschine, die es observiert (Funktionsaufrufe, Speicherbedarf, etc.) Bspw: Valgrind Erhebliche Einbußen in der Performanz Durch Virtualisierung sind Umstände anders + Sehr geringer Aufwand + Programm muss nicht manipuliert werden

18 Profiling Technische Realisierung 18/35 Sampling Laufendes Programm wird stichprobenartig geprüft Stichproben werden in einer bestimmten Frequenz genommen Stichproben enthalten Informationen über die Funktion, die aktuell ausgeführt wird und dessen Aufrufhierarchie Relativer Anteil der Stichproben pro Funktion wird berechnet + Nahezu kein Geschwindigkeitsverlust + Keine Manipulation des Programms bzw. dessen Codes Ungenau, da nicht die Aktionen des Programms vernommen werden

19 Profiling 19/35 Auswirkungen auf das Programm Instrumentierung Zusätzliche Instruktionen verlangsamen das Programm Größe des Programms nimmt zu (Dateigröße) Speicherverhalten während der Laufzeit verändert sich

20 /35 ABGRENZUNG zur statischen Codeanalyse

21 Abgrenzung 21/35 Statische Codeanalyse Quellcode wird ohne Ausführung des Programms analysiert Code wird in textueller Form interpretiert und bewertet Frühe Fehlererkennung (vor oder während des Kompilierens) Kann durch automatisierte Werkzeuge oder durch Menschen stattfinden

22 Abgrenzung Statische Codeanalyse 22/35 Durch Entwickler Selten Überprüfungen auf Syntax, da sehr langwierig (Aufgabe für automatisierte Werkzeuge) Analyse auf Namenskonventionen und Funktionalität Dazu gehören: Codeinspektionen, Walkthroughs, Schreibtischtests, Pair-Programming

23 /35 Durch Werkzeuge Ermitteln Metriken, Vererbungen, syntaktische Fehler, Abhängigkeiten, etc. indem sie den Quellcode scannen Ähnliche Aufgaben wie Compiler Liefern eine aufbereitete Zusammenfassung der Ergebnisse bzw. Warnungen Visualisierungen, wie Klassendiagramme oder Nassi- Shneidermann-Diagramme Oft in Entwicklungsumgebungen integriert

24 /35 VERGLEICH von dynamischer und statischer Codeanalyse

25 Vergleich Statische Codeanalyse 25/35 Vorteile der statischen Analyse + Fehler/Warnungen beziehen sich auf eine exakte Stelle im Code + Gute Integration in Entwicklungsumgebungen Schnelle Navigation (u.a. durch Outlining) Statische Typsicherheit Codegenerierung (Getter, Setter, Deklaration in Header, etc.) Automatische Vervollständigung sowie passende Vorschläge + Gute Externe Tools wie Lint finden viele potentielle Schwachstellen, die der Compiler übersieht

26 Vergleich Statische Codeanalyse 26/35 Vorteile der statischen Analyse + Meist nur einmaliger Aufwand nötig + Deckt auch Teile des Codes ab, für die keine Tests formuliert sind

27 Vergleich Statische Codeanalyse 27/35 Nachteile der statischen Analyse Quellcode muss verfügbar sein Manuelle Analyse fordert hohe Konzentration und Ausdauer Trotzdem möglich, dass Fehler nicht gefunden werden Korrekter Code kann als fehlerhaft deklariert werden Analyse ist nur so gut, wie die definierten Prüfregeln Fehler, die auf bestimmter Hardware auftreten, werden nicht gefunden

28 Vergleich Dynamische Codeanalyse 28/35 Vorteile der dynamischen Analyse + Quellcode nicht zwangsläufig nötig + Fehler im Zusammenhang mit der Hardwarekonfiguration oder Laufzeitumgebung, werden nur in der Ausführung gefunden + Funktionalitäten werden geprüft (gute Testfälle geben Sicherheit, u.a. bei Refactoring) + Laufzeitinformationen (wie Zeitmessungen) nur dynamisch zu ermitteln

29 Vergleich Dynamische Codeanalyse 29/35 Vorteile der dynamischen Analyse + Performance-Tests + Sicherheitslücken, wie unzulässige Speicherzugriffe, Buffer- Overflows, etc. können entdeckt werden + Logging-Mechanismus möglich um auch produktive Systeme zu observieren und Abstürze nachzuvollziehen

30 Vergleich Dynamische Codeanalyse 30/35 Nachteile der dynamischen Analyse Komplexer und daher schwerer in bestehendes Projekt zu integrieren Teilweise muss Code geschrieben werden (manuelle Instrumentierung, Logging, Tests) Schlecht gewählte Testfälle garantieren keine Korrektheit Fehlgeschlagener Test zeigt nur Auslöser nicht Ursache Manipulation des Programmes bei vielen Profilingverfahren nötig

31 Vergleich Dynamische Codeanalyse 31/35 Nachteile der dynamischen Analyse Durch Manipulation wird Verhalten des Programms geändert Dadurch ist es möglich, dass Zeitmessungen unbrauchbar werden Sampling bei wenigen Stichproben nicht repräsentativ

32 /35 FAZIT

33 Fazit 33/35 Weder die statische noch die dynamische Codeanalyse sind objektiv betrachtet besser als die andere Eher: Ergänzen sich gegenseitig Schließen sich nicht gegenseitig aus Finden meistens auch zeitlich in unterschiedlichen Entwicklungsphasen statt Sinnvoll einzelne Werkzeuge und Verfahren der jeweiligen Analysen zu kombinieren

34 Fazit 34/35 Während der Entwicklung Pair-Programming und Reviews Lint/cppcheck o.ä. um Konventionen und Schwachstellen zu finden Testframework (Testfälle dokumentieren Funktionalität) Zeitkritische Passagen mit Profilern optimieren Überprüfung auf Speicherlecks mit profiling Tool Logging Mechanismus (wichtig nach Abstürzen)

35 /35 Noch Fragen? Vielen Dank für Ihre Aufmerksamkeit!