TotalView Debugger

1. TotalView Debugger Vorgestellt von Marco Dyballa mail: dyballu@uni-muenster.de

2. Gliederung 1 Motivation 2 TotalView – Ein Überblick 3 Prozess-/Thread-Modell von TotalView 4 Multi-Prozess/Multi-Thread-Debugging – Ein Beispiel 5 Fazit

3. 1. Motivation • Debugger stellen für die Qualitätssicherung in der Softwaretechnik ein unverzichtbares Instrument dar • TotalView hebt sich insbesondere durch die Unterstützung Debuggens von Parallelen Programmen von anderen Debuggern ab • Auf die allgemeinen Funktionen eines Debuggers soll hier nicht näher eingegangen werden, sondern lediglich auf die besonderen Elemente von TotalView

4. 2 TotalView – Ein Überblick (1/2) Features • Übliche Debugfunktionalität • Paralleles Debuggen (Multi-Thread/Multi-Prozess) • Remote-Debugging über ein Netzwerk • Graphische Visualisierung von Daten in 2D oder 3D • Erhältlich für Unix-/Linuxsysteme auf unterschiedlichen Plattformen • HP Alpha Tru64 UNIX • IBM RS/6000 Power AIX • Sun SPARC Solaris • SGI IRIX 6.x MIPS • u.a. • Programmiersprachen C/C++, Fortran und Assembler • Unterstützung mehrerer Compiler-Distributionen

5. 2 TotalView – Ein Überblick (2/2) Testumgebung • TotalView V6.4 (www.etnus.com) • Suse Linux 9.0 • GNU-C/C++-Compiler V3.3.2 • AMD-AthlonXP 2400+ (Single-Prozessor)

6. 2 Die Prozessansicht (1/2)

7. 2 Die Prozessansicht (2/2) • Go Das Programm wird ausgeführt • Halt Das Programm wird sofort angehalten • Next Die aktuelle Programmzeile wird ausgeführt • Step Wie Next, es wird jedoch in Funktionen verzweigt • Out Das Programm wird bis Funktionsende ausgeführt • Run To Das Programm wird bis zu einer bestimmten Zeile ausgeführt • NextI Führt die nächste Instruktion auf Assemblerebene aus • StepI Wie NextI, es wird jedoch in Subroutinen verzweigt • P- / P+ Wechselt zum vorherigen/nächsten Prozess • T- / T+ Wechselt zum vorherigen/nächsten Thread Mit der linken oberen Auswahlbox wird die Menge von Prozessen oder Threads festgelegt, auf die sich die Kommandos beziehen (die Arena).

8. 2 Breakpoints (1/4) TotalView unterstützt vier Arten von Breakpoints 1. Breakpoints (Standard) • Der gesamte Prozess wird angehalten 2. Watchpoints • Prozess wird angehalten, wenn sich der Wert einer Variablen ändert 3. Evaluationpoints • Ausführung vorgegebener Code-Fragmente ohne Unterbrechung 4. Barrieren • Ein Thread/Prozess wird an dieser Stelle angehalten und erst wieder freigegeben, wenn alle Threads/Prozesse eines Sets diese Barriere erreicht haben

9. 2 Breakpoints (2/4) Evaluationpoint • Ausführung von Code-Fragmenten in C/C++, Fortran oder Assembler • Ausführung spezieller Statements von TotalView, eingeleitet mit $ • Beispiel: Schleife alle 20 Durchläufe unterbrechen$count 20 • Beispiel: Ausführung anhalten, wenn eine Variable einen bestimmten Wert erreichtif(counter == 50) $stop

10. 2 Breakpoints (3/4) Watchpoint • Auch Memory-Breakpoint genannt, weil streng genommen eine Speicherzelle überwacht wird, nicht der symbolische Variablenname Lebensdauer von Objekten/Variablen beachten! • Zugriff auf alten und neuen Wert der Variable über Statements $oldval und $newval • Bedingte und nicht bedingte Watchpoints • Nicht bedingt: die Programmausführung wird immer unterbrochen, wenn sich der Wert der Speicherzelle ändert • Bedingt: die Programmausführung wird nach positiver Prüfung eines Statements unterbrochen Evaluationspointif($newval == 50) $stop

11. 2 Breakpoints (4/4) Watchpoint: Lebensdauer von Objekten beachten Beispiel: [1] for(int i=0; i<100; i++) { printf(„%d“, i); } [2] for(int j=0; j<100; j++) { printf(„%d“, j); } Watchpoint auf i: if($newval == 50) $stop • Die Ausführung stoppt, sobald i den Wert 50 enthält • Nach Verlassen des Blocks in Zeile [1] ist i nicht mehr bekannt, d.h. der Speicher wird freigegeben • Beim Eintritt in [2] wird j angelegt und erhält den Speicherbereich, den vorher i innehatte • Da der Watchpoint noch existiert, wird die Ausführung angehalten, sobald nun j den Wert 50 enthält  war nicht beabsichtigt!

12. 3 Prozess-/Thread-Modell 3 Prozess-/Thread-Modell 3.1 Gruppenbildung 3.1.1 Prozessgruppen 3.1.2 Threadgruppen 3.1.3 Zusammenhänge der Gruppen 3.2 Auswirkungen von Kommandos 3.2.1 GOI, POI, TOI und die Arena 3.2.2 Auswirkungsweite von Kommandos 3.3 Barrieren

13. 3.1 Gruppenbildung (1/5) Prozesse und Threads werden in TotalView in jeweils zwei Gruppen eingeteilt: Über die Gruppenzugehörigkeit bestimmt TotalView, welche Prozesse und Threads von einem Kommando betroffen sind.

14. 3.1.1 Prozessgruppen (2/5) Control Group • Enhält den Elterprozess • alle zugehörigen Kindprozesse • via fork() erzeugt (beruhen alle auf demselben Sourcecode) • via execve() erzeugt (evtl. anderer Sourcecode, andere Programme) Share Group • Prozesse der Control Group, die auf demselben Executable beruhen Control und Share Group unterscheiden sich nur dann, wenn Kindprozesse mit execve()erzeugt wurden, weil dann unterschiedliche Executables zugrunde liegen  zwei Share Groups, eine Control Group

15. 3.1.2 Threadgruppen (3/5) Workers Group • Enthält alle Arbeitsthreads der Control Group • vom Programm erzeugte Threads • Service-Threads, die Dienste für andere Threads bereitstellen • keine Manager-Threads Lockstep Group • Enthält alle angehaltenen Threads einer Share Group, die • am selben Programmzähler angehalten wurden und sich somit • an derselben Stelle innerhalb des Programms befinden

16. 3.1.3 Zusammenhänge Prozessgruppen (4/5) Zusammenhang zw. Prozess, Control Group und Share Group

17. 3.1.3 Zusammenhänge Threadgruppen (5/5) Zusammenhänge zwischen Threads und Gruppen

18. 3.2.1 GOI, POI, TOI und die Arena Ermittlung der von einem Kommando betroffenen Prozesse/Threads • GOI – Group of Interest • POI – Process of Interest • TOI – Thread of Interest • Zentrale Rolle • Ist der Thread, auf den sich ein Kommando direkt bezieht • Über den TOI werden POI und GOI ermittelt:TOI  Lockstep Group  Share Group  Control Group • ArenaMenge von Threads, Prozessen und Gruppen, die von einem Kommando betroffen sind

19. 3.2.2 Auswirkungsweite von Kommandos Die Auswirkungsweite von Kommandos kann in der Prozessansicht eingestellt werden: Unterschieden werden drei Reichweiten 1. Thread Width 2. Process Width 3. Group Width

20. 3.2.2 Auswirkungsweite von Kommandos Thread Width • Nur der gewählte Thread wird gestartet (TOI) • Sobald der TOI sein Ziel erreicht, wird er angehalten, alle anderen Threads laufen weiter. Process Width • Prozessgruppe • Alle Threads des Prozesses werden gestartet • Sobald der TOI sein Ziel erreicht hat, werden er und alle anderen Threads des Prozesses angehalten • Threadgruppe • Alle Threads der GOI werden gestartet • Sobald ein Thread der GOI sein Ziel erreicht, wird er angehalten • Wenn alle Threads der GOI ihr Ziel erreicht haben, wird der gesamte Prozess angehalten

21. 3.2.2 Auswirkungsweite von Kommandos Group Width • Prozessgruppe • Alle Prozesse der Control Group werden gestartet • Erreicht ein Thread das Ziel, wird der Prozess angehalten • Fortsetzung, bis alle betroffenen Prozesse angehalten wurden • Threadgruppe: • Alle Prozesse der Control Group werden gestartet • Erreicht ein Thread das Ziel, wird dieser angehalten, andere Threads des Prozesses laufen weiter • Sobald alle Threads der GOI angehalten wurden, werden alle Prozesse der Control Group angehalten

22. 3.3 Barrieren (1/3) Barrieren • Sinnvoll beim parallelem Debuggen • Zur Synchronisation mehrerer Prozesse/Threads • Legen die Threads fest, die bei Erreichen der Barriere angehalten werden sollen – When Hit, Stop • Legen die Threads fest, die nach Ausführung der Barriere zusätzlich angehalten werden sollen – When Done, Stop • Legen die Menge der Threads fest, die die Barriere erreicht habe müssen, damit alle gehaltenen Threads wieder freigegeben werden – Satisfaction Set

23. 3.3 Barrieren (2/3) • When Hit, Stop und When Done, Stop • Group: Stoppt alle Threads der zugehörigen Control Group • Process: Stoppt alle Threads des zugehörigen Prozesses • Thread: Stoppt nur den gegenwärtigen Thread • Satisfaction Set • Control: Alle Threads der Control Group müssen die Barriere erreicht haben • Share: Alle Threads der Share Group müssen die Barriere erreicht haben • Workers: Alle Threads der Workers Group müssen die Barriere erreicht haben Anm.: Korrektur zur Ausarbeitung!

24. 3.3 Barrieren (3/3) Einstellungsdialog für Barrieren

25. 4 Multi-Prozess/Multi-Thread-Debugging 4 Multi-Prozess/Multi-Thread-Debugging 4.1 Probleme beim parallelen Debuggen 4.2 Beispiel

26. 4.1 Probleme beim parallelen Debuggen • Kommunikationsprobleme zwischen Prozessen oder Threads stellen eine der häufigsten Fehlerquellen bei der parallelen Programmierung dar • Kommunikation ist häufig abhängig vom Timing • Daraus resultiert für das parallele Debugging: • Der Fehler tritt beim Debuggen nicht mehr auf • Durch verändertes Timing in den Debugversionen der Programme • Das Anhalten eines Prozesses kann zu einem anderen Kommunikationsverhalten führen

27. 4.2 Beispiel Problemstellung • Eine Fraktalgrafik soll auf zwei Prozessoren berechnet werden • Hierzu werden drei Prozesse benötigt • zwei Arbeitsprozesse, Worker1 und Worker2 • ein Hauptprozess, der die Aufgaben verteilt, der Farmer • Berechnung erfolgt Zeilenweise für insgesamt 480 Zeilen • Die Worker-Prozesse beruhen auf der Datei fraktal, der Farmer-Prozess auf der Datei fraktalmain • Die Worker-Prozesse machen dann unter sich aus, wer welche Aufgabe hat

28. 4.2 Beispiel Kommunikation zwischen den Prozessen • bool SendMsg(const char* Port, const char* Msg)sendet Nachricht Msg an Kommunikationsport Port • bool RecvMsg(const char* Port, char* Msg)prüft ob am Kommunikationsport Port eine Nachricht vorliegt und speichert diese gegebenenfalls in Msg

29. 4.2 Beispiel – Die Worker void Worker(const char* Name) { char Buffer[1024]; // Puffer für empfangene Nachrichten […] // Portadresse aus Namen bilden for(;;) { while(!RecvMsg(Name, Buffer)); // Auf Nachricht warten char Msg[128]; int Line; sscanf(Buffer, "%s %d", Msg, &Line); // Nachricht zerlegen if(strcmp(Buffer, "Compute") == 0) // Nachricht auswerten Compute(Line); else if(strcmp(Buffer, "Quit") == 0) { if(strcmp("Worker1", Name) == 0) SendMsg("Worker1Answer", "Exited"); else if(strcmp("Worker2", Name) == 0) SendMsg("Worker1Answer", "Exited"); // FEHLER !! return; } SendMsg(Port, "Ready"); // Farmer melden, dass wir bereit sind } }

30. 4.2 Beispiel – Der Fehler Feststellung: Der Farmerprozess terminiert nicht! Mögliche Gründe 1. Der Farmer merkt nicht, dass die letzte Zeile schon berechnet wurde und sendet keine Quit-Nachrichten an die Worker. Da er dadurch auch keine Exited-Nachrichten der Worker erhält, terminiert er nicht. 2. Mindestens einer der Worker erhält keine Quit-Nachricht oder sendet keine Exited-Nachricht. Beide Möglichkeiten lassen sich dadurch überprüfen, indem wir an den Kommunikationsstellen der Worker überprüfen, welche Nachrichten empfangen und gesendet werden.

31. 4.2 Vor dem Start Die angebundenen Prozesse

32. 4.2 Die Control Groups vor dem Start Farmer Worker

33. 4.2 Die Share Groups vor dem Start Farmer Worker

34. 4.2 Die Worker Groups vor dem Start Farmer Worker

35. 4.2 Beispiel – Barriere setzen Barrieren in Worker-Funktion an den Kommunikations- stellen setzen

36. 4.2 Beispiel – Barriere einstellen Einstellungen der Barriere

37. 4.2 Nach dem Start Die angebundenen Prozesse

38. 4.2 Prozessansicht nach dem Start

39. 4.2 Die Control Groups nach dem Start Farmer Worker

40. 4.2 Die Share Groups nach dem Start Farmer Worker

41. 4.2 Die Worker Groups nach dem Start Farmer Worker

42. 4.2 Die Lockstep Groups nach dem Start Farmer Worker Anm.: Die Lockstep Groups der Worker sind vom Inhalt identisch, mit der Ausnahme, dass sie unterschiedliche TOIs besitzen.

43. 4.2 Fehlersuche Teil 1 • Wir stellen fest, dass die Worker Nachrichten vom Farmer empfangen • Daher wollen wir feststellen, ob die Worker auch korrekt ihre Nachrichten an den Farmer senden • Hierzu: • Deaktivieren der ersten Barriere • Beide Prozesse weiterlaufen lassen • Beide Prozesse stoppen, sobald sie an ihren entsprechenden (zweiten) Barrieren angelangt sind (an den SendMsg-Zeilen)

44. 4.2 Nach dem Start 2 Die angebundenen Prozesse

45. 4.2 Nach dem Start 2 – Worker 1

46. 4.2 Nach dem Start 2 – Worker 2 (FEHLER)

47. 4.2 Nach dem Start 2 – Lockstep Groups Worker 1 Worker 2

48. Fazit • TotalView ist ein universeller, komplexer Debugger • Unterstützung vieler Plattformen • Nicht gebunden an eine Compiler-Distribution • TotalView eignet sich besonders zum Debuggen paralleler Programme

49. Alles ist mal zu Ende Ich bedanke mich für Eure Aufmerksamkeit!