Crash dump analýza 2010/2011 (LS)

O předmětu

Kontakt

Harmonogram

Zdroje informací

Zápočet

Zkouška

O předmětu

Přednáška a cvičení jsou zaměřeny na výuku a procvičování technik tzv. crash dump analýzy, čili hledání příčin fatálních problémů operačního systému (např. "spadnutí" či "zamrznutí" systému, poškození paměti apod.).

Posluchači se seznámí se základními mechanismy fungování procesorů a instrukčních sad IA-32, AMD64 (x86-64) a SPARC V9. Na těchto základech budou poté demonstrovány nástroje pro analýzu příčin pádu, ladění a observabilitu. V přiměřené míře budou také probírány základní principy nízkoúrovňového programování, ale také složitější datové struktury a algoritmy, které se používají v operačních systémech, a možné problémy, které vlivem programátorských chyb vznikají (deadlock, porušení paměti apod.).

Cvičení probíhají interaktivní formou v počítačové laboratoři. Během cvičení se používají zjednodušené příklady reálných chyb, které se v praxi objevují při poskytování zákaznické podpory velkých softwarových systémů. Praktické úlohy pocházejí především z prostředí unixových operačních systémů, ale osvojené znalosti a postupy lze využít v libovolném operačním systému. Během cvičení i mimo něj mají studenti vzdálený přístup na servery architektury AMD64 (x86-64) a UltraSPARC T1 (Niagara) se systémem Oracle Solaris.

Předmět je připravován ve spolupráci týmu Systems Revenue Product Engineering Oracle Corporation a Katedry distribuovaných a spolehlivých systémů. Na přednáškách a cvičeních tedy studenti získají nejen teoretické znalosti, ale také praktické zkušenosti zprostředkované lidmi, kteří se crash dump analýzou profesionálně zabývají v rámci vývoje a péče o korporátní zákazníky využívající Oracle Solaris.

Kontakt

K výměně informací mezi studenty a vyčujícími je určen mailing list. Pro dotazy a připomínky týkající se výuky používejte prosím přednostně tento mailing list.

Pokud máte dotaz nebo připomínku, kterou nechcete posílat do mailing listu, můžete použít také email přednášejících:

• Jakub Jermář, jakub.jermar<at-sign>oracle.com
• Martin Děcký, martin.decky<at-sign>d3s.mff.cuni.cz

Harmonogram

Přednáška se koná v letním semestru 2010/2011 v úterý od 10:40 do 12:10 v posluchárně S8, cvičení se koná v úterý od 12:20 do 13:50 v laboratoři SU1.

Harmonogram přednášek je zatím předběžný a může se průběžně měnit.

Zdroje informací

• Frank Hofmann: The Solaris Operating System on x86 Platforms, Crashdump Analysis, Operating System Internals
• Richard McDougall, Jim Mauro, Brendan Gregg: Solaris Performance and Tools: DTrace and MDB Techniques for Solaris 10 and OpenSolaris
• Chris Drake, Kimberley Brown: PANIC! UNIX System Crash Dump Analysis Handbook
• Igor Ljubuncic: Linux Kernel Crash Book
• NASM Manual, Appendix B: Instruction List
• SPARC Assembly Language Reference Manual, Appendix E: SPARC V9 Instruction Set

Zápočet

Zápočet z předmětu Crash dump analýza lze získat za úspěšné absolvování praktické examinace. Typická zadání examinice mohou být například: samostatné odhalení tzv. root cause na základě předloženého crash dumpu, odhalení programátorské chyby ve zdrojovém kódu (kdy zdrojáky některých částí výsledného programu nejsou k dispozici) apod.

Examinace je časově omezena 90 minutami a je při ní povolena veškerá literatura, zápisky a pomůcky (včetně Internetu) výjma sbírek řešených příkladů a spolupráce s jinou osobou. Na absolvování examinace má každý student k dispozici tři pokusy.

Účast na cvičení není vyžadována a není kritériem pro získání zápočtu. Přesto důrazně doporučujeme cvičení ve vlastním zájmu aktivně absolvovat.

Termíny examinace

Nejbližší zápočtový termín se bude konat 7. 6. 2011 od 10:40 v SU1. Prosím přihlašujte se na termín pomocí Studijního informačního systému. V případě, že vám tento termín nevyhovuje nebo zápočet nezískáte, domluvíme se na dalším termínu pomocí emailu.

Zkouška

Zkouška z předmětu Crash dump analýza bude probíhat formou písemky, která by měla prověřit znalosti z přednášky a cvičení. Písemka bude obsahovat náhodný výběr otázek (případně jejich variací) ze seznamu uvedeného na konci této stránky. Maximální počet bodů se podle varianty písemky bude pohybovat mezi 12 až 14.

Na vypracování písemky bude 60 minut a kromě psacích potřeb nejsou povoleny žádné pomůcky. Za každou správně zodpovězenou otázku lze získat příslušný počet bodů, který je u ní uveden (případně menší podíl v případě částečně správné odpovědi). U většiny otázek je kromě fakticky správné odpovědi potřeba pro získání plného počtu bodů uvést také podrobné a jasné vysvětlení nebo zdůvodnění. Počet bodů u jednotlivých otázek nevyjadřuje nutně jejich složitost. Celkové hodnocení se poté určí na základě podílu součtu získaných bodů vůči maximálnímu počtu bodů:

Termíny zkoušky

Zájemci o zkouškový termín nechť kontaktují přednášející, domluvíme se na konkrétním termínu pomocí emailu. Získání zápočtu není podmínkou pro konání zkoušky.

Zkouškové otázky

1. [2] Popište výhody a nevýhody instrukční sady s pevnou a proměnnou délkou instrukcí (z pohledu ladění kódu).
2. [2] Popište situace, kdy funkce uvedená ve zdrojovém kódu po překladu nefiguruje jako samostatná funkce ve strojovém kódu.
3. [1] Jaký je rozdíl mezi adresací celých čísel v paměti u procesorů architektury little-endian a big-endian.
4. [1] Vysvětlete pojem ABI (Application Binary Interface).
5. [1] Vyberte si jedno ABI používané na IA-32 a jedno ABI používané na AMD64 a popište tři shody a tři rozdíly.
6. [1] Vyberte si jedno ABI používané na AMD64 a jedno ABI používané na SPARC V9 a popište tři shody a tři rozdíly.
7. [1] Proč většina ABI definuje ukládání argumentů funkcí na zásobník v opačném pořadí než jsou argumenty uvedeny v signatuře funkce?
8. [1] Co jsou to non-volatile registry a jak se liší od volatile registrů?
9. [1] Co je to stack pointer a jak se liší od frame pointeru?
10. [1] Podrobně popište, z čeho se skládá stack frame. Můžete si vybrat jednu z architektur probíraných na přednášce.
11. [1] Co je to trap frame a jak se liší od stack frame?
12. [1] Co je to red-zone (v souvislosti se zásobníkem procesoru) a jaké jsou výhody použití red-zone?
13. [1] Co je to branch delay slot?
14. [3] Musí trap frame na IA-32 nutně obsahovat (uchovávat) všechny preserved registry, pokud funkce, která trap frame vytváří, žádné preserved registry nemění a volá pouze funkce dodržující ABI? Svou odpověď zdůvodněte.
15. [3] Musí trap frame na AMD64 nutně obsahovat (uchovávat) všechny scratch registry, pokud funkce, která trap frame vytváří, některé scratch registry nemění a volá alespoň jednu funkci (všechny volané funkce dodržují ABI)? Svou odpověď zdůvodněte.
16. [3] Mějme následující kód:

    int foo(...)
    {
    	...
    	int rc;
    	...
    	rc = bar(...);
    	foobar(...);
    	return rc;
    }
    

    Může se stát, že se návratová hodnota funkce bar() uloží do stack frame funkce foobar()? Svou odpověď zdůvodněte.
17. [3] Mějme následující stack trace:

    CCCCCCCC foobar+n()
    BBBBBBBB foo+l()
    AAAAAAAA main+k()
    

    O jaký jev se jedná, pokud následující příkaz debuggeru mdb foo+l/i místo volání funkce foobar() ukáže volání funkce bar()? Popište, jakým způsobem byste zjistili adresu instrukce, která zavolala funkci foobar()?
18. [1] Jaké znaménko bude mít displacement při přístupu k argumentům funkce pomocí registru EBP na IA-32? Vysvětlete proč.
19. [1] Jaké znaménko bude mít displacement při přístupu k argumentům funkce pomocí registru RSP za použití GCC přepínače -mno-red-zone na AMD64? Vysvětlete proč.
20. [2] Jaké znaménko bude mít offset v instrukcích ldx/stx (load/store) při přístupu k lokálním proměnným funkce pomocí registru %sp na SPARC V9? Vysvětlete proč. Jak se situace změní při použití registru %fp? Uvažujte zásobníkové rámce malé velikosti.
21. [2] S jakými sadami registrů se pracuje pri window spill trap a window fill trap výjimkách na architektuře SPARC V9? Popište také jak a proč se tak děje?
22. [1] K čemu slouží příkazy ::typegraph a ::whattype debuggeru mdb?
23. [3] Popište, za jakých okolností může nastat situace, kdy uživatelská aplikace padá při přístupu do paměti, ale při použití knihovny libumem se chyba neprojeví.
24. [3] Popište obecně postup, kterým byste zjistili místo uváznutí (deadlocku) několika kernelových vláken v běžícím systému.
25. [1] Uvažujme, že při krokování programu v mdb na IA-32 nebo SPARC V9 je aktuální hodnota stack pointeru c. Zkonstruujte a popište příkaz mdb, pomocí kterého si můžete po každé odkrokované instrukci zobrazit aktuální obsah zásobníku až po adresu c, aniž by bylo potřeba daný příkaz pokaždé měnit.
26. [1] Z jakého důvodu je větší pravděpodobnost, že náhodně vygenerovaná data vypadají na první pohled jako skutečný kód, na platformš IA-32 (resp. AMD64) než na platformě SPARC V9?
27. [1] Proč se v assembleru procesorů SPARC V9 (obecně řady RISCových procesorů) často používají pseudoinstrukce (syntetické instrukce), které po překladu do spustitelného kódu vygenerují několik skutečných instrukcí?
28. [1] Jak lze charakterizovat rozdíl mezi problémem typu uváznutí (deadlock) a zaseknutí (hang, livelock)?
29. [2] Jaké statistické veličiny poskytované operačním systémem lze použít pro indikaci toho, že daná konfigurace počítače je výkonově nedostatečná pro aktuálně prováděnou zátěž a proč?
30. [1] Vysvětlete, proč skriptovací jazyky sledovacích nástrojů typu DTrace záměrně neobsahují programové konstrukce typu cyklus nebo větvení.
31. [1] Vysvětlete, za jakým účelem je na platformě AMD64 zachována segmentace (ve velmi zjednodušené a omezené podobě).
32. [1] Vysvětlete, co se rozumí pod pojmem "ortogonální instrukční sada" (vůči registrové sadě). Vysvětlení vhodně ilustrujte na konkrétních příkladech.
33. [2] Jak se liší význam hodnoty saturace (typicky vyjádřené číslem bez horního limitu) a hodnoty utilizace (typicky vyjádřené číslem v rozsahu <0, 1>) procesoru? Ve kterých situacích má která veličina lepší vypovídací hodnotu?