Toto je výběr příběhů z internetu o tom, jak mají brouci někdy zcela neuvěřitelné projevy. Možná máte také co říct.
Alergie auta na vanilkovou zmrzlinu
Příběh pro inženýry, kteří chápou, že samozřejmost není vždy odpovědí a že bez ohledu na to, jak přitažená fakta se mohou zdát, stále jsou to fakta. Divize Pontiac společnosti General Motors Corporation obdržela stížnost:
Toto je podruhé, co vám píšu, a neobviňuji vás, že neodpovídáte, protože to zní šíleně. Naše rodina má tradici jíst zmrzlinu každý večer po večeři. Druhy zmrzliny se pokaždé mění a po večeři si celá rodina vybírá, jakou zmrzlinu si koupí, načež jdu do obchodu. Nedávno jsem si koupil nový Pontiac a od té doby se mé cesty za zmrzlinou staly problémem. Víte, pokaždé, když si koupím vanilkovou zmrzlinu a vrátím se z obchodu, auto nenastartuje. Pokud přivezu jakoukoliv jinou zmrzlinu, auto nastartuje bez problému. Chci se zeptat na vážnou otázku, bez ohledu na to, jak hloupě to zní: "Co je na Pontiacu, že se nespustí, když přinesu vanilkovou zmrzlinu, ale spustí se snadno, když přinesu jinou příchuť zmrzliny?"
Jak si dokážete představit, prezident divize byl k dopisu skeptický. Nicméně pro každý případ jsem poslal inženýra, aby to prověřil. Překvapilo ho, že ho potkal bohatý, vzdělaný muž žijící v krásné oblasti. Dohodli se, že se sejdou hned po večeři, aby si oba mohli zajít do obchodu na zmrzlinu. Ten večer to byla vanilka, a když se vrátili k autu, nešlo to nastartovat.
Inženýr přišel ještě tři večery. Poprvé byla zmrzlina čokoládová. Auto nastartovalo. Podruhé byla jahodová zmrzlina. Auto nastartovalo. Třetího večera požádal o vanilku. Auto nenastartovalo.
Inženýr racionálně uvažoval a odmítl uvěřit, že by auto bylo alergické na vanilkovou zmrzlinu. Proto jsem se s majitelem vozu dohodl, že bude v návštěvách pokračovat, dokud nenajde řešení problému. A po cestě si začal dělat poznámky: zapisoval si všechny informace, denní dobu, druh benzínu, čas příjezdu a návratu z obchodu atd.
Inženýr brzy pochopil, že majitel vozu tráví méně času nákupem vanilkové zmrzliny. Důvodem bylo rozložení zboží na prodejně. Vanilková zmrzlina byla nejoblíbenější a byla uchovávána v samostatném mrazáku v přední části obchodu, aby bylo snazší ji najít. A všechny ostatní odrůdy byly v zadní části obchodu a nalezení správné odrůdy a zaplacení zabralo mnohem více času.
Nyní byla otázka pro inženýra: proč auto nenastartovalo, když od okamžiku vypnutí motoru uplynulo méně času? Protože problémem byl čas, ne vanilková zmrzlina, inženýr rychle našel odpověď: byl to plynový zámek. Docházelo k tomu každý večer, ale když majitel vozu strávil více času hledáním zmrzliny, motor se podařilo dostatečně vychladit a snadno nastartovat. A když si muž koupil vanilkovou zmrzlinu, motor byl ještě příliš horký a plynový uzávěr se nestihl rozpustit.
Morálka: I úplně šílené problémy jsou někdy skutečné.
Crash Bandicoot
Je bolestné tohle zažít. Jako programátor si zvyknete vinit svůj kód za první, za druhé, za třetí... a někde na desetitisícém místě obviňujete kompilátor. A dále v seznamu již obviňujete vybavení.
Zde je můj příběh o hardwarové chybě.
Pro hru Crash Bandicoot jsem napsal kód pro načtení a uložení na paměťovou kartu. Pro takového samolibého herního vývojáře to bylo jako procházka růžovým sadem: Myslel jsem, že práce zabere několik dní. Nakonec jsem však kód ladil šest týdnů. Cestou jsem řešil další problémy, ale každých pár dní jsem se k tomuto kódu na pár hodin vracel. Byla to agónie.
Příznaky vypadaly takto: když uložíte aktuální průběh hry a přistoupíte na paměťovou kartu, vše téměř vždy proběhne v pořádku... Někdy však vyprší časový limit operace čtení nebo zápisu bez zjevného důvodu. Krátký záznam často poškodí paměťovou kartu. Když se hráč pokusí zachránit, nejenže se mu nepodaří zachránit, ale také zničí mapu. Blbost.
Po chvíli náš producent v Sony, Connie Bus, začal panikařit. Hru s touto chybou jsme nemohli odeslat a o šest týdnů později jsem nechápal, co problém způsobuje. Prostřednictvím Connie jsme oslovili další vývojáře PS1: setkal se někdo s něčím podobným? Ne. Nikdo neměl problémy s paměťovou kartou.
Když nemáte žádné nápady na ladění, zbývá jediný přístup: „rozděl a panuj“: odstraňujte stále více kódu z vadného programu, dokud nezůstane relativně malý fragment, který stále způsobuje problém. To znamená, že odříznete program kousek po kousku, dokud nezůstane část, která obsahuje chybu.
Jde ale o to, že je velmi těžké vystřihnout kousky z videohry. Jak jej spustit, pokud jste odstranili kód, který emuluje gravitaci? Nebo kreslení postaviček?
Proto musíme celé moduly nahradit útržky, které předstírají, že dělají něco užitečného, ale ve skutečnosti dělají něco velmi jednoduchého, co nemůže obsahovat chyby. Musíme napsat takové berličky, aby hra alespoň fungovala. Jedná se o pomalý a bolestivý proces.
Zkrátka se mi to povedlo. Odstraňoval jsem další a další kusy kódu, dokud mi nezůstal počáteční kód, který konfiguruje systém pro spuštění hry, inicializuje vykreslovací hardware atd. V této fázi jsem samozřejmě nemohl vytvořit nabídku uložení a načtení, protože bych musel vytvořit útržek pro veškerý grafický kód. Mohl bych se ale tvářit jako uživatel pomocí (neviditelné) obrazovky uložení a načtení a požádat o uložení a zápis na paměťovou kartu.
Zůstal mi tak malý kousek kódu, který měl stále výše uvedený problém - ale stále se to stalo náhodně! Většinou vše fungovalo dobře, ale občas se vyskytly závady. Odstranil jsem téměř všechen kód hry, ale chyba byla stále naživu. To bylo matoucí: zbývající kód ve skutečnosti nic nedělal.
V určitém okamžiku, pravděpodobně kolem třetí hodiny ranní, mě napadla myšlenka. Operace čtení a zápisu (vstup/výstup) zahrnují přesné časy provádění. Když pracujete s pevným diskem, paměťovou kartou nebo modulem Bluetooth, nízkoúrovňový kód zodpovědný za čtení a zápis to dělá v souladu s hodinovými impulsy.
Pomocí hodin se zařízení, které není přímo připojeno k procesoru, synchronizuje s kódem vykonávaným na procesoru. Hodiny určují přenosovou rychlost – rychlost, kterou jsou data přenášena. Pokud dojde k záměně s časováním, pak je také zmatený hardware nebo software nebo obojí. A to je velmi špatné, protože data mohou být poškozena.
Co když něco v našem kódu mate časování? Zkontroloval jsem vše, co s tím souvisí v kódu testovacího programu a všiml jsem si, že jsme nastavili programovatelný časovač v PS1 na 1 kHz (1000 tiků za sekundu). To je poměrně hodně, standardně při startu konzole běží na 100 Hz. A většina her tuto frekvenci používá.
Andy, vývojář hry, nastavil časovač na 1 kHz, aby se pohyby počítaly přesněji. Andy má tendenci jít přes palubu, a pokud napodobujeme gravitaci, děláme to co nejpřesněji!
Co když ale zrychlení časovače nějak ovlivnilo celkové načasování programu, potažmo hodiny, které regulují přenosovou rychlost pro paměťovou kartu?
Komentoval jsem kód časovače. Chyba se již neopakovala. To ale neznamená, že jsme to opravili, protože k selhání došlo náhodně. Co kdybych měl jen štěstí?
O několik dní později jsem znovu experimentoval s testovacím programem. Chyba se neopakovala. Vrátil jsem se k úplné kódové základně hry a upravil kód pro uložení a načtení tak, aby se programovatelný časovač před přístupem na paměťovou kartu resetoval na původní hodnotu (100 Hz) a poté se resetoval zpět na 1 kHz. K dalším srážkám už nedošlo.
Ale proč se to stalo?
Znovu jsem se vrátil do testovacího programu. Snažil jsem se najít nějaký vzor ve výskytu chyby s 1 kHz časovačem. Nakonec jsem si všiml, že k chybě dochází, když někdo hraje s ovladačem PS1. Vzhledem k tomu, že bych to zřídka dělal sám - proč bych potřeboval řadič při testování kódu pro ukládání a načítání? - Ani jsem si této závislosti nevšiml. Jednoho dne ale jeden z našich umělců čekal, až dokončím testování – asi jsem v tu chvíli nadával – a nervózně kroutil ovladačem v rukou. Došlo k chybě. "Počkej co?!" Tak to udělej znovu!"
Když jsem si uvědomil, že tyto dvě události byly propojeny, mohl jsem chybu snadno zopakovat: začal jsem nahrávat na paměťovou kartu, posunul jsem ovladač a zničil jsem paměťovou kartu. Mně to připadalo jako hardwarová chyba.
Přišel jsem za Connie a řekl jsem jí o svém objevu. Předala informace jednomu z inženýrů, kteří navrhli PS1. "To není možné," odpověděl, "to nemůže být hardwarový problém." Požádal jsem Connie, aby pro nás zařídila rozhovor.
Inženýr mi zavolal a dohadovali jsme se jeho lámanou angličtinou a mojí (extrémně) lámanou japonštinou. Nakonec jsem řekl: "Dovolte mi poslat můj 30řádkový testovací program, kde pohyb ovladače způsobuje chybu." Souhlasil. Řekl, že je to ztráta času a že je strašně zaneprázdněn prací na novém projektu, ale vzdal se, protože jsme pro Sony velmi důležitý vývojář. Vyčistil jsem svůj testovací program a poslal jsem mu ho.
Další večer (byli jsme v Los Angeles a on v Tokiu) mi zavolal a ostýchavě se omluvil. Byl to hardwarový problém.
Nevím, v čem přesně byla chyba, ale co jsem slyšel v centrále Sony, pokud jste nastavili časovač na dostatečně vysokou hodnotu, rušilo to komponenty na základní desce v okolí krystalu časovače. Jedním z nich byl řadič přenosové rychlosti pro paměťovou kartu, který zároveň nastavoval přenosovou rychlost řadičů. Nejsem inženýr, takže jsem možná něco pokazil.
Podstatou ale je, že došlo k interferenci mezi komponenty na základní desce. A při současném přenosu dat přes port řadiče a port paměťové karty s časovačem běžícím na 1 kHz došlo ke ztrátě bitů, ztrátě dat a poškození karty.
Špatné krávy
V 1980. letech minulého století napsal můj mentor Sergej software pro SM-1800, sovětský klon PDP-11. Tento mikropočítač byl právě instalován na železniční stanici poblíž Sverdlovska, důležitého dopravního uzlu v SSSR. Nový systém byl navržen pro směrování vagónů a nákladní dopravy. Obsahoval ale nepříjemnou chybu, která vedla k náhodným pádům a pádům. K pádům vždy došlo, když někdo šel večer domů. Ale i přes důkladné vyšetřování druhý den počítač fungoval správně ve všech manuálních i automatických testech. To obvykle označuje podmínku závodu nebo jinou konkurenční chybu, která se vyskytuje za určitých podmínek. Sergej, unavený z telefonátů pozdě v noci, se rozhodl tomu přijít na kloub a především pochopit, jaké podmínky na seřaďovacím nádraží vedly k poruše počítače.
Nejprve shromáždil statistiky všech nevysvětlených pádů a vytvořil graf podle data a času. Vzor byl jasný. Po několika dalších dnech pozorování si Sergej uvědomil, že dokáže snadno předpovědět čas budoucích selhání systému.
Brzy se dozvěděl, že k výpadkům docházelo pouze tehdy, když stanice třídila vlaky dobytka ze severní Ukrajiny a západního Ruska mířících na nedaleká jatka. To samo o sobě bylo zvláštní, protože jatka byla zásobována farmami umístěnými mnohem blíž, v Kazachstánu.
Černobylská jaderná elektrárna explodovala v roce 1986 a radioaktivní spad učinil okolní oblasti neobyvatelnými. Rozsáhlé oblasti na severu Ukrajiny, Běloruska a západního Ruska byly kontaminovány. Sergej měl podezření na vysokou úroveň radiace v přijíždějících vagonech a vyvinul metodu, jak tuto teorii otestovat. Obyvatelstvo mělo zakázáno mít dozimetry, a tak se Sergej zaregistroval u několika vojáků na nádraží. Po několika sklenicích vodky se mu podařilo přesvědčit vojáka, aby změřil úroveň radiace v jednom z podezřelých vagónů. Ukázalo se, že hladina byla několikanásobně vyšší než normální hodnoty.
Nejen, že dobytek vydával spoustu záření, ale jeho úroveň byla tak vysoká, že vedla k náhodné ztrátě bitů v paměti SM-1800, která byla umístěna v budově vedle stanice.
V SSSR byl nedostatek potravin a úřady se rozhodly míchat černobylské maso s masem z jiných oblastí země. To umožnilo snížit celkovou úroveň radioaktivity bez ztráty cenných zdrojů. Když se o tom Sergej dozvěděl, okamžitě vyplnil dokumenty pro emigraci. A pády počítače se zastavily samy, když se úroveň radiace časem snížila.
Přes trubky
Kdysi společnost Movietech Solutions vytvořila software pro kina, určený pro účetnictví, prodej vstupenek a obecnou správu. DOS verze vlajkové lodi aplikace byla docela populární mezi malými a středně velkými řetězci kin v Severní Americe. Není tedy divu, že když byla oznámena verze Windows 95, integrovaná s nejnovějšími dotykovými obrazovkami a samoobslužnými kiosky a vybavená nejrůznějšími nástroji pro vytváření zpráv, rychle se stala také populární. Většinou aktualizace proběhla bez problémů. Místní IT pracovníci nainstalovali nové vybavení, migrovali data a obchod pokračoval. Kromě případů, kdy to nevydrželo. Když se to stalo, společnost vyslala Jamese, přezdívaného „Čistič“.
I když přezdívka napovídá, že jde o hanebný typ, čistička je jen kombinací instruktora, instalatéra a všeuměla. James strávil několik dní u klienta sestavováním všech komponent dohromady a pak strávil dalších pár dní tím, že by zaměstnance učil, jak používat nový systém, řešil jakékoli hardwarové problémy, které se objevily, a v podstatě pomáhal softwaru v jeho počátcích.
Není proto divu, že v těchto hektických časech James ráno dorazil do kanceláře, a než se dostal ke svému stolu, přivítal ho manažer, nasycený kofeinem nad rámec obvyklého.
"Obávám se, že musíte co nejdříve odjet do Annapolis v Novém Skotsku." Celý jejich systém selhal a po noci práce s jejich inženýry nemůžeme přijít na to, co se stalo. Vypadá to, že síť na serveru selhala. Ale až poté, co systém několik minut běžel.
— Nevrátili se ke starému systému? - odpověděl James zcela vážně, i když v duchu překvapením vytřeštil oči.
— Přesně tak: jejich IT specialista „změnil priority“ a rozhodl se odejít se svým starým serverem. Jamesi, nainstalovali systém na šest míst a právě zaplatili za prémiovou podporu a jejich podnikání nyní běží jako v 1950. letech.
James se mírně napřímil.
- To je jiná věc. Dobře, začněme.
Když dorazil do Annapolis, první věc, kterou udělal, bylo najít zákazníkovo první divadlo, které mělo problém. Na mapě pořízené na letišti vše vypadalo slušně, ale okolí požadované adresy vypadalo podezřele. Ne ghetto, ale připomíná film noir. Když James zaparkoval u obrubníku v centru města, přistoupila k němu prostitutka. Vzhledem k velikosti Annapolis to bylo s největší pravděpodobností jediné v celém městě. Její vzhled okamžitě připomněl slavnou postavu, která na velkém plátně nabízela sex za peníze. Ne, ne o Julii Robertsové, ale o Jonu Voightovi [narážka na film "Půlnoční kovboj" - cca. pruh].
Poté, co James poslal prostitutku na cestu, šel do kina. Okolí se zlepšilo, ale stále působilo jako zchátralé. Ne že by se James příliš trápil. Už byl na ubohých místech. A to byla Kanada, kde jsou i lupiči natolik zdvořilí, že po odebrání peněženky říkají „děkuji“.
Boční vchod do kina byl ve vlhké uličce. James přešel ke dveřím a zaklepal. Brzy to zaskřípalo a lehce se otevřelo.
-Vy jste uklízečka? - ozval se zevnitř chraplavý hlas.
- Ano, to jsem já... Přišel jsem vše napravit.
James vešel do haly kina. Personál zřejmě neměl jinou možnost a začal návštěvníkům rozdávat papírové vstupenky. To znesnadnilo účetní výkaznictví, natož zajímavější detaily. Zaměstnanci však Jamese přivítali s úlevou a okamžitě ho odvedli do serverovny.
Na první pohled bylo vše v pořádku. James se přihlásil na server a zkontroloval obvyklá podezřelá místa. Žádný problém. James však z velké opatrnosti vypnul server, vyměnil síťovou kartu a vrátil systém zpět. Okamžitě začala pracovat naplno. Personál opět začal prodávat vstupenky.
James zavolal Markovi a informoval ho o situaci. Není těžké si představit, že by James mohl chtít zůstat a zjistit, jestli se nestane něco neočekávaného. Sešel po schodech dolů a začal se vyptávat zaměstnanců, co se stalo. Systém evidentně přestal fungovat. Vypnuli a zapnuli, vše fungovalo. Ale po 10 minutách systém spadl.
Zrovna v tuto chvíli se stalo něco podobného. Najednou systém lístků začal házet chyby. Personál si povzdechl a popadl papírové lístky a James spěchal do serverovny. Se serverem vše vypadalo dobře.
Pak vstoupil jeden ze zaměstnanců.
— Systém opět funguje.
James byl zmatený, protože nic neudělal. Přesněji řečeno nic, kvůli čemu by systém fungoval. Odhlásil se, zvedl telefon a zavolal na linku podpory své společnosti. Brzy stejný zaměstnanec vstoupil do serverovny.
- Systém nefunguje.
James se podíval na server. Na plátně tančil zajímavý a známý vzor různobarevných tvarů – chaoticky se svíjející a proplétající trubky. Všichni jsme někdy viděli tento spořič obrazovky. Bylo to krásně vykreslené a doslova hypnotizující.
James stiskl tlačítko a vzor zmizel. Spěchal k pokladně a cestou potkal zaměstnance, který se k němu vracel.
— Systém opět funguje.
Pokud dokážete udělat mentální facepalm, přesně to James udělal. Spořič obrazovky. Používá OpenGL. A proto během provozu spotřebovává všechny zdroje procesoru serveru. V důsledku toho každé volání na server končí časovým limitem.
James se vrátil do serverovny, přihlásil se a nahradil spořič obrazovky krásnými dýmkami prázdnou obrazovkou. To znamená, že místo spořiče obrazovky, který spotřebovává 100 % zdrojů procesoru, jsem nainstaloval jiný, který zdroje nespotřebovává. Pak jsem čekal 10 minut, abych zkontroloval svůj odhad.
Když James dorazil do dalšího kina, přemýšlel, jak vysvětlit svému manažerovi, že právě letěl 800 km, aby vypnul spořič obrazovky.
Havárie během určité fáze měsíce
Pravdivý příběh. Jednoho dne se objevila softwarová chyba, která závisela na fázi měsíce. Existovala malá rutina, která se běžně používala v různých programech MIT k výpočtu přiblížení skutečné fázi Měsíce. GLS zabudoval tuto rutinu do programu LISP, který při zápisu souboru vytiskl řádek s časovým razítkem dlouhým téměř 80 znaků. Bylo velmi vzácné, že by první řádek zprávy skončil příliš dlouhý a vedl k dalšímu řádku. A když program později přečetl tento soubor, proklel. Délka prvního řádku závisela na přesném datu a čase a také na délce specifikace fáze v době tisku časového razítka. To znamená, že chyba doslova závisela na fázi měsíce!
První papírové vydání (Steele-1983) obsahoval příklad takové linky, která vedla k popsané chybě, ale sazeč ji „opravil“. To bylo od té doby popsáno jako „chyba fáze měsíce“.
Buďte však opatrní s předpoklady. Před několika lety se inženýři z CERNu (Evropské centrum pro jaderný výzkum) setkali s chybami při experimentech prováděných ve velkém elektron-pozitronovém urychlovači. Protože počítače aktivně zpracovávají obrovské množství dat generovaných tímto zařízením, než výsledek ukázaly vědcům, mnozí spekulovali, že software byl nějak citlivý na fázi měsíce. Několik zoufalých inženýrů se dostalo na dno pravdy. Chyba vznikla mírnou změnou geometrie 27 km dlouhého prstence v důsledku deformace Země při přechodu Měsíce! Tento příběh vstoupil do fyzikálního folklóru jako „Newtonova pomsta na částicové fyzice“ a jako příklad spojení mezi nejjednoduššími a nejstaršími fyzikálními zákony a nejpokročilejšími vědeckými koncepty.
Spláchnutí záchodu zastaví vlak
Nejlepší hardwarová chyba, o které jsem kdy slyšel, byla ve vysokorychlostním vlaku ve Francii. Chyba vedla k nouzovému brzdění vlaku, ale pouze v případě, že na palubě byli cestující. V každém takovém případě byl vlak vyřazen z provozu, zkontrolován, ale nic se nenašlo. Poté byl poslán zpět na čáru a okamžitě zastavil.
Při jedné z kontrol šel strojník cestující ve vlaku na toaletu. Brzy se smyl, BUM! Nouzové zastavení.
Inženýr kontaktoval řidiče a zeptal se:
— Co jsi dělal těsně před brzděním?
- No, při sestupu jsem zpomalil...
Bylo to zvláštní, protože za normálního provozu vlak zpomaluje ve sjezdech desítkykrát. Vlak se rozjel a při dalším klesání strojvedoucí varoval:
- Zpomalím.
Se nic nestalo.
— Co jste dělali při posledním brzdění? - zeptal se řidič.
- No... byl jsem na záchodě...
- Tak jdi na záchod a udělej to, co jsi udělal, až půjdeme zase dolů!
Inženýr šel na záchod, a když řidič varoval: „Zpomaluji,“ spláchl vodu. Vlak samozřejmě okamžitě zastavil.
Nyní mohli problém reprodukovat a potřebovali najít příčinu.
Po dvou minutách si všimli, že kabel dálkového ovládání motorové brzdy (vlak měl na každém konci jeden motor) je odpojený od stěny elektrické skříně a leží na relé, které ovládalo solenoid zásuvkové zástrčky... Když relé byl zapnutý, rušil brzdový kabel a ochrana systému proti poruchám jednoduše zahrnovala nouzové brzdění.
Brána, která nenáviděla FORTRAN
Před několika měsíci jsme si všimli, že síťová připojení na pevnině [toto bylo na Havaji] jsou velmi, velmi pomalá. To může trvat 10-15 minut a pak se to náhle objeví znovu. Po nějaké době si mi kolega stěžoval, že síťová spojení na pevnině vůbec nefunguje. Měl nějaký FORTRAN kód, který bylo potřeba zkopírovat do počítače na pevnině, ale nešlo to, protože „síť nevydržela dostatečně dlouho na to, aby se nahrání na FTP dokončilo“.
Ano, ukázalo se, že k výpadkům sítě došlo, když se kolega pokusil FTP soubor se zdrojovým kódem ve FORTRANu poslat na stroj na pevnině. Pokusili jsme se soubor archivovat: pak byl zkopírován hladce (ale cílový počítač neměl unpacker, takže problém nebyl vyřešen). Nakonec jsme "rozdělili" FORTRAN kód na velmi malé kousky a poslali je jeden po druhém. Většina fragmentů byla zkopírována bez problémů, ale pár kusů neprošlo, nebo přešlo mnoho pokusy.
Když jsme problematické pasáže prozkoumali, zjistili jsme, že mají něco společného: všechny obsahovaly bloky komentářů, které začínaly a končily řádky s velkým C (jak kolega raději komentoval ve FORTRANu). Poslali jsme e-maily síťovým expertům na pevnině a požádali o pomoc. Samozřejmě chtěli vidět vzorky našich souborů, které nebylo možné přenést přes FTP... ale naše dopisy se k nim nedostaly. Nakonec jsme přišli s jednoduchým popsatjak vypadají nepřenosné soubory. Fungovalo to :) [Dovolím si sem přidat příklad jednoho z problematických komentářů FORTRAN? Pravděpodobně to nemá cenu!]
Nakonec se nám to podařilo zjistit. Mezi naší částí kampusu a pevninskou sítí byla nedávno instalována nová brána. Měl VELKÉ potíže s přenosem paketů, které obsahovaly opakované bity velkého C! Jen několik z těchto paketů by mohlo zabrat všechny prostředky brány a zabránit většině ostatních paketů v průchodu. Stěžovali jsme si u výrobce brány... a oni odpověděli: „Ach, ano, čelíte chybě opakovaného C! Už o něm víme." Problém jsme nakonec vyřešili zakoupením nové brány od jiného výrobce (na obranu prvně jmenovaného, nemožnost přenosu programů FORTRAN může být pro někoho výhodou!).
Obtížné časy
Před pár lety, když jsem pracoval na vytvoření ETL systému v Perlu, aby se snížily náklady na 40. fázi klinických studií, potřeboval jsem zpracovat asi 000 1 dat. Dva z nich testem neprošli. To mě příliš netrápilo, protože tato data byla převzata z dat poskytnutých klientem, což bylo často, no, překvapivé. Ale když jsem zkontroloval původní data, ukázalo se, že tato data jsou 2011. ledna 1 a 2007. ledna 30. Myslel jsem, že chyba je v programu, který jsem právě napsal, ale ukázalo se, že je již XNUMX let starý . To může znít záhadně pro ty, kteří neznají softwarový ekosystém. Kvůli dlouhodobému rozhodnutí jiné společnosti vydělávat peníze mi můj klient zaplatil za opravu chyby, kterou jedna společnost zavedla náhodou a druhá záměrně. Abyste pochopili, o čem mluvím, musím mluvit o společnosti, která přidala funkci, která se nakonec stala chybou, a také o několika dalších zajímavých událostech, které přispěly k záhadné chybě, kterou jsem opravil.
Za starých dobrých časů počítače Apple někdy spontánně přenastavovaly své datum na 1. leden 1904. Důvod byl jednoduchý: ke sledování data a času používal bateriově napájené „systémové hodiny“. Co se stalo, když vybila baterie? Počítače začaly sledovat datum podle počtu sekund od začátku epochy. Epochou jsme mysleli referenční původní datum a pro Macintosh to byl 1. leden 1904. A po vybití baterie bylo aktuální datum resetováno na zadané datum. Ale proč se to stalo?
Dříve Apple používal 32 bitů k ukládání počtu sekund od původního data. Jeden bit může uložit jednu ze dvou hodnot - 1 nebo 0. Dva bity mohou uložit jednu ze čtyř hodnot: 00, 01, 10, 11. Tři bity - jedna hodnota z osmi: 000, 001, 010, 011, 100 , 101, 110, 111 atd. A 32 může uložit jednu z 232 hodnot, tedy 4 294 967 296 sekund. U dat Apple se to rovnalo přibližně 136 letům, takže starší počítače Mac nemohou zpracovat data po roce 2040. A pokud se vybije systémová baterie, datum se resetuje na 0 sekund od začátku epochy a datum musíte nastavit ručně pokaždé, když zapnete počítač (nebo dokud si nekoupíte novou baterii).
Rozhodnutí Applu ukládat data jako sekundy od epochy však znamenalo, že jsme nemohli zpracovat data před epochou, což mělo dalekosáhlé důsledky, jak uvidíme. Apple představil funkci, nikoli chybu. Mimo jiné to znamenalo, že operační systém Macintosh byl imunní vůči „chybě tisíciletí“ (což se nedalo říci o mnoha aplikacích pro Mac, které měly vlastní datové systémy pro obcházení omezení).
Pokračuj. Použili jsme Lotus 1-2-3, „zabijáckou aplikaci“ IBM, která pomohla zahájit revoluci PC, ačkoli počítače Apple měly VisiCalc, díky kterému byl osobní počítač úspěšný. Upřímně řečeno, kdyby se neobjevily 1-2-3, PC by sotva vzlétly a historie osobních počítačů by se mohla vyvíjet velmi odlišně. Lotus 1-2-3 nesprávně považoval rok 1900 za přestupný rok. Když Microsoft vydal svou první tabulku, Multiplan, získal malý podíl na trhu. A když spustili projekt Excel, rozhodli se nejen zkopírovat schéma pojmenování řádků a sloupců z Lotusu 1-2-3, ale také zajistit kompatibilitu chyb tím, že záměrně považovali rok 1900 za přestupný rok. Tento problém přetrvává dodnes. To znamená, že v 1-2-3 to byla chyba, ale v Excelu to bylo vědomé rozhodnutí, které zajistilo, že všichni uživatelé 1-2-3 mohli importovat své tabulky do Excelu bez změny dat, i když byla nesprávná.
Ale byl tu další problém. Nejprve Microsoft vydal Excel pro Macintosh, který neuznával data před 1. lednem 1904. A v Excelu byl 1. leden 1900 považován za začátek éry. Vývojáři proto provedli změnu tak, aby jejich program rozpoznal typ doby a uložil v sobě data v souladu s požadovanou dobou. Microsoft o tom dokonce napsal vysvětlující článek. A toto rozhodnutí vedlo k mému bugu.
Můj systém ETL obdržel excelové tabulky od zákazníků, které byly vytvořeny na Windows, ale mohly být vytvořeny i na Macu. Začátek éry v tabulce proto mohl být buď 1. leden 1900, nebo 1. leden 1904. Jak to zjistit? Formát souboru Excel zobrazuje potřebné informace, ale analyzátor, který jsem použil, je neukázal (nyní ano) a předpokládal, že znáte epochu pro konkrétní tabulku. Pravděpodobně jsem mohl strávit více času pochopením binárního formátu Excelu a odesláním opravy autorovi analyzátoru, ale měl jsem pro klienta mnohem víc práce, takže jsem rychle napsal heuristiku, abych určil epochu. Byla jednoduchá.
V Excelu může být datum 5. července 1998 reprezentováno ve formátu "07-05-98" (zbytečný americký systém), "5. července 98", "5. července 1998", "5-Jul-98" popř. nějaký jiný formát. další zbytečný formát (ironií je, že jeden z formátů, který moje verze Excelu nenabízela, byl ISO 8601). V tabulce však bylo neformátované datum uloženo buď jako "35981" pro epochu-1900 nebo "34519" pro epochu-1904 (čísla představují počet dní od epochy). Jednoduše jsem použil jednoduchý analyzátor k extrahování roku z formátovaného data a poté jsem použil analyzátor Excel k extrahování roku z neformátovaného data. Pokud se obě hodnoty lišily o 4 roky, pak jsem věděl, že používám systém s epochou-1904.
Proč jsem nepoužil formátovaná data? Protože 5. červenec 1998 může být formátován jako "červenec 98" se ztraceným dnem v měsíci. Obdrželi jsme tabulky od tolika společností, které je vytvářely tolika různými způsoby, že bylo na nás (v tomto případě na mně), abychom data zjistili. Kromě toho, pokud to Excel udělá správně, měli bychom také!
Zároveň jsem narazil na 39082. Připomenu, že Lotus 1-2-3 považoval rok 1900 za přestupný rok a to se věrně opakovalo i v Excelu. A protože to přidalo jeden den k roku 1900, mnoho funkcí pro výpočet data mohlo být pro tento den chybných. To znamená, že 39082 mohlo být 1. ledna 2011 (na počítačích Mac) nebo 31. prosince 2006 (na systému Windows). Pokud můj „parser roku“ extrahoval rok 2011 z naformátované hodnoty, pak je vše v pořádku. Ale protože analyzátor Excelu neví, jaká epocha se používá, výchozí je epocha-1900 a vrací rok 2006. Moje aplikace viděla, že rozdíl je 5 let, považovala to za chybu, zaprotokolovala to a vrátila neformátovanou hodnotu.
Abych to obešel, napsal jsem toto (pseudokód):
diff = formatted_year - parsed_year
if 0 == diff
assume 1900 date system
if 4 == diff
assume 1904 date system
if 5 == diff and month is December and day is 31
assume 1904 date system
A pak bylo všech 40 000 dat analyzováno správně.
Uprostřed velkých tiskových úloh
Na začátku osmdesátých let pracoval můj otec ve společnosti Storage Technology, dnes již neexistující divizi, která vytvářela páskové jednotky a pneumatické systémy pro vysokorychlostní podávání pásek.
Přepracovali jednotky tak, aby mohly mít jednu centrální jednotku „A“ připojenou k sedmi jednotkám „B“ a malý operační systém v RAM, který řídil jednotku „A“, mohl delegovat operace čtení a zápisu na všechny jednotky „B“.
Při každém spuštění jednotky „A“ bylo nutné do periferní jednotky připojené k „A“ vložit disketu, aby se operační systém nahrál do její paměti. Bylo to extrémně primitivní: výpočetní výkon obstarával 8bitový mikrokontrolér.
Cílovou skupinou pro taková zařízení byly společnosti s velmi velkými datovými sklady – banky, obchodní řetězce atd. – které potřebovaly tisknout velké množství adresních štítků nebo bankovních výpisů.
Jeden klient měl problém. Uprostřed tiskové úlohy může jeden konkrétní disk „A“ přestat fungovat a způsobit zastavení celé úlohy. Aby se obnovil chod disku, museli zaměstnanci vše restartovat. A pokud se to stalo uprostřed šestihodinového úkolu, pak se ztratilo obrovské množství drahého počítačového času a narušil se harmonogram celé operace.
Technici byli vysláni z Storage Technologies. Ale navzdory jejich nejlepšímu úsilí nebyli schopni chybu reprodukovat za testovacích podmínek: zdálo se, že k ní došlo uprostřed velkých tiskových úloh. Problém nebyl v hardwaru, vyměnili vše, co se dalo: RAM, mikrokontrolér, disketová mechanika, všechny myslitelné části páskové mechaniky - problém přetrvával.
Poté technici zavolali centrálu a zavolali Experta.
Expert popadl židli a šálek kávy, posadil se do počítačové učebny – v té době tam byly místnosti vyhrazené počítačům – a sledoval, jak zaměstnanci řadili do fronty velkou tiskovou úlohu. Expert čekal, že dojde k selhání – a stalo se. Všichni se podívali na Experta, ale on neměl tušení, proč se to stalo. Nařídil tedy, aby byla zakázka znovu zařazena do fronty a všichni zaměstnanci a technici se vrátili do práce.
Expert se opět posadil do křesla a začal čekat na selhání. Uběhlo asi šest hodin a došlo k poruše. Expert opět neměl žádné nápady, kromě toho, že se vše odehrálo v místnosti plné lidí. Nařídil restartovat misi, posadil se a čekal.
Při třetím selhání si Expert něčeho všiml. K selhání došlo, když personál vyměnil pásky na cizí jednotce. K poruše navíc došlo, jakmile jeden ze zaměstnanců prošel určitou dlaždicí na podlaze.
Zvýšená podlaha byla vyrobena z hliníkových dlaždic položených ve výšce 6 až 8 palců. Pod zvýšenou podlahou vedly četné dráty od počítačů, aby někdo omylem nešlápl na důležitý kabel. Dlaždice byly položeny velmi těsně, aby se pod zdvojenou podlahu nedostaly nečistoty.
Znalec si uvědomil, že jedna z dlaždic je zdeformovaná. Když zaměstnanec stoupl na jeho roh, okraje dlaždice se otíraly o sousední dlaždice. Odíraly se s nimi i plastové části, které spojovaly dlaždice, což způsobovalo statické mikrovýboje, které vytvářely vysokofrekvenční rušení.
RAM je dnes mnohem lépe chráněna před vysokofrekvenčním rušením. Ale v těch letech tomu tak nebylo. Odborník si uvědomil, že toto rušení narušilo paměť a s ní i provoz operačního systému. Zavolal podpůrnou službu, objednal nové dlaždice, sám je nainstaloval a problém zmizel.
Je příliv!
Příběh se odehrál v serverové místnosti, ve čtvrtém nebo pátém patře kanceláře v Portsmouthu (myslím), v oblasti doků.
Jednoho dne unixový server s hlavní databází havaroval. Restartovali ho, ale on šťastně padal dál a znovu. Rozhodli jsme se zavolat někomu z podpůrné služby.
Ten podpůrný... myslím, že se jmenoval Mark, ale to je jedno... Nemyslím si, že ho znám. Na tom nezáleží, opravdu. Zůstaňme u Marka, ano? Skvělý.
Takže o pár hodin později dorazil Mark (z Leedsu do Portsmouthu to není daleko, víte), zapnul server a vše fungovalo bez problémů. Typická zatracená podpora, klient se kvůli tomu hodně rozčiluje. Mark se podívá do souborů protokolu a nenajde nic nevhodného. Mark se tedy vrátí do vlaku (nebo jakýmkoli způsobem dopravy, kterým přijel, mohla to být chromá kráva, pokud vím... každopádně na tom nezáleží, ano?) a zamíří zpět do Leedsu. den.
Ten samý večer se server znovu zhroutil. Příběh je stejný... server se nezvedá. Mark se snaží pomoci vzdáleně, ale klient nemůže spustit server.
Další vlak, autobus, citronová pusinka nebo jiné svinstvo a Mark je zpět v Portsmouthu. Podívej, server naběhne bez problémů! Zázrak. Mark stráví několik hodin kontrolou, zda je vše v pořádku s operačním systémem nebo softwarem, a vyráží do Leedsu.
Kolem poloviny dne se server zhroutí (uklidněte se!). Tentokrát se zdá rozumné přivést lidi z hardwarové podpory, aby server nahradili. Ale ne, po cca 10 hodinách to také padá.
Situace se opakovala několik dní. Server funguje, asi po 10 hodinách spadne a další 2 hodiny se nespustí. Zkontrolovali chlazení, úniky paměti, zkontrolovali vše, ale nic nenašli. Pak srážky ustaly.
Týden uběhl bezstarostně... všichni byli šťastní. Šťastný, dokud to všechno nezačne znovu. Obrázek je stejný. 10 hodin práce, 2-3 hodiny odstávky...
A pak někdo (myslím, že mi řekli, že tato osoba nemá s IT nic společného) řekl:
"To je příliv!"
Výkřik se setkal s prázdnými pohledy a něčí ruka pravděpodobně zaváhala u tlačítka bezpečnostního volání.
"Přestává fungovat s přílivem."
To by se zdálo být zcela cizím konceptem pro pracovníky IT podpory, kteří pravděpodobně nebudou číst ročenku Tide, zatímco sedí u kávy. Vysvětlili, že to nemůže nijak souviset s přílivem, protože server fungoval týden bez poruch.
"Minulý týden byl příliv nízký, ale tento týden je vysoký."
Trochu terminologie pro ty, kteří nemají jachtařskou licenci. Příliv a odliv závisí na měsíčním cyklu. A jak se Země otáčí, každých 12,5 hodiny gravitační síla Slunce a Měsíce vytvoří přílivovou vlnu. Na začátku 12,5hodinového cyklu je příliv, uprostřed cyklu odliv a na konci opět příliv. Ale jak se mění dráha Měsíce, mění se i rozdíl mezi odlivem a přílivem. Když je Měsíc mezi Sluncem a Zemí nebo na opačné straně Země (měsíc v úplňku nebo bez měsíce), dostáváme syzygynské přílivy – nejvyšší přílivy a nejnižší odlivy. Při půlměsíci dostáváme kvadraturní přílivy - nejnižší přílivy. Rozdíl mezi těmito dvěma extrémy se velmi zmenšuje. Lunární cyklus trvá 28 dní: syzygický - kvadraturní - syzygický - kvadraturní.
Když technikům vysvětlili podstatu přílivových sil, okamžitě je napadlo, že musí zavolat policii. A celkem logické. Ale ukázalo se, že ten chlap měl pravdu. O dva týdny dříve kotvil torpédoborec nedaleko od kanceláře. Pokaždé, když ji příliv zvedl do určité výšky, radarové stanoviště lodi skončilo na úrovni podlahy serverovny. A radar (nebo zařízení pro elektronický boj nebo nějaká jiná vojenská hračka) vytvořil chaos v počítačích.
Letová mise pro raketu
Dostal jsem za úkol přenést velký (asi 400 tisíc řádků) systém řízení a monitorování raketového startu na nové verze operačního systému, kompilátoru a jazyka. Přesněji řečeno, ze Solaris 2.5.1 na Solaris 7 a ze systému Verdix Ada Development System (VADS), napsaného v Ada 83, do systému Rational Apex Ada, napsaného v Ada 95. VADS zakoupila společnost Rational a její produkt byl zastaralý, ačkoli Rational se snažil implementovat kompatibilní verze balíčků specifických pro VADS, aby usnadnil přechod na kompilátor Apex.
Tři lidé mi pomohli jednoduše zkompilovat kód čistě. Trvalo to dva týdny. A pak jsem pracoval na svém, aby systém fungoval. Stručně řečeno, byla to nejhorší architektura a implementace softwarového systému, se kterou jsem se setkal, takže dokončení portu trvalo další dva měsíce. Systém byl poté odeslán k testování, které trvalo několik dalších měsíců. Chyby, které se při testování našly, jsem ihned opravil, ale jejich počet rychle ubýval (zdrojový kód byl produkční systém, takže jeho funkčnost fungovala celkem spolehlivě, jen jsem musel odstranit chyby, které vznikly při adaptaci na nový kompilátor). Nakonec, když vše fungovalo, jak mělo, jsem byl převeden na jiný projekt.
A v pátek před Dnem díkůvzdání zazvonil telefon.
Start rakety měl být testován zhruba za tři týdny a při laboratorních testech odpočítávání byla sekvence příkazů zablokována. V reálném životě by to test přerušilo, a pokud by k zablokování došlo během několika sekund po nastartování motoru, došlo by v pomocných systémech k několika nevratným akcím, které by vyžadovaly dlouhou - a nákladnou - připravenost rakety. Nezačalo by to, ale spousta lidí by byla velmi naštvaná kvůli ztrátě času a spousty, spousty peněz. Nedovolte, aby vám někdo řekl, že ministerstvo obrany utrácí peníze neuváženě – nikdy jsem se nesetkal se smluvním manažerem, který by nedával rozpočet na první nebo na druhé místo a poté na harmonogram.
V předchozích měsících byla tato výzva k odpočítávání spuštěna stokrát v mnoha variantách, jen s několika menšími škytavkami. Pravděpodobnost, že k tomu dojde, byla tedy velmi nízká, ale její důsledky byly velmi významné. Vynásobte oba tyto faktory a pochopíte, že zprávy mi a desítkám inženýrů a manažerů předpovídaly zničený prázdninový týden.
A pozornost byla věnována mně jako osobě, která přenesla systém.
Stejně jako u většiny systémů kritických z hlediska zabezpečení bylo zaznamenáno mnoho parametrů, takže bylo poměrně snadné identifikovat několik řádků kódu, které byly provedeny před zhroucením systému. A samozřejmě na nich nebylo nic neobvyklého, stejné výrazy byly úspěšně provedeny doslova tisíckrát během jednoho běhu.
Zavolali jsme lidi z Apexu do Rationalu, protože to byli oni, kdo vyvinul kompilátor a některé rutiny, které vyvinuli, byly volány v podezřelém kódu. Na ně (a na všechny ostatní) udělalo dojem, že je potřeba přijít na kořen problému doslova národního významu.
Protože v časopisech nebylo nic zajímavého, rozhodli jsme se pokusit problém reprodukovat v místní laboratoři. Nebyl to snadný úkol, protože k události došlo přibližně jednou za 1000 jízd. Jedním z podezřelých důvodů bylo, že volání funkce mutex vyvinuté dodavatelem (součást migračního balíčku VADS) Unlock nevedlo k odemčení. Zpracovací vlákno, které funkci volalo, zpracovalo zprávy srdečního tepu, které nominálně přicházely každou sekundu. Zvýšili jsme frekvenci na 10 Hz, tedy 10x za vteřinu, a začali jsme běžet. Asi po hodině se systém zablokoval. V logu jsme viděli, že sekvence zaznamenaných zpráv byla stejná jako při neúspěšném testu. Udělali jsme několik dalších běhů, systém byl trvale zablokován 45-90 minut po startu a pokaždé, když protokol obsahoval stejnou trasu. I když jsme technicky spouštěli jiný kód - frekvence zpráv byla jiná - chování systému bylo stejné, takže jsme byli přesvědčeni, že tento scénář zatížení způsobuje stejný problém.
Nyní jsme potřebovali zjistit, kde přesně došlo k zablokování v posloupnosti výrazů.
Tato implementace systému používala systém úloh Ada a používala ho neuvěřitelně špatně. Úlohy jsou v Ada souběžně spustitelný konstrukt na vysoké úrovni, něco jako vlákna provádění, pouze zabudované do samotného jazyka. Když dva úkoly potřebují komunikovat, „nastavují schůzku“, vyměňují si potřebná data a poté schůzku zastaví a vrátí se ke svým nezávislým provedením. Systém byl však implementován jinak. Poté, co se cílový úkol setkal, se tento cílový úkol setkal s dalším úkolem, který se pak setkal s třetím úkolem, a tak dále, dokud nebylo dokončeno nějaké zpracování. Poté byla všechna tato setkání dokončena a každý úkol se musel vrátit ke svému provedení. To znamená, že jsme měli co do činění s nejdražším systémem volání funkcí na světě, který zastavil celý proces „multitaskingu“, zatímco zpracovával část vstupních dat. A předtím to nevedlo k problémům jen proto, že propustnost byla velmi nízká.
Tento mechanismus úlohy jsem popsal, protože když bylo požadováno setkání nebo se očekávalo jeho dokončení, mohlo dojít k „přepnutí úlohy“. To znamená, že procesor by mohl začít zpracovávat další úlohu, která je připravena k provedení. Ukazuje se, že když je jeden úkol připraven k setkání s jiným úkolem, může se začít vykonávat úplně jiný úkol a nakonec se řízení vrátí k prvnímu setkání. A mohou nastat další události, které způsobí přepnutí úlohy; jednou takovou událostí je volání systémové funkce, jako je tisk nebo provedení mutexu.
Abych pochopil, který řádek kódu způsobuje problém, potřeboval jsem najít způsob, jak zaznamenat postup posloupností příkazů, aniž bych spouštěl přepínač úloh, což by zabránilo zhroucení. Takže jsem nemohl využít Put_Line()abyste se vyhnuli provádění I/O operací. Mohl bych nastavit proměnnou čítače nebo něco podobného, ale jak mohu vidět její hodnotu, když ji nemohu zobrazit na obrazovce?
Při zkoumání logu se také ukázalo, že i přes zamrznutí zpracování heartbeat zpráv, které zablokovalo všechny I/O operace procesu a znemožnilo provedení dalšího zpracování, byly nadále vykonávány další nezávislé úlohy. To znamená, že práce nebyla zablokována úplně, pouze (kritický) řetězec úkolů.
Toto bylo vodítko potřebné k vyhodnocení blokovacího výrazu.
Vytvořil jsem balíček Ada, který obsahoval úkol, výčtový typ a globální proměnnou tohoto typu. Vyčíslitelné literály byly vázány na konkrétní výrazy problematické sekvence (např. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked) a poté do něj vložili přiřazovací výrazy, které přiřadily odpovídající výčet globální proměnné. Vzhledem k tomu, že objektový kód toho všeho jednoduše uložil konstantu do paměti, přepínání úloh v důsledku jejího provádění bylo krajně nepravděpodobné. Podezřívali jsme především výrazy, které by mohly přepnout úlohu, protože k zablokování došlo při provádění, nikoli při přepnutí úlohy zpět (z několika důvodů).
Úloha sledování jednoduše běžela ve smyčce a pravidelně kontrolovala, zda se hodnota globální proměnné nezměnila. Při každé změně byla hodnota uložena do souboru. Pak krátké čekání a nová kontrola. Proměnnou jsem zapsal do souboru, protože úloha byla provedena pouze tehdy, když ji systém vybral k provedení při přepínání úlohy v problémové oblasti. Cokoli se stalo v této úloze, neovlivní ostatní, nesouvisející zablokované úlohy.
Očekávalo se, že když systém dosáhne bodu provedení problematického kódu, globální proměnná se resetuje při přechodu na každý další výraz. Pak se stane něco, co způsobí přepnutí úlohy, a protože její frekvence provádění (10 Hz) je nižší než u monitorovací úlohy, mohl by monitor zachytit hodnotu globální proměnné a zapsat ji. V normální situaci bych mohl získat opakující se sekvenci podmnožiny výčtů: poslední hodnoty proměnné v době přepnutí úlohy. Při zavěšení by se globální proměnná již neměla měnit a poslední zapsaná hodnota bude indikovat, který výraz nebyl dokončen.
Spustil jsem kód se sledováním. Ztuhl. A monitoring fungoval jako hodinky.
Protokol obsahoval očekávanou sekvenci, která byla přerušena hodnotou indikující, že byl zavolán mutex Unlock, a úkol není dokončen - jako je tomu u tisíců předchozích hovorů.
Inženýři Apexu v tuto chvíli horečně analyzovali svůj kód a našli místo v mutexu, kde by teoreticky mohlo dojít k zámku. Jeho pravděpodobnost však byla velmi nízká, protože k zablokování mohla vést pouze určitá posloupnost událostí vyskytujících se v určitém čase. Murphyho zákony, lidi, to jsou Murphyho zákony.
Abych ochránil část kódu, kterou jsem potřeboval, nahradil jsem volání funkce mutex (postavená na funkčnosti mutex OS) malým nativním balíčkem mutex Ada pro řízení přístupu mutexu k tomuto kusu.
Vložil jsem to do kódu a spustil test. O sedm hodin později kód stále fungoval.
Můj kód byl předložen Rationalu, kde jej zkompilovali, rozebrali a zkontrolovali, že nepoužívá stejný přístup, jaký byl použit v problematických funkcích mutexu.
Tohle byla nejpřeplněnější kontrola kódu v mé kariéře 🙂 V místnosti se mnou bylo asi deset inženýrů a manažerů, dalších deset lidí bylo na konferenčním hovoru – a všichni zkoumali asi 20 řádků kódu.
Kód byl zkontrolován, byly sestaveny nové spustitelné soubory a odeslány k formálnímu regresnímu testování. O pár týdnů později byl test odpočítávání úspěšný a raketa odstartovala.
Dobře, to je všechno v pořádku, ale jaký je smysl příběhu?
Byl to naprosto odporný problém. Stovky tisíc řádků kódu, paralelní provádění, více než tucet interagujících procesů, špatná architektura a špatná implementace, rozhraní pro vestavěné systémy a utracené miliony dolarů. Žádný tlak, správně.
Nebyl jsem jediný, kdo na tomto problému pracoval, i když jsem byl v centru pozornosti, když jsem dělal portování. Ale i když jsem to udělal, neznamená to, že jsem rozuměl všem stovkám tisíc řádků kódu, nebo je dokonce přelétl. Kód a protokoly analyzovali inženýři po celé zemi, ale když mi řekli své hypotézy o příčinách selhání, trvalo mi jen půl minuty, než jsem je vyvrátil. A když jsem byl požádán o analýzu teorií, předal bych to někomu jinému, protože mi bylo zřejmé, že tito inženýři šli špatnou cestou. Zní to troufale? Ano, to je pravda, ale hypotézy a žádosti jsem odmítl z jiného důvodu.
Pochopil jsem podstatu problému. Nevěděl jsem přesně, kde se to děje nebo proč, ale věděl jsem, co se děje.
Za ta léta jsem nasbíral spoustu znalostí a zkušeností. Byl jsem jedním z průkopníků používání Ada a chápal jsem jeho výhody a nevýhody. Vím, jak běhové knihovny Ada zvládají úkoly a vyrovnávají se s paralelním spouštěním. A rozumím nízkoúrovňovému programování na úrovni paměti, registrů a assembleru. Jinými slovy, mám hluboké znalosti ve svém oboru. A použil jsem je k nalezení příčiny problému. Chybu jsem nejen obešel, ale pochopil jsem, jak ji najít ve velmi citlivém běhovém prostředí.
Takové příběhy o boji s kódem nejsou příliš zajímavé pro ty, kteří nejsou obeznámeni s rysy a podmínkami takového boje. Ale tyto příběhy nám pomáhají pochopit, co je potřeba k vyřešení skutečně obtížných problémů.
Chcete-li vyřešit opravdu těžké problémy, musíte být víc než jen programátor. Musíte porozumět „osudu“ kódu, jak interaguje se svým prostředím a jak prostředí samotné funguje.
A pak budete mít svůj zničený prázdninový týden.
Je třeba pokračovat.
Zdroj: www.habr.com