Dotaz: Uninteruptible sleep aneb D stav procesu

[nemam]

Prosímvás může mi někdo stručně vysvětlit skutečný důvod, proč když se mi proces sekne na nějaké síťové operaci, a skončí ve stavu uninterruptible sleep, proč ho nejde killnout natvrdo, zahodit jeho alokovanou paměť, vykašlat se na jeho čekání na I/O operaci a zapomenout na něj?

Když tedy udělám proces, který se záměrně bude dostávat do stavu D, zabiju tím systém? Tohle jsem nikdy nepochopil, proč jádro prostě nemůže ten čekající proces utnout a vyhodit natvrdo. K čemu je to dobrý?

Díky za vysvětlení. Proč na toto musím proboha rebootnout? To fakt není možné nějak ošetřit a vyjít z tohoto stavu jednoho dementního seklého procesu?

---

---

Odpovědi

[nemam]

Jasne. Jednalo se o kate editor, ten byl závislej na otevřeném souboru přes sshfs, stačilo killnout sshfs a kate ve stavu uninterruptible sleep sel do haje taky.

Ale proc toto tvrdy chovani? Tohle fakt nechapu. Proste killnu kate, at si zavisi na cem chce a nazdar s nim ne? Proc ne? Na datech a jejich konzistenci mi uz v takovem pripade vubec nesejde. Proc ten proces drzet? Totez se zombie procesy. Proc je proboha drzet?

Fakt bych rad kdyby mi to nekdo vysvetlil. Pripada mi to jako strasna blbost tohle.

[Jendа]

Proste killnu kate, at si zavisi na cem chce a nazdar s nim ne?

Tipuju, že zrovna může mít zamčený nějaký zámek v kernelu, a ten pak zůstane zamčený navždy? Netuším, jak jsou věci v kernelu implementované, ale asi nebude obecně pravda, že je lze kdykoli zabít. Ale možná by mohl být nějaký override "ano, opravdu zabít".

[Heron]

Přesný důvod neznám a také si rád počkám na fundovanou odpověď, ale ono se to v praxi neděje tak často.

Nejčastěji (vlastně výhradně) jsem se s tím setkal u neodmountovaného NFS, kdy někdo vypne NFS server, ale neodmountuje klienty. Vtip je v tom, že ten server stačí prostě jen opět zapnout nebo připojit do sítě a jede se vesele dál. Tj. místo bezhlavého střílení všech procesů ve stavu D je vhodnější vyřešit ten NFS server*. Všechno, klidně i po pár hodinách, potom vesele jede dál. V praxi je (asi) fakt málo případů, kdy D nelze vyřešit a snad ve většině případů to ukazuje na chybu někde jinde. Takže než dát adminům do ruky další nástroj, jak přijít o data, je lepší je takto taktně upozornit.

*) Ostatně já doma taky neodpojuju NFS při rebootu serveru. Až nabootuje, tak se pokračuje dál.

[Josef Kufner]

Btw, když dáš NFS mountu volbu soft, tak umí prostě vrátit IO chybu.

[Heron]

Jo, ale tohle se ne vždy hodí a může to vést k poškození dat (program neví, co je a co není zapsané - i když správně by měl stejně počkat až na dokončení flush).

[MP]

Tak kdyz nekdo pouzije async se soft...tak mu neni pomoci.

[j]

To neni o sitovy operaci, to je o IO operaci (cteni/zapis). Naprosto bezne na to narazis na zatizenych discich nebo na srackodiscich (vsemozny usb dngly/sd karty atd). Jen vetsinou nakonec IO operace dobehne, takze to zmizi samo.

Nezabitelny je to jakoze proto aby ti to nezkurvilo data, coz je ti ovsem khovnu, kdyz kvuli tomu pak musis stejne strelit celej system ;D.

Jo, pokud takovej proces namnozis, tak naprosto vpohode dojdes do stavu totalniho vycerpani ram/cpu/...

A resitelny to prej je, prej mas prepsat tu appku nebo kus kernelu ... ;D.

---

Dete s tim guuglem dopice!

[Michal Kubeček]

Když tedy udělám proces, který se záměrně bude dostávat do stavu D, zabiju tím systém?

To není tak jednoduché, rozhodnutí, zda bude proces spát přerušitelně ("S", TASK_INTERRUPTIBLE) nebo nepřerušitelně ("D", TASK_UNINTERRUPTIBLE) je na kódu jádra, který se ho rozhodne při čekání uspat. Uninterruptible sleep se typicky používá tam, kde se neočekává, že se bude čekat moc dlouho, a úklid stavu při přerušení by byl komplikovaný.

Tohle jsem nikdy nepochopil, proč jádro prostě nemůže ten čekající proces utnout a vyhodit natvrdo.

Např. proto, že ten proces drží nějaký mutex, takže kdyby se jen tak "odstřelil", jak si představujete, zůstal by ten mutex natrvalo zamčený a každý proces, který by si ho potřeboval vzít, by se od té chvíle "seknul" úplně stejný. (Mohou být i jiné důvody, ale tohle je doufám dostatečně názorné.)

Na druhou stranu, už poměrně dlouho lze použít TASK_KILLABLE, kdy je sice stále blokovaná většina signálů, ale proces lze zabít pomocí SIGKILL. Používá se tam, kde je sice žádoucí, aby byl spánek nepřerušitelný běžnými signály, ale proces lze v případě potřeby bezpečně zabít. Na výstupu ps nebo top to ale poznat není, oboje se ukazuje jako "D".

To hlavní, co je potřeba mít na paměti, je, že uninterruptible sleep není samoúčelný, vývojáři ho nepoužívají, pokud k tomu nemají dobrý důvod. Také by v tomto stavu proces neměl být dlouho a pokud je, znamená to, že je něco špatně. Buď došlo k deadlocku (což znamená bug) nebo je systém z nějakého důvodu přetížený, např. příliš mnoho konkurenčních požadavků na stejné I/O zařízení nebo příliš plná paměť (a neustálé čekání, až se něco "odswapuje", aby se uvolnily stránky potřebné pro aktuálně běžící procesy).

[nemam]

Např. proto, že ten proces drží nějaký mutex, takže kdyby se jen tak "odstřelil", jak si představujete, zůstal by ten mutex natrvalo zamčený a každý proces, který by si ho potřeboval vzít, by se od té chvíle "seknul" úplně stejný. (Mohou být i jiné důvody, ale tohle je doufám dostatečně názorné.)

Coz je nesmysl, protoze pokud by mutex respektoval to, kdo ho vytvoril, tak sestreleny proces, pokud prestane existovat, by uz dany mutex proste nedrzel a operace by byla vyrizena, vysledek nepotrebny, tedy mutex by se mohl s klidem odmutexovat a dalsi procesy by mohly nerusene dal fungovat. Vysledek IO operace uz v takovem pripade nikdo nepotrebuje. Neco jak kdyz v jistych jazycich otevru a zamknu soubor a skoncim bez uzavreni a odemceni, taky nezustane natrvalo takovy soubor zamceny a otevreny, neb by to delalo dost bordel a komplikace v systemu takove chovani. A proste stav D je komplikace vcelku radna nekdy. Napriklad u toho kate se seklym sshfs totiz dalsi spusteny kate je sekly taky i kdyz sshfs uz bezi novy a funkcni. A ja si osobne myslim, ze jadro by melo byt chytrejsi nez aplikace a nenechat se aplikaci jakkoliv rozrusit, takze by melo mit moznost zabit proces at se deje co se deje. Jinak to muze skoncit uplnym zahlcenim systemu, pokud to aplikace budou delat naschval, tedy za ucelem dostat mnoho svych procesu do stavu D.

[Michal Kubeček]

Pokud na toto téma chcete opravdu diskutovat a ne jen hořekovat nad tím, jak je jádro úplně špatně navržené, bylo by vhodné, abyste si pro začátek nastudoval aspoň něco málo o tom, jak ty věci fungují a proč. Ono by sice teoreticky bylo možné, aby mutex opravdu fungoval tak, jak si to představujete, ale existují dobré praktické důvody, proč to tak není (především efektivita).

A proste stav D je komplikace vcelku radna nekdy.

Zkusím to vysvětlit ještě jednodušeji: to, že nějaký proces setrvává delší dobu v "D" stavu, není skutečný problém, ale jen symptom (a důsledek) vážnějšího problému někde jinde. Ať už je tím problémem bug nebo prostě jen přetížení určité části systému a ať už je problém trvalý nebo jen dočasný, měl byste řešit ten skutečný problém, ne nějaký "stav D". Stejně jako když vám dojde místo na filesystému, začnou vám různé programy hlásit podivné chyby, protože nemají kam zapisovat data; ale problémem nejsou chybová hlášení těch programů, skutečný problém je plný filesystém. Tohle je úplně stejné.

[Jendа]

tak sestreleny proces, pokud prestane existovat, by uz dany mutex proste nedrzel a operace by byla vyrizena, vysledek nepotrebny, tedy mutex by se mohl s klidem odmutexovat a dalsi procesy by mohly nerusene dal fungovat

Co když to byla zapisovací IO operace a proces zrovna v okamžiku sestřelení modifikoval třeba nějaký B strom?

[Josef Kufner]

A co kdyby mu zrovna vypadla elektřina?

Je to stejný problém. Program musí počítat s tím, že neatomická operace neproběhne celá. Pokud s tím nepočítá, je to bug a má být opraven. Tedy pokud přepočítává strom, tak si ho má přepočítat a pak vyměnit starý, nebo má jednotlivé úkony dělat tak, aby později mohl navázat v jakémkoliv okamžiku výpočtu (a třeba i nějakou část počítat znovu), nebo alespoň musí být schopen detekovat, že ten výpočet nedoběhl a spustit ho znovu celý. Například editory napřed zapíší soubor vedle a pak ho přejmenují na ten původní (což už je atomická operace). Není na tom nic komplikovaného, jen se na to nesmí úplně kašlat.

D stav je prostě špatné řešení teoretického problému. Daná operace má skončit s chybou. Ten proces třeba může chtít nepovedený zápis nahlásit, nebo si data odložit jinam a počkat až bude síťový disk dostupný.

[Michal Kubeček]

A co kdyby mu zrovna vypadla elektřina?

To je irelevantní. On je totiž ten Jendův příklad spíš zavádějící, důvod, proč je při určitých operacích potřeba mít TASK_UNINTERRUPTIBLE (ale ne TASK_KILLABLE, zmínku o němž zatím všichni statečně ignorují) není nekonzistence data na disku, to by opravdu nedávalo smysl. Bývá to spíš nekonzistentní stav běžícího systému nebo nekonzistentní stav nějakého zařízení. V takovém případě výpadek elektřiny, reset nebo panic nevadí, ale kdyby proces najednou "zmizel" be řádného úklidu, byl by to problém.

D stav je prostě špatné řešení teoretického problému.

Tak ještě jednou: TASK_UNINTERRUPTIBLE není "špatné řešení", je to prostě stav. Stav, ve kterém jsou blokovány signály, nic víc, nic méně. Toho, co se musí provést při "odstřelení" procesu, je už takhle poměrně dost a kdyby bylo potřeba v kterémkoli okamžiku umožnit okamžité ukončení, mělo by to vliv na výkon, který je obecně považován za nepřijatelný.

A to se pořád ještě bavíme jen o TASK_UNINTERRUPTIBLE & !TASK_WAKEKILL. Pokud to je možné, používá se TASK_KILLABLE = TASK_UNINTERRUPTIBLE | TASK_WAKEKILL, kdy se sice blokují signály, ale proces lze ukončit pomocí SIGKILL. On totiž zdaleka ne každý syscall vůbec počítá s tím, že může být přerušen signálem a vrátit EAGAIN.

Ale především by asi bylo dobré znovu zopakovat poslední odstavec komentáře z 19.8. 12:35. A opakovat ho tak dlouho, dokud ho ti, kdo tu pořád opakují, jak je "stav D špatné řešení" nevstřebají.

[Josef Kufner]

Tím jen nepřímo říkáš, že systém je příliš křehký a ta či ona komponenta si neporadí s nekonzistentním stavem. Tedy že jedno špatné řešení je maskováno druhým špatným řešením. Moc náročný úklid je jen výmluva; nekonzistentní stav stačí detekovat a odstranit, zařízení resetovat – není to něco co by se dělo často, jen při selhání, kdy je stejnak potřeba věci opravit.

[Michal Kubeček]

Tím jen nepřímo říkáš, že systém je příliš křehký a ta či ona komponenta si neporadí s nekonzistentním stavem.

Klidně si tomu tak můžete říkat, pokud chcete. Samozřejmě že by se to teoreticky dalo udělat i tak, aby to fungovalo tak, jak si představujete, ale výsledek by byl zoufale neefektivní. Pro každý mutex byste musel někde zaregistrovat, že se má odemknout. Pro každou referenci, kterou může task v danou chvíli držet, byste musel někde zaregistrovat, že se má vrátit. Ale pozor, to všechno včetně těch, které držel už volající v úplně jiné části jádra, takže ta registrace by se pravděpodobně musela provést už při každém zamknutí mutexu nebo vzetí reference. Kdo má trochu představu, co obnáší zamknutí mutexu nebo refcount_inc(), musí mu být jasné, že to je naprostý nesmysl, protože byste tím z jednoduché a efektivní operace udělal zoufale pomalého molocha. A to jsou jen dva triviální příklady, zrovna tak byste musel evidovat další spoustu zdrojů, a to nejen těch univerzálních, ale i různé specifické pro konkrétní subsystémy nebo drivery.

A i kdybyste to nakrásně realizoval a zbavil se všech uninterruptible sleepů, ve skutečenosti byste tím nevyřešil vůbec nic. Protože k tomu, aby proces byl "nesestřelitelný", totiž vůbec nepotřebujete ten uninterruptible sleep. Z úplně stejných důvodů (bug, nešťastný návrh nebo přetížení) může proces třeba čekat na spinlock; pak sice neuvidíte ten "ošklivý a chybně navržený stav D", budete tam mít nádherné "R", ale nesestřelitelný bude úplně stejně.

Možná by bylo lepší si připustit, že oni ti vývojáři jádra (a všech unixových OS před Linuxem a vedle něj) možná nejsou taková banda úplných pitomců, která za ty desítkly let nepochopila to, co je vám úplně jasné hned od pohledu.

[Josef Kufner]

Například https://lwn.net/Articles/288056/ také potvrzuje, že uninterruptible sleep, minimálně v případě IO, je o mizerném ošetřování chyb.

[Michal Kubeček]

Vůbec ne. Je ironické, že jste si jako argument našel zrovna článek informující o (tehdy) nové featuře TASK_KILLABLE, o které jsem tu už několikrát zmínil a která se samozřejmě dávno používá - tam, kde je to možné a praktické. Takže mi zbývá jen upozornit, že ten článek je 13 let starý…

[nemam]

Hledas duvody pro to, proc to udelal blbě a ne zpusoby jak to udelat lepe. Nedelas nahodou v OK System? Tam maji zamestnanci podobne zpusoby mysleni. Podle toho pak ty jejich vytvory pro statni spravu vypadaji.

D stav a nemoznost sestreleni procesu v userspacu je proste nesmysl, a ze tobe smysl dava a dokazes si ho obhajit tisicem vymyslu je uz bohuzel tva vec. Lenost programatoru jadra, cekani na neco ceho se nemusime vubec nikdy dockat. Ty si jak ten proces v D stavu. Obhajovat tenhle nesmysl muzes treba donekonecna. Treba tak dlouho az te to prestane bavit a nakonec to vstrebas i ty, pac si nad tim jednou vylames zuby a reknes si, kua to je fakt nesmysl, ze nemuzu tenhle proces sestrelit, pricemz neni k jeho nesestreleni vubec zadny duvod, jen nekdo si myslel, kdyz to psal, ze to tak chci a budu to tak chtit, a budu se nad tim radovat, aby mi tam visel proces v D stavu se kterym mozna nehnu ani kdyby co bylo. Nejlepe kdyz mi bude navic jeste k tomu alokovat furu ram.

[Michal Kubeček]

Děkujeme za názornou demonstraci Kruger-Dunningova efektu.

[Jendа]

Ale především by asi bylo dobré znovu zopakovat poslední odstavec komentáře z 19.8. 12:35. A opakovat ho tak dlouho, dokud ho ti, kdo tu pořád opakují, jak je "stav D špatné řešení" nevstřebají.

No ale tak pokud je to NFS nebo NBD na nějakém vzdáleném stroji, jehož výpadek nedokážu ovlivnit, a já teď mám kvůli tomu v počítači zaseknuté procesy, tak je to mrzuté.

[Michal Kubeček]

Ano, to určitě dobré není, ale co si pamatuju, zrovna u NFS už to ve většině případů killable je. NBD je dost starý driver a ne zrovna mainstream, takže tam si nejsem moc jistý, jak moc aktivně je vyvíjený. Obecně samozřejmě souhlasím, že při čekání na odezvu ze sítě by se vždy mělo počítat s tím, že se nedočkáme, takže by tam vždy měl být nějaký (ideálně konfigurovatelný) timeout a možnost ručního zásahu (což nemusí být nutně zabití procesu signálem, u NFS mne napadá třeba forced unmount). Sám jsem se před lety dohadoval s autorem DRBD, že čekat na potvrzení od druhého serveru pod spinlockem je špatně; on argumentoval tím, že když to po nějakém timeoutu vzdáme (což už měl v novější verzi implementováno), tak vznikne split-brain, já se ho snažil přesvědčit, že když na to potvrzení čekáme šest hodin, tak ten split-brain už dávno nastal a je lepší si to připustit včas.

Ale podstata je někde jinde. Já přece netvrdím, že je všechno je napsáno dokonale a že některé konkrétní drivery nemohou používat unkillable uninterruptible sleep spíš z lenosti než ze skutečné potřeby. Jenže lidé jako Josef Kufner a "nemam" (a ti, kdo jejich stesky označují jako "řešení") tu tvrdí, že uninterruptible sleep je z principu špatně a že by neměl existovat vůbec. A navíc zarputile ignorují existenci dvou variant, z nichž pouze jedna se chová tak, jak tvrdí (přestože Josef Kufner sám nalinkoval 13 let článek informující o implementaci).

[Josef Kufner]

To, že je to použité z lenosti a nebo z principu špatně se vůbec nevylučuje

[Michal Kubeček]

Tak jinak: je zásadní rozdíl mezi tvrzením, že některé konkrétní drivery používají uninterruptible (a unkillable) sleep tam, kde by nemusely, a tvrzením, že samotná existence toho stavu je zásadně špatně. To první nepopírám, to druhé je bohapustý nesmysl opakovaný bez technických argumentů lidmi, kteří nemají tušení, jak ty věci fungují a proč.

[j]

Takze podle tebe je lepsi, kdyz system crashne celej, kvuli nejakym nesestrelitelnym procesum ktery vyzerou ram/cpu/... a (mozna) znici nejaky ty data, nez strelit nejaky stado procesu nejaky dementni aplikace a (mozna) znicit data ty aplikace?

Mimochodem, NIC jako nesestrelitelnej proces neexistuje, to je jen a pouze koncept, kterej si nekdo vymyslel. Coz je mimo jiny videt prave na tom, ze ten proces restart neprezije. A restart systemu muzu provist i bez restartu HW. To jsou dve zcela nesouvisejici veci. Principielne umim system restartovat i za chodu. A vis jak se to dela? Mno nastartuje se novej system, a ty bezici procesy se mu predaji.

A, zazrak, cerna magie, ... ty ktery nechci aby se predaly, se proste nepredaji, a proste chcipnou nejpozdejs v okamzik ukonceni puvodniho systemu.

Jenze na to abych sejmul proces nepotrebuju ukoncit system, naopak, sprava procesu je jednim ze zakladnich ukolu operacniho systemu. A pokud ten system neumi ukoncit libovolnej proces, tak je to proste spatne.

Tvoje argumentace vypada jako dohadovani se, jestli je lepsi nekoho sejmout sekerou mebo gilotinou, pricemz vysledek bude uplne stejnej, jen jde o cenu toho ukonu, protoze retart systemu (ta gilotina) je vyrazne drazsi.

---

Dete s tim guuglem dopice!

[Michal Kubeček]

Zkuste si nejdřív přečíst, co už jsem sem na tohle téma napsal. Třeba si všimnete, že vůbe nejde nějaká "data ty aplikace", ale o interní datové struktury jádra, které nemůžete nechat v nekonzistentním stavu, protože pak by stejně šlo do kytek i všechno ostatní, stejně jako kdybyste nechal zamčené nějaké zámky nebo neuvolnil reference.

Ono je opravdu neuvěřitelně frustrující snažit se nějak technicky argumentovat a bavit se s bandou lidí, kteří nemají sebemenší představu, jak věci fungují a co by jejich geniální vize obnášely v praxi, ale o to silnější mají výrazivo a o to více házejí ramena, jak jsou všichni ti vývojáři naprostí blbci, když něco tak "jasného" nedokážou pochopit. A co hůř, libují si ve své ignoranci a nemají sebemenší snahu se o problematice něco dozvědět.

Takže této marné snahy o vysvětlování radši nechám a počkám si na vaše patche, které odstraní TASK_UNINTERRUPTIBLE z linuxového jádra. Jak kdysi pravil jeden moudrý muž: "Tak is cheap. Show me the code."

[xxxs]

takze nedokoncena sietova operacia by po zostreleni zhodila cele jadro? nejako sa mi tomu nechce verit.

[Michal Kubeček]

Čistě ze zvědavosti… toho, že jsem tu už před více než pěti dny napsal

Obecně samozřejmě souhlasím, že při čekání na odezvu ze sítě by se vždy mělo počítat s tím, že se nedočkáme, takže by tam vždy měl být nějaký (ideálně konfigurovatelný) timeout a možnost ručního zásahu

jste si nevšiml nebo jste se to rozhodl ignorovat?

[xxxs]

takze pre ucely temy - nezostrelitelny sietovy proces, je j.kufnerove vyjadrenie adekvatne a oznacitelne ako riesenie?

[Michal Kubeček]

Není, protože tvrdí, že je to špatné řešení zcela obecně, ne v nějakém konkrétním případě. Jako "řešení" si může každý označit co chce - a podle toho to taky vypadá. Že tu navíc všichni přes opakovaná upozornění zatvrzele ignorují už 13 let existující a pro účely diskuse zcela zásadní rozdíl mezi uninterruptible a unkillable, to už je jen taková třešnička na dortu.

[Jendа]

Je to stejný problém.

Není, pokud jde o inmemory strukturu. Třeba pokud alokoval paměť (nevím jak funguje jaderný alokátor, ale tipuju, že multithread a nějakou potřebu zamykání mít bude), tak když vypadne proud, tak je to jedno. Předpokládám, že malloc (pomáhám si analogií z userspace, protože do kernelu nevidím) se žurnálem bys nechtěl, protože by byl pooomalý.

[Josef Kufner]

Pokud jádro něco alokuje či použije v rámci toho zaseknutého volání, tak o tom ví a může to uklidit (neboť to leží v té proměnné tam o pár řádek výše a "stačí" implementovat něco jako finally). Pokud už to předalo procesu, tak se to uklidí při ukončení jako obvykle.

Nejde ani tak o technické detaily, ale o to, že se kdysi použilo nějaké řešení, později se ukázalo nešikovné, ale teď už je velmi obtížné ho změnit, protože je v daném projektu zažrané příliš hluboko, nejen v kódu, stabilních API, ale i v hlavách programátorů. Stává se to až nehezky často.

[Jendа]

Pokud jádro něco alokuje či použije v rámci toho zaseknutého volání, tak o tom ví a může to uklidit (neboť to leží v té proměnné tam o pár řádek výše a "stačí" implementovat něco jako finally).

Já tomu teda prd rozumím, ale myslel jsem si, že tam platí dvě věci:

• alokuje se z nějaké datové struktury, která potřebuje uzamknout - kmalloc vypadá jako heapový alokátor, a alokátory co jsem viděl (moc jich nebylo) neuměly pracovat bez zámků. Ono by se to asi dost blbě dělalo.
• ty operace nedělá nějak magicky „kernel“, ale přímo ten thread, který teď spouští kód kernelu (a má příslušně namapovanou paměť, aby mohl zapisovat věci, které běžně z userspace nejdou)

[Josef Kufner]

ty operace nedělá nějak magicky „kernel“, ale přímo ten thread, který teď spouští kód kernelu

To je totéž. Prostě kus kódu v Ring 0, který po sobě musí umět uklidit, i když věci nedopadnou dobře.

[Michal Kubeček]

Pokud jádro něco alokuje či použije v rámci toho zaseknutého volání, tak o tom ví a může to uklidit (neboť to leží v té proměnné tam o pár řádek výše a "stačí" implementovat něco jako finally).

Pokud je to "o pár řádků výš", tak to je relativně jednoduchá situace, ale zdaleka ne vždy to tak je. Ta alokace může být v úplně jiné funkci - a dokonce v úplně jiném driveru nebo jiné části kódu. Co hůř, za uvolnění může být zodpovědný někdo jiný, než kdo tu paměť alokoval.

Nejde ani tak o technické detaily

Jde o technické detaily. Vy a pan "nemam" máte svou představu, jak by měly věci vypadat, ale ta vychází z neznalosti toho, jak to všechno funguje uvnitř. A na základě té své představy vynášíte kategorické soudy o tom, jak je to všechno špatně navržené.