Debugov ání v C/C++

1. Debugování v C/C++

2. Co musíme však nejdříve udělat? • Přeložit program s debug informacemi • Umožníme přidáním volby –g do překladače POZOR!!! Pokud se program skládá z více modulů ( .o souborů) je potřeba přidat volbu –g při tvorbě každého takového modulu

3. Co by jsme naopak dělat neměli • Debugovat programy které jsme prohnali přes optimalizující překladač • Tj. pokud budu debugovat tak nepřidávám volbu –o ( a už vůbec ne -o2 -o3 ) • Pokud tak učiníme tak debugovaný program bude odlišný od toho který máme před sebou ve zdrojovém textu

4. Rozdíl debbugování v C oproti C++ • C++ umožňuje používat šablony. Tj. při pádu programu přidává i názvy šablon • C++ umožňuje dědičnost a špatně se dohledává pokud je chyba ve virtuální destruktoru některé z nadřezených tříd • Debuggování v C++ je tudíž trošku těžší a někdy velice nepřehledné

5. Jaké máme možnosti ? • Debugovat ze souboru vzniklých při pádu programu • Debugovat přímo spuštěný program

6. Debugování z core-dumpu 1 • Musíme nejdříve donutit OS tvořit core-dumpy - Zvládneme pomocí příkazu “ulimit –c unlimited“ - Příkaz “ulimit“ má spoustu dalších užitečných vlastností ( změna počtu vláken, max. procesorového času apod.)

7. Debugování z core-dumpu 2 • Po spadnutí programu se nám nyní vytvoří soubor core( číslo procesu ) • Tento soubor můžeme nyní předhodit debbugeru a podívat se kde se stala chyba • Provedeme pomocí: gdb ( název programu ) ( coredump )

8. Debugování z core-dumpu 3 • Nyní když jsme v debbugeru tak vidíme řádek na kterém se stala chyba • Zadáme teda příkaz “bt“ ať vídíme kde přesně se stala chyba a jaké volání funkcí jí předcházelo

9. Debugování z core-dumpu 4 • Další příkazy které se mohou hodit • ptype ( typ proměnné ) • print ( název proměnné nebo výraz ) • set print pretty print struktura->jmeno p pole[3]@5 • list

10. Debugování z core-dumpu 5 Pozitiva + Nezdržujeme běh programu debbugerem + Debbugujeme až když skutečně víme, že něco spadlo Negativa - Né každý pád programu tvoří coredump ( např. signál pipe ) - Z coredumpu debbuger nikdy nezíská tolik informací jako přímo při běhu programu

11. Debugování za běhu 1 • Můžeme používat přímo a nepotřebujeme k němu žádný coredump • Musíme však počítat s někdy mnohonásobně větší zátěží při běhu programu

12. Debugování za běhu 2 - GDB • Možnost číslo 1 – použijeme gdb • Tuto možnost velice nedoporučuju. Osobně používám na debugování gdb v “bojových situacích“ • Podíváme se teda na pár užitečnách příkazů které můžou pomoc

13. Debugování za běhu 3 - GDB • Nejdříve spustíme program pod gdb gdb ( název programu) • Takto spuštěný program je zatím zastavený. Spustíme ho tedy příkazem run ( argumenty z příkazové řádky )

14. Debugování za běhu 4 - GDB • Breakpointy • break ( číslo řádky ) • break ( název funkce ) • clear ( číslo řádky / název funkce ) • Info breakpoints • Krokování • next • continue

15. Debugování za běhu 5 - strace • Strace je prográmek který nám sobrazuje veškeré systémové volání • Hodí se tedy pokud chceme vyzkoumat co program volal a s jakými argumenty a nebo kvůli čemu a kde dostal signál • Pokud tušíme, že nám program zhodil nějáký signál je toto nejlepší program na nalezení problému

16. Debugování za běhu 6 • Všechny předchozí programy jsou užitečné ale nezobrazují všechny užitečné informace. • Např. Nevíme kde jsme uvolnili proměnnou do které jsem se pak pokusili něco napsat • Nekontolují memory-leaky apod.

17. Debugování za běhu 6 - strace • Použití strace ( název programu ) • Na obrazovce pak uvidíme postupně všechna volání i s parametry

18. Debugování za běhu 7 - valgrind • Valgrind je užitečný prográmek který kontroluje veškeré operace s pamětí • Odborně – Program na kontrolu konzistence heapu • Asi nejlepší ze všech programů na debugování • Bohužel zatím použitelný jen pod Linuxem

19. Debugování za běhu 7 - valgrind • Program není ve standratní knihovně a porot ho musíme stáhnout z internetu • Např z. www.valgrind.org • apt-get install valgrind ( Debian ) • yum install valgrind ( Red Hat )

20. Debugování za běhu 8 - valgrind • Program se skládá z několika částí kde každá se soustředí na jiný druh problémů • Nejvíce používané jsou • error-check • leak-check

21. Debugování za běhu 9 - valgrind • Pokud valgrind spustíme bez jakýchkoliv parametrů tak použijeme modul pro kontrolu chyb • Použití valgrind ( název programu )

22. Debugování za běhu 10 - valgrind • Ve výpise se nám pak zobrazí chyby • Proměnné bez defaultních hodnot • Dvojí uvolnění paměti • Zápis mimo paměť • Přepis paměti • Zápis do paměti kterou jsme nealokovali

23. Debugování za běhu 10 - valgrind • Nejlepší je, že valgrind nám i ukáže proč k chybě došlo! • Například pokud zapisujeme do předtím uvolněné paměti tak nám i ukáže místo kde jsme jí uvolnili • Pokud zapisujeme mimo alokovanou oblast tak nám ukáže o kolik jsme se přepsali a kde máme zaalokovat více místa

24. Debugování za běhu 11 - valgrind • Dalším skvělým modulem je kontrola memory-leaků • Stačí spusti valgrind s jinou volbou valgrind --leak-check=full ( název programu ) • Valgrind nám nyní ukáže všechnu paměť kterou jsme alokovali ale neuvolnili a taky paměť na kterou se již nemůžeme dostat

25. Debugování za běhu 12 Pozitiva + Máme mnohem více informací + Můžeme ovlivňovat chování programu + Valgrind ;) Negativa - Běh s debbugerem je mnohonásboně náročnější než bez debbugeru

26. IDE • Další věc která se pro debugování hodí jsou různá IDE • Z vlastní zkušeností můžu doporučit Eclipse s pluginem pro C/C++ • Další skvělý nástroj je KDevelop který v sobě integruje strace/GDB/valgrind a spoustu dalších užitečných věcí

27. Shrnutí • Pokud jsem si jistý, že v programu už nemám chybu tak mi stačí ladění z coredumpu • Pokud potřebuju ladit intenzivně tak nechám běžet program pod debbugerem

28. Děkuji za pozornost