Hlavní navigace

Segmentation fault. Core dumped.

Michal Krause

S hláškou, kterou jsem si zapůjčil do nadpisu dnešního článku nebo s nějakou hodně podobnou se dříve nebo později setká snad každý, kdo pracuje s některým un*xem. Jádro nám tak oznamuje, že program zhavaroval. Někteří z nás propadají záchvatům zuřivosti, když ji vidí na svém monitoru, ale zoufalství není na místě. Programátor má totiž jisté prostředky, jak riziko pádu svého programu minimalizovat.

C neboli céčko, je a ještě dlouho bude zřejmě nejpoužívanějším programovacím jazykem této planety. Důvody jsou k tomu dva.
Tím prvním je přenositelnost na úrovni zdrojového kódu. Teď se asi mnoho lidí ironicky ušklíblo a někteří čtenáři již ťukají ve svém oblíbeném mailovači zprávu, ať se podívám na Javu (Perl, Python, …), pokud chci vědět, jak má přenositelnost vypadat. Vím, že napsat program v C tak, aby byl plně přenositelný, je obrovsky složité, ale byl bych rád, aby se nezapomínalo, že céčko je v pořadí hned nad assemblerem. Je to v podstatě nízkoúrovňový jazyk a na této úrovni je samozřejmě kompatibilita platforem prakticky nulová, stačí už jenom rozdílné délky základních typů (někde je int 32bitový, jinde 16bitový), endianita a podobně. Nic to však nemění na tom, že je jazyk C pevně definovaný normou a kdyby to nekomplikovali výrobci kompilátorů nedodržováním standardů, bylo by možné naprostou většinu problémů řešit prostředky jazyka (místo abych počítal s tím, že int má 4 bajty, použiju zkrátka sizeof(int)), což ovšem klade zvýšené nároky na kázeň programátora.
Druhým důvodem oblíbenosti jazyka C je jeho flexibilita a možnosti. Konec konců, i zmiňovaná Java, Perl či další jazyky, respektive jejich kompilátory nebo interpretry jsou napsané v céčku. Programátor není omezován high-level obalem, což umožňuje vysokou pružnost a efektivitu. Ano, na druhou stranu je to samozřejmě i příčinou vyšší složitosti řešení relativně jednoduchých úkonů, neboť většina zodpovědnosti je přesunuta na programátora. Krásným příkladem je následující kód v Perlu a v C, který dělá dočista totéž, přečte jednu řádku z klávesnice a vypíše její obsah na obrazovku.

V Perlu:

        $s = <STDIN>;
        print("$s");

a v céčku:

        char    *s;

        s = malloc(10);
        if (fgets(s, 10, stdin) != NULL)
                printf("%s", s);
        free(s);

I kdybych nakrásně ponechal alokaci a uvolnění paměti pro řetězec „s“ na kompilátoru mírně odlišným zápisem kódu, je na první pohled vidět, že zatímco v Perlu se programátor nemusí starat o délku řetězce, v céčku je omezen tím, jak velký blok paměti je pro proměnnou přidělen (v našem případě 10 znaků včetně ukončovacího znaku 0).
Když si programátor s uvedeným kódem pohraje, dokáže samozřejmě zajistit, že se bude proměnná „s“ dynamicky „natahovat“ a třeba i zmenšovat podle potřeby. Bude to rychlé, bude to úsporné, ale bude to také potenciálně nebezpečné. Dojde-li při operacích s paměti k chybě, může být program jednak jádrem ukončen a jednak lze některé takové chyby (například v síťových službách) zneužít až k získání přístupu do systému, pokud víte, jak na to.

Obvyklé problémy jsou tři: přetečení/podtečení (češtináři prominou) bufferu (potenciální bezpečnostní díra), zápis/čtení mimo oblast paměti příslušící procesu (vedoucí obvykle k pádu programu) a neuvolnění přidělené paměti (způsobující zejména u dlouhodobě běžících démonu „nafukování“ programu a zbytečné plýtvání pamětí). Všechny tři chyby je bezpodmínečně nutné řešit. Jenže jak na to?

Relativně nejjednodušší je hledání chyb, kdy proces zapisuje nebo čte zcela mimo jeho vyhrazenou paměť. To způsobí vždy pád programu, neboť takovou operaci jádro vůbec nepřipustí. Při násilném ukončení procesu je na disk uložen do souboru core obsah paměti, kterou měl proces alokovanou. Pokud byl program zkompilován s ladícími informacemi, lze pak pomocí standardního debuggeru (např. gdb) snadno zjistit, na kterém řádku kódu program zhavaroval.

Někdy se ale stane, že program zkolabuje a gdb pak tvrdí, že spadl na nějaké zcela bezpečné operaci (například něco jako i = a * 2). V tomto případě si můžete být na 99% jist, že váš program někde za svého běhu přepsal paměť, kterou neměl. To může způsobit například změnu návratové adresy, takže program při opouštění podprogramu skočí úplně jinam, než by měl. Důsledkem je téměř vždy nelogické chování programu, ale občas se dokonce stane, že vše zdánlivě funguje dobře a chyba se projeví třeba až na jiném počítači. Pro odhalování podobných chyb jsou určeny speciální knihovny, kterým se někdy říká buffer overrun debugger. Takovou knihovnu přilinkujete k vašemu programu a tím máte zajištěno, že program spadne přesně ve chvíli, kdy k přetečení bufferu dojde. Pak již následuje výše zmíněné zkoumání core souboru vedoucí již tentokrát k odhalení skutečné chyby.
Asi nejznámější je knihovna Electric Fence, která je používána i v mnoha komerčních společnostech. Osobně s ní mám jenom ty nejlepší zkušenosti a vřele doporučuji vždy ozkoušet vaše programy s touto knihovnou, neboť jde o záležitost velice ošidnou a tento postup vám jistě ušetří mnohé starosti s rozzuřenými uživateli, kterým váš program nebude fungovat :)

Existují však i knihovny, které umí mnohem víc, než jenom detekovat přetečení bufferu. Jednou z nich je dmalloc. Tento „memory debugger“ jsem objevil teprve nedávno a vlastně jsem původně chtěl psát jenom o něm, ale nakonec jsem si řekl, že to vezmu obecněji.
Dmalloc dokáže hlavně výborně detekovat třetí zmiňovanou chybu, kterou je neuvolňování přidělené paměti. Program s přilinkovanou knihovnou dmalloc zapíše těsně před ukončením běhu programu do logu informace o neuvolněných blocích paměti. Pokud do zdrojového kódu vložíte pomocí řádku #include <dmalloc.h> hlavičkový soubor náležící ke knihovně, získáte z logu dokonce i přesnou informaci o tom, na kterém řádku zdrojáku došlo k alokaci paměti, jež nebyla uvolněna. Bez rekompilace programu (pomocí proměnné prostředí) můžete nastavovat parametry, kterými se řídí chování dmallocu, jako je například míra logování událostí. Lze nastavit množství různých testů, mezi nimi i ten na přetečení bufferu, ale přeci jenom je v tomhle o něco lepší Electric Fence. Výhodou je podpora multithreadových aplikací a částečně i C++.

Použití dmallocu mělo u mě v několika případech ještě jeden blahodárný vliv (i když možná nechtěný nebo náhodný). Když jsem totiž použil některé funkce pro práci s řetězci s omezenou délkou (například strncpy nebo strncat, nedoplnila se na konec cílového řetězce ukončovací nula (což je běžné chování těchto funkcí). Bez dmallocu program vypadal, že funguje, ale s ním dělal v těchto fázích doslova psí kusy. Zkoumáním jsem pak chybu odhalil a potřebný znak doplnil ručně. Jsem si jist, že ať už na mém či některém jiném počítači by se tato chyba dříve či později projevila i za běžného provozu.

Pokud tedy programujete v céčku a nechcete se i přes občasné těžkosti vzdát jeho možností (a také třeba rychlosti výsledných programů), měli byste rozhodně při své práci používat některé pomůcky pro ladění operací s pamětí. Já osobně nedám na kombinaci dmalloc a Electric Fence dopustit.

P.S. Kombinací myslím samozřejmě použití obou produktů, ale zvlášť. Kombinování více ladících nástrojů tohoto typu v jednom programu způsobí jedině problémy.

Našli jste v článku chybu?

18. 9. 1999 16:30

Stanislav Meduna (neregistrovaný)

Nemam skusenosti s dmallocom, ElectricFence som vsak
pred casom pouzit skusil. Bohuzial sa kvoli svojmu sposobu hodi
len na velmi male programy. Pokial jeho cinnost spravne
chapem, pouzije pre kazdy malloc minimalne jednu stranku
pamati - to sice umoznuje pristupy krasne kontrolovat,
ale pokial si program naalokuje 100000 objektov (a to
zvlast programy v C++ robia), vyslednych 400 MB zabranej
virtualnej pamati uz sposobi problemy na vacsine instalacii.
Komercne systemy (memory advisor v Unix sve…







120na80.cz: Rovnátka, která nejsou vidět

Rovnátka, která nejsou vidět

Lupa.cz: Levný tarif pro Brno nebude, je to kartel

Levný tarif pro Brno nebude, je to kartel

Root.cz: Nová třída SD karet A1 s vysokým výkonem

Nová třída SD karet A1 s vysokým výkonem

DigiZone.cz: R2B2 a Hybrid uzavřely partnerství

R2B2 a Hybrid uzavřely partnerství

DigiZone.cz: V Plzni odstartovalo Radio 1

V Plzni odstartovalo Radio 1

Lupa.cz: Co se dá měřit přes Internet věcí

Co se dá měřit přes Internet věcí

Lupa.cz: Obchod budoucnosti je bez front, košíků i pokladen

Obchod budoucnosti je bez front, košíků i pokladen

Vitalia.cz: Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Lupa.cz: Kdo pochopí vtip, může jít do ČT vyvíjet weby

Kdo pochopí vtip, může jít do ČT vyvíjet weby

Podnikatel.cz: Chaos u EET pokračuje. Jsou tu další návrhy

Chaos u EET pokračuje. Jsou tu další návrhy

DigiZone.cz: Sat novinky: slovenská TV8 HD i ruský NTV Mir

Sat novinky: slovenská TV8 HD i ruský NTV Mir

Podnikatel.cz: Udávání a účtenková loterie, hloupá komedie

Udávání a účtenková loterie, hloupá komedie

DigiZone.cz: Ohrozí Freedom TV přechodové sítě?

Ohrozí Freedom TV přechodové sítě?

Vitalia.cz: Potvrzeno: Pobyt v lese je skvělý na imunitu

Potvrzeno: Pobyt v lese je skvělý na imunitu

DigiZone.cz: Česká televize mění schéma ČT :D

Česká televize mění schéma ČT :D

Lupa.cz: Insolvenční řízení kvůli cookies? Vítejte v ČR

Insolvenční řízení kvůli cookies? Vítejte v ČR

Vitalia.cz: Jak vybrat ořechy do cukroví a kde mají levné

Jak vybrat ořechy do cukroví a kde mají levné

Root.cz: Certifikáty zadarmo jsou horší než za peníze?

Certifikáty zadarmo jsou horší než za peníze?

Měšec.cz: Exekuční poradna: ptejte se online

Exekuční poradna: ptejte se online

120na80.cz: Horní cesty dýchací. Zkuste fytofarmaka

Horní cesty dýchací. Zkuste fytofarmaka