Programování v C: sanitizer, profilování (diskuse)

[Člověk z Horní Dolní]

Měli byste tedy jakoby se sanitizérem překompilovat celý runtime.

Ha, teď jsi se prozradil, už vím kdo je Gréta.

[Jendа]

https://www.smbc-comics.com/comic/the-program

[Člověk z Horní Dolní]

Haha :D

[MakeIranBombedAgain❗]

jestli jako myslíš že tvuj vodhad je jakoby víc lepšejší než bystroušákovy statistický analízy komentů :D

[Člověk z Horní Dolní]

Zas bych ty prekombinovane statisticke metody neprecenoval, selsky rozum ma casto lepsi vysledky :D

[_]

Jenda je Bluebear, Greta je Amiga.

[xxxs]

amiga je zaujimavy typek, ale ak sa mu podarilo opravit mozog natolko, aby mohol hrat gretu, tak ten recept bude mat hodnotu gdp eu.

[Petr]

Greta ma mozog? Vzdyt je uplne vymastena.

[Člověk z Horní Dolní]

V diskuzi o globalnim oteplovani se docela ztrapnila neznalosti te problematiky.

[Grétina zapařená pipina]

Považovat odlišný názor za neznalost je dost omezené.

[MakeIranBombedAgain❗]

si myslim že to nemá smysl to s nim dál řešit protože už je jakoby rozhodnutej čemu chce věřit :D ho ale teda jako dorazim když mě takle provokuješ :D :D ;D ;D

[_]

Gréta je kučera, začalo to jako pravičácká agenda karikatury ekologického liberála, ale dlouho mu to nevydrželo, a už najednou hlásají totožné názory a řeší stejné věci - už nejen politiku, ale najednou i FOSS a licence. Hlavně na sebe nereagují a málokdy jsou ve stejném vlákně. A zejména - koho než frantíka zajímají ty jeho podělaný relační roury? Tohle se blbě mění když si někdo zapomene změnit účet Q.E.D.

[MakeIranBombedAgain❗]

A zejména - koho než frantíka zajímají ty jeho podělaný relační roury

ttttsssss radar mě zajímá uplně stejně hele :O :O :D :D :D :D ;D ;D

[Jan Hus]

Gréta nepíše takovou czenglish jako s. Jenda.

[billgates]

Zaujimave. Doteraz som pouzival -Wall -Wextra -Wshadow -fstack-protector-strong a na sanitizaciu -fsanitize=address -fsanitize=undefined -fsanitize=leak -fno-omit-frame-pointer. Tie niektore dalsie warningove parametre vyzeraju uzitocne.

[neprogramátor]

Když přijde soudný den budou počítače programovat nás, ne my je. A jako první budou na řadě programátoři.

[Eich]

Nastesti to bude az v dobe kdy bude dominovat vsude JavaScript.

[plostenka]

Osobně jsem ale tohle nikdy nepotřeboval řešit, defaultní malloc byl vždycky good enough. Setkali jste se někdy s případem, kdy by bylo potřeba alokátor ladit?

Presne kvuli zpomaleni kvuli (kontrolam na) race condition jsme museli naalokovat velkou pamet pro kazdy thread separatne a implementovat v asm vlastni alokator nad timhle vyhrazenym adresnim prostorem.

[Heron]

Tady je krásný writeup o hledání občasného náhodného pádu Go.

Skvělý článek, díky.

Trochu mi to (v malém) připomíná moje začátky s golangem, kdy jsem skoro hned narazil na chybu při procházení adresářů na sambě, kdy to vracelo různý počet nalezených souborů při každém dalším volání. Golang všechny relevantní syscally posílá s SA_RESTART a nikdy by se neměl vracet EINTR. Jenže se vrací. Ovladač pro sambu prostě ignoruje SA_RESTART a nechá to udělat klienta (potom se zjistilo, že je to ještě navíc ovlivněno velikostí bufferu) a nakonec vydali nové verze knihovních funkcí, ale toto řešení se mi nelíbí, protože to zakrývá původní a stále existujicí chybu v sambě. (Nehledě na to, že workaround je poměrně snadný a podle mě je mnohem lepší v kódu když už tak použít workaround na místo knihovní funkce, která zakrývá nějaký problém na systémové vrstvě. -- Potom se každý drží knihovní funkce a nechce nic slyšet o tom, že pod tím je to ale stále špatně, takže je lepší toto místo explicitně označit.) Sice na kritických místech používám NFS, kde se to neděje, ale i tak mě překvapuje, že takto často používaný způsob sdílení má tyto problémy.

[Heron]

Například se mi zdá, že si každý druhý píše vlastní alokátor

Jo, bavil jsem se s člověkem, který si běžně píše (C++) několik vlastních alokátorů v jednom programu pro různé účely, protože jinak to nejde a ten single thread program by jinak nezvládal zátěž (což je možná pravda, ale současně to extrémně zkomplikuje přepis na multithread nebo jiné rozsekání).

[jbv]

Obecne je problem v tom ze vetsina C/C++ progrmatoru jsou hodne spatni. Nejcasteji jsou to samouci, hlavne z 90tek. Dneska uz nastesti C/C++ neni sexy, tak z mladsi generace v nem programuji prkticky jen ti, ktere to opravdu zajima. Je to pekne videt i na nazoru hlavne C komunity na rust, protoze tihle programatori nejsou schopni napsat netrivialni rust kod, co se zkompiluje.

[Člověk z Horní Dolní]

Jde taky o to, ze C++ je extremne slozity jazyk. Ja jsem driv C++ nesnasel, ale v poslednich asi 5 letech jsem si ho docela oblibil, i kdyz moc v nem nedelam, urcite nejsem zadny odbornik. Od C++11 ten jazyk udelal obrovsky pokrok v UX, s nadsazkou to je ted jako Python, ale rychlejsi. Tu rychlost a moznost low-level optimalizace miluju, je to takovy pocit svobody, ze me ten jazyk nijak neomezuje.

[kvr]

Pěkný článek. Ještě bych zmínil Electric Fence Malloc, který před nebo za alokovanou pamětí rezervoval nepřístupnou stránku, která při buffer overflow/underflow vedla k okamžitému pádu.

a pokud vlákna hodně alokují, tak je toto bottleneck. Alokátor tohle detekuje a rozdělí haldu na více částí, pro každé vlákno samostatně.

Osobně jsem ale tohle nikdy nepotřeboval řešit, defaultní malloc byl vždycky good enough. Setkali jste se někdy s případem, kdy by bylo potřeba alokátor ladit?

Kdysi dávno, tak před 15ti lety. Defakto webserver v C++, samozřejmě spousta requestů se zpracovávala paralelně a v té chvíli byl i na tehdy snad jenom čtyřjádru existující glibc malloc šílený bottleneck. Takže v té době jsem si i já napsal vlastní alokátor, kromě per-thread cache a rozdělení podle podobné velikosti bloků uměl i některé debug features popsané v článku, včetně detekce memory leaks, myslím, že i inaccessible stránky na začátku či na konci apod. Později s běžně dostupnými multicore procesory a multithreading se začaly používat podobné alokátory přes LD_PRELOAD a mám pocit, že i glibc má dnes něco podobného (nebo dokonce přímo převzali jemalloc?)...

Tady je ukázka, že podmínku zarovnaného přístupu není možné v C ignorovat ani na architekturách, kde to procesor hardwarově ošetří (byť za cenu zpomalení), protože se to stejně náhodně vysype.

Na tohle jsem taky narazil, když jsem experimentoval s AVX-512. Alignment __mm512 sice funguje v rámci struktury, ale stack je zarovnaný jenom 16-bytes. Takže SSE v pohodě jede (__mm128), ale AVX-2 a AVX-512 může mít základní adresu struktury nezarovnanou a tedy i prvky uvnitř. Nejsem si jistý, jak to má malloc bez options, myslím, že taky musí vracet 16-byte, ale jestli i výš, nevím.

Jinak, procesor x86_64 to právě hardwarově neošetří - na load/store se můžou použít instrukce, které vyžadují alignment (MOVAPD apod), pokud to kompilátor (mylně, viz výše) ví a to potom vede k pádům. Měly být původně rychlejší, ale myslím, že dneska je to skoro jedno...

Kromě toho bych řekl, že instrukce na unaligned load/store nebudou atomické (ne ve smyslu compare-and-swap, ale v jednoduchém smyslu konzistence, že se přepíše či nahraje celá hodnota najednou bez přerušení jiným CPU).

[jbv]

Vlastni akolator neni uplne casta vec, ale da se pro nej najit pomerne dost use casu. Obecne bych rekl, ze vsechny pouziti, kde je velky tlak na rychlost alokace/dealokace a zaroven je pomerne predvidatelne pouziti alokatoru. Typicky priklad jsou gc, transakce, databaze apod. Ale je pravda, ze to nejsou veci co lidi pisou denne.

[xkucf03]

Typicky priklad jsou gc

Existuje něco jiného než Boehm? Myslím veřejně dostupné.

[xkucf03]

Pěkný článek, díky.

Nejvíc používám ASan. Bez něj by programování v C/C++ byla procházka minovým polem. S ním je to relativně v pohodě a řeší velkou část nebezpečnosti těchto jazyků.

Ještě bych doporučil použití fuzzeru, který taky může odhalit nějaké ty chyby – krmí program náhodnými/chybnými daty a zjišťuje, zda program spadne, zacyklí se atd. Může odhalit např. chybu typu, že ve vstupních datech je uvedena délka následujícího pole (TLV), parser si pro tuto délku alokuje paměť, aniž by předem ověřil, že tolik dat na vstupu vůbec je (tzn. chybnými vstupními daty lze program donutit, aby si alokoval zbytečně gigabajty paměti a nebo spadl). Ale zrovna tohle je chyba, které jsem si byl vědom a fuzzerem jsem si ji jen potvrdil.

[trekker.dk]

například přetečení intu, ale to lidi často řeší kompilací s -fwrapv

Pěkné, využil jsem. Ušetřilo mi to v programu asi tak 4 instrukce.

[mln]

Ma niekto tip na sanitiser (alebo podobne nastroje na buffer owerflow, memory leak, pretecenie premennych) ktory by fungoval na mikrokntroleroch ? SMT32, MSP430, TMS320 atd ? Na mikrokontroleroch sa C jazyku clovek nevyhne :/

Chcel by som sa dožiť dna ked bude C jazyk mat v kompilatore volbu ktora zapne kontroly na owerflow, memory leak, pretecenie premennych. Mikrokontrolery su uz dosť rychle, podme písať bezpečný program - tí ktorí o to maju zaujem (nikomu nevnucujem).

[xkucf03]

Nestačilo by ten kritický kód napsat jako knihovnu, kterou by šlo přeložit jak pro MCU, tak pro x86? (jasně, tam, kde pracuji s I/O to bude vázané na to MCU a musel bych si to nějak mockovat/simulovat, ale svoje vlastní algoritmy můžu klidně napsat jako .h soubor, který bude použitelný jako uvnitř firmwaru tak na desktopu).

[dumblob]

Nezarovnaný přístup - problémy i na x86 Tady je ukázka, že podmínku zarovnaného přístupu není možné v C ignorovat ani na architekturách, kde to procesor hardwarově ošetří (byť za cenu zpomalení), protože se to stejně náhodně vysype.

Někdy ale zarovnaný přístup nechceme, protože nezarovnaný bývá více než 2x rychlejší.

[Jendа]

To vypadá jako příklad na omezenou asociativitu cache. Cacheline je 64B (možná na nejnovějších počítačích dokonce 128B), to je úplně něco jiného než o čem se píše v článku (nativní céčkové datové typy - což končí u 8B typů - zarovnané na svoji velikost).

[dumblob]

Ano, špatně jsem to přečetl (kolikrát už jsem si říkal, že večer, kdy jsem na pokraji ztráty vědomí vlivem unavenosti, nesmím přispívat do diskuzí).

Alespoň někdo kdo hledá něco o zarovnání, najde i širší pojetí

[MakeIranBombedAgain❗]

supr satanizér :D ;D

[토토사이트]

The article is really good. I found here looking for a good article because my heart was empty. There are a lot of different articles, so reading them makes me feel a bit empty. Next time I want to read an article about 토토사이트, please