Ladění (programování)

Ladění je v informatice metodický postup pro nalézání a snižování množství chyb v počítačových programech nebo elektronického hardware tak, aby fungoval, jak se předpokládá. Ladění chyb bývá obtížnější v systémech, které jsou silně provázané, protože jedna chyba vyvolává další. Ladění probíhá pomocí testování systému, u software za pomoci ladicích výpisů nebo ladicích nástrojů (debugger, Valgrind, …)

Vývoj softwaru
  • (existující články)
  • Základní aktivity
  • Příbuzná témata
  • Standardy a odborná sdružení
  • Slovníčky, seznamy

Původ výrazu

editovat

Existuje několik polemik o původu termínu debugging. Pojmy bug (tj. chyba) a debugging (tj. ladění) jsou připisovány Grace Hopperové ve 40. letech.[1] Zatímco ona pracovala na počítači Mark II na Harvardově univerzitě, její spolupracovníci objevili můru, která uvízla v relé, a tím narušila činnost počítače. Odstraňování této závady nazvali „debugováním“, neboli „odstraňováním hmyzu“ (laděním much). Avšak výraz bug ve smyslu technické chyby, je datován nejméně do roku 1878 od Thomase Edisona. Pojem debugging se ještě před začátkem používání ve světě počítačů používal jako výraz v letectví. A skutečně, v jednom rozhovoru Grace Hopperová poznamenala, že nebyla tvůrcem tohoto výrazu. Bug byl vhodným a existujícím výrazem a hodil se do dané terminologie, tak jej tak ponechali.

Pokud se podíváme do Oxfordského slovníku angličtiny na slovo debugging, vypadne nám pojem debugging použitý v odkazu na testování leteckého motoru v roce 1945 v časopise Royal Aeronautical Society. Hopperová použila tento výraz 9. září 1947. Pojem byl přijat počítačovými programátory až do začátku roku 1950. V roce 1951 napsal S. Gill významný článek, kde je nejstarší zaznamenaná diskuse o programových chybách, ale nepoužívají se zde přímo pojmy bug nebo debugging. V digitální knihovně ACM je termín ladění poprvé použit až ve třech dokumentech z roku 1952 z Národního setkání ACM. Dva ze tří používají termín v uvozovkách. Do roku 1963 byl výraz debugging dostatečně běžný, že byl bez vysvětlení použit na straně 1 v manuálu CTSS.

Článek „Stalking the Elusive Computer Bug“ od Peggy A. Kidwellové[2] se zabývá původem slova bug a debugging podrobněji.

Nástroje

editovat

Ladění je obecně velmi zdlouhavý a únavný úkol. Zkušenosti programátora s laděním pravděpodobně nejvíce ovlivňují schopnost odstranit problém, ale obtížnost ladění softwaru se značně liší i dle použitého programovacího jazyka, dostupných nástrojů, jako jsou debuggery apod. Debuggery jsou softwarové nástroje, které umožňují programátorovi sledovat průběh programu, pozastavit jej, znovu spustit, nastavit body zastavení (breakpoints), změnit hodnoty v paměti a dokonce v některých případech krokovat program zpět. Pojem debugger také může ukazovat na osobu, která provádí ladění.

Obecně platí, že vyšší programovací jazyky, jako je Java, provádí ladění snáze, protože mají takové vlastnosti, jako je zpracování výjimek, které jsou schopny snáze nalézt v aktuálních zdrojích kód s nevypočitatelným chováním. U nižších programovacích jazyků, jako je C nebo Jazyk symbolických adres, mohou chyby způsobit skryté problémy, jako jsou přepsání paměti (memory corruption), a je často velmi obtížné zjistit, kde se původní problém vyskytl. V těchto případech může být zapotřebí nástroj jako je paměťový debugger (memory debugger).

V určitých situacích může být výhodné použití všeobecných softwarových nástrojů, které jsou schopny reagovat na specifický jazyk. Nazývají se nástroji pro statickou analýzu kódu. Tyto nástroje hledají ve specifickém souboru známé běžné i vzácné problémy, vyskytující se v obsaženém zdrojovém kódu. Všechny tyto problémy by dokázaly nástroje, jako je kompilátor nebo interpret, odhalit jen vzácně, protože se nejedná o chyby v syntaxi, ale spíše v sémantice. O některých nástrojích výrobci tvrdí, že jsou schopny detekovat až 300 problémů + unikátní problémy. Komerční i bezplatné nástroje pak existují pro různé jazyky. Tyto nástroje mohou být velmi užitečné při kontrole velmi velkého počtu souborů, kde je nepraktické, aby se kód procházel a kontroloval ručně. Typickým příkladem detekce problému, by mohla být dereference proměnné, ke které dochází, pokud je jí přiřazena hodnota. Dalším příkladem by mohlo být provedení silné typové kontroly, pokud samotný jazyk tuto kontrolu sám nevyžaduje na takové úrovni. Proto jsou tyto nástroje lepší v lokalizaci pravděpodobné chyby, než skutečné chyby. Výsledkem je, že mají pověst vytváření falešných poplachů. Příkladem může být nástroj lint pro kontrolu zdrojových kódů v jazyce C.

Pro ladění elektronického hardwaru stejně jako softwaru, fungujícího na nízké úrovni (např. BIOSy, ovladače zařízení) a firmware, se používají jednotlivě nebo v kombinaci nástroje, jako jsou osciloskopy, logické analyzátory nebo obvodové emulátory (ICE). ICE může provádět mnoho z úloh typických pro softwarový debugger na softwaru a firmwaru na nízké úrovni.

Ladění procesu

editovat

Výpis ladění je pozorováním (živých nebo zaznamenaných) hlášení, které indikují průběh provedení procesu.

Prvním krokem při ladění je pokus o reprodukci (zopakování) problému. To nemusí být triviální úkol, například v případě paralelních procesů nebo některých neobvyklých softwarových chyb. Také záleží na konkrétním uživatelském prostředí, historii práce a nastavení systému. Všechny tyto a další aspekty mohou zkomplikovat snahu o vyvolání stejného problému.

V okamžiku, kdy se podaří problém zopakovat, je třeba zjednodušit vstup do tohoto programu, aby se snáze provádělo ladění. Například chyba v kompilátoru se může projevit, až když se provádí parsování velikého zdrojového souboru. Avšak po zjednodušení testovaného případu může postačit jen pár řádků z původního zdrojového kódu k tomu, aby byla stejná havárie napodobena. Takové zjednodušení lze provést ručně, přístupem „rozděl a panuj“. Programátor odstraňuje některé části z původního testu a kontroluje, zda se problém stále ještě vyskytuje. Při ladění problému v GUI se programátor snaží přeskočit některé akce uživatele z původního popisu problému a zjišťuje, zda zbývající opatření stále působí příslušnou chybu. Testování lze zjednodušit automatizovanými testy, kdy lze použít např. delta debugging.

V okamžiku, kdy je testovaný případ dostatečně jednoduchý, může programátor používat debugger, zkoumat stavy (hodnoty proměnných, zásobník volání) a hledat původ celého problému. Jako alternativu lze použít trasování programu (tracing). V jednoduchém případě je trasování pouze několik vypsaných hlášení, které zobrazí hodnoty proměnných v určitých bodech vykonávání programu.

Vzdálené ladění (remote debugging) je způsob odstraňování chyb, kdy laděný program běží na jiném systému, než kde je umístěn debugger. Pro spuštění vzdáleného ladění se debugger připojí ke vzdálenému systému přes počítačovou síť. Po připojení může debugger kontrolovat plnění programu na vzdáleném systému a získat informace o jeho stavu.

Post-mortem ladění (post-mortem debugging) je laděním výpisu z procesu. Výpis z vyhrazeného prostoru procesu bývá možné získat automaticky od systému nebo ručně pomocí interakce uživatele. Výpisy z havárií (výpisy z jádra) jsou často generovány, až když je proces ukončen kvůli neošetřené výjimce.

Anti-debugging

editovat

Anti-debugging je „zavedením jedné nebo více technik do počítačového kódu, které brání pokusům o reverzní inženýrství nebo ladění finálního programu“. Existuje několik typů těchto technik:

  • API: ověří přítomnost debuggeru pomocí standardních systémových funkcí
  • Výjimky: kontrola modifikace obsluhy výjimek
  • Skupiny procesů a vláken: kontroluje, zda se skupinami procesů nebo vláken nebylo manipulováno
  • Pozměněný kód: kontrolujte, zda kód není pozměněn debuggerem, který vkládá do kódu breakpointy
  • HW registry: kontrola nastavení hardwarových breakpointů v registrech CPU
  • Časování a latence: zkontroluje čas potřebný pro provedení instrukcí

Ladění může být omezeno pomocí jedné nebo více z výše uvedených technik. K dispozici je mnoho anti-debugging technik, které dokáží dostatečně chránit software proti většině hrozeb.

Reference

editovat
  1. PORTER ADAMS, Vicki. Captain Grace M. Hopper: the Mother of COBOL. InfoWorld [online]. 1981-10-05 [cit. 2020-11-08]. Dostupné online. (anglicky) 
  2. KIDWELL, P.A. Stalking the elusive computer bug. S. 5–9. IEEE Annals of the History of Computing [online]. 1998 [cit. 2020-11-08]. Roč. 20, čís. 4, s. 5–9. Dostupné online. DOI 10.1109/85.728224. (anglicky) 

Související články

editovat

Externí odkazy

editovat