Chyby za běhu programu se většinou ladí za pomoci trasovacích nástrojů a ladicích textů. Stejně, jako existují typické kompilační chyby, existují i typické chyby za běhu. Jsou to špatně nastavené cesty, špatně nastavené prostředí a neošetřené výjimečné situace. První dvě z nich lze podchytit bez trasovacích nástrojů a studia kódu. Ale právě bývají natolik časté, že bychom se o nich měli zmínit.
Špatně nastavené cesty
Configure umožňuje změnit instalační cesty pro všechny komponenty programu. Nezřídka je však tato vlastnost v programech nedotažená – konfigurační soubor se pak sice korektně nainstaluje do ${sysconfdir}/program.conf, ale za běhu jej program hledá v natvrdo předepsané/etc/program.conf. Že to je pro některé prefixy jinde, nemusím zdůrazňovat. Pokud takovou chybu neodhalí přímo chybová hláška, často pomůže výstup programu strace. Hledáme v něm příkaz open s výsledkem ENOENT:
strace -o trace.log program
Ve výpisu snadno zjistíme, kde program hledá konfigurační soubory.
Správné řešení je nadefinovat cesty při kompilaci do proměnné CPPFLAGS: -DDATADIR=„$(datadir)“.
Chyby lokalizace
Další častou chybou programů je nesprávná lokalizace. Snadno viditelná je nenastavená kategorie LC_CTYPE. V glibc-2.1 se chyba nijak neprojevovala, ale v glibc-2.2 způsobí, že se místo znaků mimo ASCII zobrazují otazníky. Náprava je snadná: před původní řádek zdrojového kódu
setlocale(LC_MESSAGES, "");
přidáme ještě
setlocale(LC_CTYPE, "");
Mnohem záludněji se projevuje obrácená chyba – nečekané následky nastavení národního prostředí pro čísla – české národní prostředí totiž na oddělení desetinných míst používá čárku a pro funkci scanf ji také vyžaduje. Programy se prozradí většinou podle toho, že v anglickém (ale i německém) prostředí fungují bez problémů, zatímco v českém (nebo litevském) ne. Zde je výčet různých problémů, které měly právě tuto příčinu: nečitelný soubor editoru xfig, problémy s jazykem a kódováním prohlížeče u www serveru apache, nefunkční kalkulačka xcalc či nemožnost pracovat s desetinnými čísly v několika programech.
Řešením je dočasné nebo trvalé nastavení národního prostředí čísel na C:
setlocale(LC_NUMERIC, "C");
Další chybou lokalizace je použití pevně definovaného písma nebo kódování. Bývá jednoduché program zalátat tak, abychom jej mohli použít jen v češtině (prostě přepíšeme řetězec 8859–1 na 8859–2), ale čisté řešení vyžaduje přidání kódu, který kódování nastaví. Do této kategorie chyb patří i chybné překódování (funkce vrací text v UTF-8, ale autor se domnívá, že jde o ISO-8859-x, nebo naopak – výsledkem je zkomolený text – viz např. JavaScript v Galeonu apod.) a nesprávná inicializace X-toolkitu (projevuje se nefunkčností mrtvých kláves nebo znaků mimo ISO-8859–2 či ASCII – viz gnome-terminal pro Gnome2). Oprava těchto chyb však nebývá zdaleka tak triviální, jak to vypadá.
Posílání oprav
Pokud se nám podařilo chybu opravit, měli bychom informaci o tom zveřejnit – právě na tom stojí kvality svobodného softwaru.
Většinou používáme nějakou distribuci – nejprve se tedy podíváme do zdrojových kódů distribuce, zdali naše oprava nesouvisí s distribučně závislými změnami. Pokud ne, pošleme ji autorovi.
Posíláme-li opravu, měla by být co nejkratší a měl by k ní být přiložen popis (nebo číslo) opravené chyby. Nejlepším způsobem, jak zaslat opravu, je vytvořit rozdílový soubor mezi původní a novou verzí programem diff:
diff -u soubor.c.orig soubor.c >záplata.diff
Důležitou informací je i verze programu, kterou opravujeme.
Názory na přesnou podobu záplat se různí podle projektu (např. Linus Thorvalds dává přednost záplatám s aktuálním adresářem nad úrovní hlavního adresáře a se záplatou zařazenou do těla mailu, zatímco někteří jiní mají raději záplatu v příloze).
Rozhodně není dobré do stejného souboru vkládat několik nesouvisejících oprav. Záplata pak bývá méně jasná, zvlášť pokud různé části kódu spravují různí autoři.
Hlášení chyb
Ne vždy máme dostatek zkušeností nebo trpělivosti, abychom chybu našli. Navíc autor programu bývá mnohem lépe orientovaný v kódu a problematické místo rychleji najde.
Před hlášením chyby bychom měli otestovat poslední verzi – nemá smysl hlásit dávno opravené chyby.
Pokud zjistíme, že se jedná o chybu závislou na distribuci, informujeme správce příslušného balíčku. Že jde o chybu distribuce, lze poznat například tak, že v jiné distribuci se tentýž program chová správně, nebo víme, že se týká nesprávné integrace do systému – například volání nepřítomných programů. Správci balíčku chybu hlásíme i tehdy, je-li původní projekt již opuštěn.
V ostatních případech hlásíme chyby autorovi. U větších programů je k tomuto účelu často vytvořená konference nebo webové rozhraní (dnes nejčastěji Bugzilla). Tím zajistíme, že se chybové hlášení dostane k povolané osobě.
Programy na registraci chyb mívají i prohledávatelné archivy. Je rozumné, abychom se před ohlášením chyby pokusili zjistit, zda tutéž chybu nepopsal již někdo před námi. Často v archivu najdeme i opravu anebo zjistíme, že chyba byla na naší straně.
Před hlášením bychom měli co nejpřesněji popsat situace, kdy se chyba projevila. Popíšeme také podobné situace, kdy se chyba neprojevila. Čím jasněji dokážeme chybu popsat, tím snadněji ji bude vývojář reprodukovat nebo alespoň analyzovat.
Některé programy při pádu nabízejí dialog pro trasování chyby. Jeho výpis je pro hledání chyby ve složitých programech velmi důležitý, proto si jej zkopírujeme a přiložíme k chybovému hlášení.
V hlášení popíšeme základní součásti své distribuce (operační systém, platformu procesoru, verzi jádra, kompilátoru a glibc), případně i souvisejících balíků (např. u balíku používajícího KDE i verzi KDE). Usnadní to ty situace, kdy chyba nastává jen pro určité operační systémy, verze jádra, kompilátoru či systému).
Nyní zbývá všechny informace vyplnit a hlášení odeslat. Trasovací systém nám pošle mailem každou poznámku, kterou někdo k naší chybě připsal. Občas budeme vyzváni k dalším experimentům, které by mohly chybu pomoci reprodukovat nebo najít.
Pokud spolupráce dopadne na výbornou, zbývá se jen těšit na novou verzi, která bude mít alespoň o jednu chybu méně…
