Dotaz: Jak najít uniklou paměť (leaky)

[ček]

Ahoj. Zajímalo by mě, jestli a jak je možné najít v běžícím programu (napsaném např. v C) paměť, na kterou už neukazují žádné ukazatele, ale nebyla uvolněna? Takhle vlastně vzniknul memory leak a mám teoreticky nepoužitelnou paměť. Nicméně operační systém ví, kterou paměť má proces alokovanou, takže by to mohlo jít čistě teoreticky zjistit i v běžícím programu, jenže jak?

---

---

Odpovědi

[pesspi]

valgrind

[petr_p]

Tazatel ale chce řešit již běžící proces.

[petr_p]

Ahoj. Zajímalo by mě, jestli a jak je možné najít v běžícím programu (napsaném např. v C) paměť, na kterou už neukazují žádné ukazatele

Nelze, v C nemas zadny reference counter. Proste si alokujes pamet a je na tobe abys ji uvolnil. Valgrind ti muze vypsat kolikrat se zavolal malloc() a kolikrat se zavolal free(), tim muzes zjistit jestli se vsechno uvolnilo.

Nicméně operační systém ví, kterou paměť má proces alokovanou, takže by to mohlo jít čistě teoreticky zjistit i v běžícím programu, jenže jak?

Obecne to neni pravda. Zalezi na alokatoru.

[l4m4]

Upřesnil bych: Operační systém ví, kterou paměť má proces alokovanou z pohledu jádra. To je ale k ničemu. Funkce typu free() (a podobné, v závislosti na alokátoru) normálně pouze vracejí paměť do heapu procesu, která je z pohledu jádra celá alokovaná tomu procesu. Neděje se žádné volání brk(), kterým by se proces zase datovou část adresního prostoru zmenšil. Operační systém proto až na výjimky nerozpozná, která část paměti je alokovaná a která není z pohledu aplikace.

[ček]

Funkce typu free() (a podobné, v závislosti na alokátoru) normálně pouze vracejí paměť do heapu procesu, která je z pohledu jádra celá alokovaná tomu procesu.

O to mi jde. Zjistit v samotném běžícím programu, jakou všechnu datovou paměť má pro daný proces alokovanou jádro. Pak by čistě teoreticky nebyl problém zjistit, na kterou část paměti už program nemá referenci. Chápu, že je blbost tohle dělat. Zajímá mě to čistě na teoretické úrovni, zda by to šlo naprogramovat.

[Šangala]

Hm, dost těžko, adresa v aplikaci není totožná s fyzickou adresou.

[luky]

Hm, dost těžko, adresa v aplikaci není totožná s fyzickou adresou.

Hm, dost snadne, adresa v jadre je totozna s adresou v aplikaci

cat /proc/PID/maps

[Šangala]

No vida, přemýšlel jsem nad tím špatně…

[l4m4]

Tato informace je v /proc/self/maps (nebo /proc/$PID/maps, pokud to chceš číst jinému procesu).

[petr_p]

Budete zklamaný. Přiblížím Linux na x86:

Každý proces má vlastní virtuální paměť. Na některá místa jsou mapované různé části kódu procesu (program a knihovny) a na některá samotný Linux. Tohle všechno je v podstatě statická věc jen pro čtení. Ta vás vůbec nezajímá. Pak máte různé bloky se sdílenou pamětí (SHM, I/O), to vás ale také nemusí zajímat (kdyby ano, pak byste se na to tady neptal, protože by to pro vás byla trivialita).

A pak jsou už jen dvě velké oblasti. Halda a zásobník. Haldu si proces voláním brk(2) zvětšuje či zmenšuje, ale nikdy do ní nemůže udělat díry. Vždy se jedná o spojitou oblast. Zásobník roste z druhého konce adresního prostoru proti haldě. Ten ovšem z hlediska jádra je předalokován na konkrétní velikost (ulimit(1)) a z principu x86 ABI taky v něm nemohou být díry a navíc si jeho velikost proces (zjednodušeně vzato) nemůže měnit.

Takže když to shrnu, tak jediný zajímavý údaj je velikost haldy. Tedy jedno číslo. Tedy přesně ten údaj který vidí jádro.

[luky]

Ten ovšem z hlediska jádra je předalokován na konkrétní velikost (ulimit(1))

Zasobnik se zvetsuje dynamicky podle toho, jak je vyuzivan (ulimit pouze omezuje maximalni velikost). Pri startu programu zabira pouze jednu stranku.

[Sten]

Jen protože Linux používá overcommit. Když jej vypnete, bude zásobník alokován při spuštění programu celý.

[luky]

Doporucuju si ve zdrojovych kodech vyhledat flag neco_GROWSDOWN (nepamatuju si prefix). Pokud dojde k vypadku a pozadovana stranka neni soucasti mapovani, kontroluje se, jestli je _blizko_. Pokud ano, prislusna stranka se domapuje.

[Sten]

Velké alokace (> MMAP_THRESHOLD, výchozí hodnota je 128 KiB) malloc nebere z haldy, ale použije anonymní mmap, který hned po free zase vrátí. Lepší alokátory vůbec nepoužívají haldu a veškeré alokace dělají právě přes mmapy, právě protože je lze snadno vracet. Tyhle mmapy jsou taky vidět ve výpisu paměti procesu. Jádro ale samozřejmě ani tady neví, co je uvnitř jednotlivých mmapů, které jsou většinou alokovány po velkých blocích (typicky stovky kilobajtů až megabajty), aby se předešlo přílišné fragmentaci, která velmi zpomaluje nové alokace.

[l4m4]

Lepší alokátory vůbec nepoužívají haldu a veškeré alokace dělají právě přes mmapy, právě protože je lze snadno vracet.

Spíš overengineered než lepší, protože to je optimalizace na situaci, že se podaří současně uvolnit všechny bloky z daného mapování a že aplikace pak nebude zase dlouho potřebovat paměť, kterou by šlo získat recyklováním těchto bloků. Jinak to akorát znamená větší množství syscallů a menší možnost konsolidace volných segmentů. Mluvím o použití haldy typickým způsobem, tj. množství menších až středních alokací ‚náhodných‘ velikosti se slabě korelovanými dobami života.

[Šangala]

Pokud nemáte zdrojáky tak jen dynamickou analýzou valgrind, pokud máte zdrojáky můžete použít i statickou analýzu třeba tímto.
OS to neví, ví jen o nadřazeném celku, který je uvolněn chcípne-li aplikace.

[Semo]

Cca pred 9-10 rokmi bol kratky serial o valgrinde na root.cz. Povedal by som, ze aspon 90% z neho je stale aplikovatelne.