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 (x86), 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 a Fedora.

Předmět je připravován ve spolupráci týmu Systems Revenue Product Engineering společnosti Oracle Corporation, kernelových vývojářů společnosti SUSE a Red Hat a Katedry distribuovaných a spolehlivých systémů MFF UK.

Na přednáškách a cvičeních 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, SUSE Linux Enterprise a Red Hat Enterprise Linux.

Kontakt

Pokud máte dotaz nebo připomínku k předmětu, můžete použít emailový kontakt na přednášející:

  • Martin Děcký, decky<at-sign>d3s.mff.cuni.cz
  • Jiří Svoboda, jiri.svoboda<at-sign>oracle.com
  • Tomáš Jedlička, tomas.jedlicka<at-sign>oracle.com
  • Petr Muller, muller<at-sign>redhat.com
  • Martin Čermák, mcermak<at-sign>redhat.com
  • Jakub Filák, jfilak<at-sign>redhat.com
  • Vlastimil Babka, vbabka<at-sign>suse.cz
  • Michal Hocko, mhocko<at-sign>suse.cz

Harmonogram

Výuka předmětu byla pro zbytek letního semestru 2015/2016 zrušena. Důvodem je nejistá účast studentů na předmětu, která nekoresponduje s časovou náročností přípravy náplně předmětu obzvláště v případě externích přednášejících.

Termín Téma a slajdy přednášky Náplň cvičení
25. února 2016 Agenda
3. března 2016 Basics
10. března 2016 IA-32 & AMD64 basic tools usage examples
17. března 2016 SPARC V9 analysis of an obfuscated binary
24. března 2016 System Debugging in Solaris
mdb
  1. program examples on IA-32 and AMD64 compiled with various GCC optimalization levels
  2. RIP-relative addressing, position-independent code
  3. second analysis of an obfuscated binary
31. března 2016 Memory Management Issues
  1. introduction to mdb
  2. first crash dump for AMD64
7. dubna 2016 Deadlocks and Hangs
SPARC Systems
  1. program examples on SPARC V9 compiled with various GCC optimalization levels
  2. different function argument types
  3. global and thread-local variables
  4. red zone on AMD64
  5. introduction to mdb
  6. first crash dump for SPARC V9
  7. second crash dump for SPARC V9 (use after free)
14. dubna 2016 Linux Crash Dump Analysis Linux examples
21. dubna 2016 DTrace DTrace examples
28. dubna 2016 crash Linux crash examples
5. května 2016 ABRT ABRT examples
12. května 2016 SystemTap SystemTap examples
19. května 2016 Debugging in Windows
Command Line Tools
Trap tracing
26. května 2016 zkouška zápočet

Zdroje informací

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 může 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 dva 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.

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í souč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ů:

Podíl bodů Hodnocení
(80 %, 100 %> výborně
(60 %, 80 %> velmi dobře
(50 %, 60 %> dobře
<0 %, 50 %> neprospěl(a)

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 nebo AMD64 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. [2] K čemu se využívá adresace dat relativně vůči ukazateli na aktuální instrukci? Jak se tento mechanismus používá na platformě IA-32, jejíž instrukční sada neumožňuje použít registr EIP jako bázový registr?
  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 na IA-32 (můžeme předpokládat, že zásobník není jinak poškozen a kód odpovídá standardnímu ABI s frame pointery):
    CCCCCCCC foobar+n()
    BBBBBBBB foo+l()
    AAAAAAAA main+k()
    
    O jaký jev se jedná, pokud disassemblování instrukce na adrese foo+l 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 lokálním proměnným funkce pomocí registru RBP na AMD64? Vysvětlete proč.
  19. [1] Jaké znaménko bude mít displacement při přístupu k lokálním proměnným funkce pomocí registru RSP za použití GCC přepínače -mno-red-zone na AMD64? Vysvětlete proč.
  20. [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č.
  21. [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.
  22. [2] S jakými sadami registrů se pracuje při 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.
  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] 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?
  26. [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í?
  27. [1] Jak lze charakterizovat rozdíl mezi problémem typu uváznutí (deadlock) a zaseknutí (hang, livelock)?
  28. [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č?
  29. [1] Vysvětlete, proč skriptovací jazyk nástroje DTrace záměrně neobsahuje programové konstrukce typu cyklus nebo větvení. Jak tento aspekt zohledňuje nástroj SystemTap?
  30. [1] Vysvětlete, za jakým účelem je na platformě AMD64 zachována segmentace (ve velmi zjednodušené a omezené podobě).
  31. [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.
  32. [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?
Logo of Faculty of Mathematics and Physics
  • Phone: +420 951 554 267, +420 951 554 236
  • Email: info<at-sign>d3s.mff.cuni.cz
  •  
  • How to find us?
Modified on 2016-04-11