Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapy a AI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.
Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).
Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.
Programming stuff. And stuff.
Den začal optimisticky s bug reportem, že jedna operace zabírá na linuxu neskutečné množství paměti (aplikace přeložena pro windows že stejných zdrojaků tímhle bugem netrpěla).
Říkám si, nějaký podivný memory leak. První zvláštní věc byla, že paměť narostla jenom jednou, při opakování daný operace už víc nenarostla. Možná kdesi v paměti zůstala zapomenuta kopie nějaké větší struktury. S debuggerem jsem zjistil že se to děje při vytváření tabulek křížových referencí, ale ani po pečlivém zkoumání jsem nenašel žádný zapomenutý new ani nic podobného.
Tabulky křížových referencí jsou ve zkratce hash_mapa mapující ukazatel symbolu na ukazatel třídy XrefEntry, která obsahuje malý hash_set a dva malé std::sety ukazatelů (malý = řádově do stovky prvků).
Co se dá dělat, podívám se na to s valgrindem. Leak tam nebyl ale ani podle valgrindu. Navíc valgrind ukazuje nárůst jenom o cca 15 MB reachable bloků, jenže top ukazuje nárůst o 300 MB v resident size. Vylučovací metodou zůstala jenom možnost fragmentace paměti. Že něco takového existuje jsem věděl, jenže nikdy předtím jsem na to nenarazil v míře, kdy by se 15 MB malých kousků roztahalo po 300 MB namapovaných stránkách.
Po mnoha náhodných pokusech s tím něco udělat nakonec zabrala výměna hash_set za obyčejný std::set v XrefEntry. Při dané operaci tabulky referencí používají velké množství malých (hash_)setů (jako členy XrefEntry). Instance XrefEntry často vznikaly a zanikaly, tím pádem často vznikaly i členské (hash_)sety, kterých kterých obsah se často měnil (a prudce kolísali ve velikosti, tj. maximum skutečně použité paměti bylo o hodně vyšší než 15 MB malých bloků po skončení operace).
Výhoda std::map a std::set oproti hash_ verzím je nejspíš v tom, že nepotřebuje alokovat extra malé kousky paměti pro buckety (u gcc i msvc je map/set implementován jako červeno-černý strom). Co způsobilo takové roztahaní po paměti byla zřejmě velmi specifická posloupnost alokací a dealokací bucketů u těch hash_setů a std::allocatoru to moc nesedlo.
Zkusil i jiné implementace map a setů. Např. boost::unordered_set měl v daném případě podobné problémy, ale roztahanost po paměti byla menší asi o 25%. Pro zajímavost, tady je porovnání několika dalších implementací (hash) tabulek:
Comparison of Hash Table Libraries
Hash tabulky mají konstantní složitost vkládání/vyhledávání/mazání, člověk by čekal že budou o hodně rychlejší než třeba červeno-černý strom s logaritmickou složitosti vkládání/vyhledávání/mazání. Prakticky u skutečných implementací musí být záznamů v tabulce hodně (nejméně desettisíce), aby byla hash tabulka rychlejší (extra režie). Neměřil jsem samozřejmě všechny implementace, ale boostí unordered a STL implementace (gcc, msvc) se chovají takhle.
Tiskni
Sdílej:
Njn, ja to cetl asi pred rokem kdyz jsem ten problem s fragmentaci pameti resil (taky jsem potreboval sablonoidne struktury, tim padem glib a ghthash vypadli). IMHO udelat poradny benchmark je neskutecne prace (proto vetsina benchmarku vypada tak jak vypada). Vzdy je lepsi (nebo spis nutny) si vsechno premerit (jine podminky, jine vysledky).
STL je urcite implementovana jako soucast gcc/msvc (i kdyz treba existuji separatni implementace jako STLport). C++ sablony navic ani nejde kompilovat (do strojoveho kodu; jedine do predkompilovanych headeru) pokud se neudela konkretni instanciace.
Na druhe strane implementace sablon urcite pouziva funkce z glibc (treba malloc/free pres new/delete a std::allocator), tim padem vykon znacne zavisi i od glibc.
Taky mam domnenku, ze od glibc zavisi rychlost vyjimek (tohle nemam jeste vyreseno, urcite jde o nejakou kombinaci z trojice glibc, binutils, libgcc_s.so), viz nasledujici pripad (__cxa_throw a _Unwind*):
Obe mereni je stejny testcase (specialni extremni pripad s 70000 vyjimkama, nemilujete proste specialni pripady? ). Vzdy prelozeno s gcc 4.1.2 (libgcc_s.so je soucasti gcc, tim padem i stejna libgcc_s.so odkud jsou _Unwind* funkce). Jednou na CentOS 4 s glibc 2.3.4 a jednou na CentOS 5 s glibc 2.5. Jedina rozdilna vec krome glibc jsou jiny verze binutils. No a ta CentOS 5 verze beha v danem pripade vic nez 5x rychleji.
(Nejspis ten problem s vyjimkama bude mat neco do cineni s timhle: http://gcc.gnu.org/ml/gcc/2005-02/msg00627.html ).
Pozn. v tech grafech pochazeji vsechny funkce pod __cxa_throw z libgcc_s.so krome dl_iterate_phdr (je z glibc) a __gxx_personality_v0 (je z libstdc++ i s uzlem pod nim).
Na druhe strane implementace sablon urcite pouziva funkce z glibc (treba malloc/free pres new/delete a std::allocator)
Ne nutně. Na unixových systémech to tak nejspíš většinou bude, ale nemusí to tak fungovat všude. Standardní C++ knihovna může být teoreticky naprosto nezávislá na standardní C knihovně.
Prilis si neumim predstavit jak by se implementovalo new/delete nebo std::allocator bez malloc nebo mmap. Snad jedine primym volanim do kernelu (pres preruseni), co je prilis low-level pro standardni C++ knihovnu.
malloc()
a free()
v libc. Uvědomte si, že C++ je jazyk zcela nezávislý na C, teoreticky byste mohl mít C++ i na platformě, kde vůbec neexistuje překladač céčka, a tedy ani standardní C knihovna. Koneckonců dřív používala i řada projektů psaných v C své vlastní náhražky za systémové malloc()
a free()
a autoři to zdůvodňovali tím, že jejich implementace jsou efektivnější, což by nebylo dost dobře možné, kdyby to byly jen nadstavby nad těmi systémovými implementacemi.
Tak tady doslo asi k nedorozumeni. Ja puvodne psal o zavislosti na glibc uz jenom proto (pripad Linuxu), ze na preimplementovani malloc/free potrebujete nejakou systemovou funkci jako mmap/brk, abyste mel _nejakou_ pamet nad ktorou postavite vlastni malloc/free. A mmap/brk je taky soucasti glibc (jinak musite volat kernel primo pres preruseni/syscall).
A mmap/brk je taky soucasti glibc (jinak musite volat kernel primo pres preruseni/syscall).
Odpověděl jste si sám: ty funkce nejsou nic jiného než wrappery nad příslušné syscally. A použití céčkových wrapperů není principiálně nutné. Navíc se na to pořád díváte příliš linuxocentricky.
True Dival jsem se na na jiny implementace new, snad vsechny bezne non-embedded systemy volaji nejakou verzi malloc (vratane msvc). Pak jsem disassembloval mmap, abych videl ze nema extra rezii. K alokatorum se jeste dostanu.
BTW nechapu tvrzeni "Standardní C++ knihovna může být teoreticky naprosto nezávislá na standardní C knihovně." AFAIK musi C++ alespon implementovat vsechny funkce C, treba taky malloc?
malloc()
mezi nimi sice je, ale neznamená to, že musí jít o stejnou implementaci jako v libc. Vztah mezi funkcí malloc()
a operátorem new
je takový, že malloc()
nesmí k alokaci použít new
The functionsale na druhou stranu se výslovně uvádí, že není specifikováno, zda operátorcalloc()
,malloc()
, andrealloc()
do not attempt to allocate storage by calling::operator new()
.
new
používá malloc()
nebo ne
Whether the attempt involves a call to the Standard C library function malloc
is unspecified.
Takže operátor new
může být nadstavba nad funkcí malloc()
, ale stejně tak na ní může být úplně nezávislý. Funkce malloc()
ale nesmí být implementována pomocí operátoru new
, IMHO kvůli tomu, aby bylo možné beztrestně overloadovat new
vlastní verzí využívající malloc()
.
<stdint.h>
. V C++ programu se obecně nemůžete spolehnout na to, že je budete mít k dispozici (ani ty, jejichž dostupnost garantuje norma jazyka C).