V článku dosť výrazne chýba informácia, že pád spôsobilo neošetrené pretečenie pamäte v Ruste, v kóde, ktorý predtým dlhé roky fungoval a potom bol prepísaný do Rustu.
Each module running on our proxy service has a number of limits in place to avoid unbounded memory consumption and to preallocate memory as a performance optimization (...) Again, the limit exists because for performance reasons we preallocate memory for the features.
When the bad file with more than 200 features was propagated to our servers, this limit was hit — resulting in the system panicking. The FL2 Rust code that makes the check and was the source of the unhandled error is shown below: (...)
This resulted in the following panic which in turn resulted in a 5xx error.
K žádnému přetečení paměti nedošlo. Daný kód vrátil validní Result type, který se Cloudflare rozhodl řešit přes explicitní panic při chybě. Což je věc která není u inicializace aplikace zas tak velké zlo, pokud ta chyba není recoverable. Správně by měli udělat rollback konfigurace a nahodit to znova.
19. 11. 2025, 14:58 editováno autorem komentáře
Souhlas, zjevně paměti bylo málo, kód detekoval chybu, se kterou kód vyšší úrovně nepočítal. Z hlediska Rust korektní chování.
Co mi tam chybí, je neschopnost identifikovat chybu poměrně dlouhou dobu. A tam nejspíš doplácí Rust na chybějící podporu vyjímek. U Java by se zpropagoval celý stacktrace a někde dole by bylo "file too big to fit into memory". U Rust a ostatních jazyků bez exception bude jenom Result-Err a hledej jehlu v kupce sena... Logování může samozřejmě pomoct, ale to se nedělá v low level funkcích, u kterých se ani neví, jestli chyba je běžná nebo neočekávaná.
Jinými slovy, je to sice memory safe, ale způsobilo to celosvětový výpadek? :)
Spekulace: Dalo by se tomu zabránit, kdyby to nepřepisovali?
Já jsem si ale celkem všiml, že v rustu toto lidi dělají - tak nějak předpokládají, že když se to zkompiluje, tak to nemá chyby - testů je většinou málo... ne všechny crates jsou kvalitní a často se mi stalo, že jsem něco jen zkoušel (nějaký rust program) a hitnul jsem panic prakticky hned. Možná se eliminovali memory-safety bugy, ale těch logických je mnohem víc? Stačí se podívat na uutils/coreutils, sudo-rs - všechno bylo způsobené ignorancí.
Asi opravdu záleží na kultuře - rust prostě není záruka bezchybnosti a je potřeba kultura testování, jinak sice přestaneme počítat memory bugy, ale začneme počítat logické bugy.
Jinými slovy, je to sice memory safe, ale způsobilo to celosvětový výpadek? :)
Memory safe neřeší všechny problémy světa a nikdo kromě odpůrců memory safe jazyků to netvrdí.
Dalo by se tomu zabránit, kdyby to nepřepisovali?
Přepis s tím nijak nesouvisí. Obě verze mají předalokaci (logicky) a obě verze selhávaly, akorát každá jiným způsobem.
To ví přece každý, že to neřeší všechny problémy světa - opět idiotská odpověď od vás.
Otázka jen je, jestli z těch memory safety bugů nebudou logické bugy. Ono jestli těch bugů bude ve výsledku stejně, jen budou jiná kategorie, tak v čem si polepšíme :) ?
Já dělám běžně v memory safe jazycích a těch logických chyb se udělá strašně moc. Takže nemám pocit bezpečí, jen díky tomu, že něco je memory safe.
To ví přece každý, že to neřeší všechny problémy světa
Pokud to ví každý, proč se tedy podivujete, že to nevyřešilo problém, který s memory-safe nesouvisí?
opět idiotská odpověď od vás.
Vždycky svou odpověď přizpůsobuju dotazu.
Otázka jen je, jestli z těch memory safety bugů nebudou logické bugy.
Nebudou.
Takže nemám pocit bezpečí, jen díky tomu, že něco je memory safe.
Prý všichni vědí, že memory-safe nevyřeší všechny problémy světa. Je tedy logické při použití memory safe jazyka mít pocit bezpečí, že v memory-safe kódu nebudou chyby v přístupu mimo platnou paměť. Ale bylo by nelogické mít pocit bezpečí v jiných oblastech, pokud nejsou chráněny jiným způsobem.
A hitnout Panic je docela netriviální, běžná praxe je zakázat explicitní panic lintem a pro těch pár výjimek kde se jeho použití vyplatí vynutit explicitní vypnutí lintu s komentářem.
Načítání konfigurace je jedna z těch možných výjimek, protože software bez funkční konfigurace tak nějak nějak nenastartuje.
20. 11. 2025, 09:47 editováno autorem komentáře