See on valik Internetist pärit lugusid sellest, kuidas putukatel on mõnikord täiesti uskumatud ilmingud. Võib-olla on teil ka midagi öelda.
Auto allergia vaniljejäätisele
Lugu inseneridele, kes mõistavad, et ilmselge ei ole alati vastus ja et ükskõik kui kaugele toodud faktid ka ei tundu, on need siiski faktid. General Motors Corporationi Pontiaci osakond sai kaebuse:
Kirjutan teile teist korda ja ma ei süüdista teid, et te ei vasta, sest see kõlab hullumeelselt. Meie peres on kombeks süüa igal õhtul pärast õhtusööki jäätist. Jäätisesordid muutuvad iga kord ja peale õhtusööki valib terve pere, millist jäätist osta, misjärel lähen poodi. Ostsin hiljuti uue Pontiaci ja sellest ajast alates on minu jäätise hankimise reisid muutunud probleemiks. Näete, iga kord, kui ostan vanillijäätise ja tulen poest tagasi, ei lähe auto käima. Kui toon muud jäätist, käivitub auto probleemideta. Ma tahan esitada ühe tõsise küsimuse, ükskõik kui tobedalt see ka ei kõlaks: "Mis Pontiacis on, et see ei käivitu, kui toon vaniljejäätist, vaid käivitub kergesti, kui toon mõne muu maitsega jäätist?"
Nagu võite ette kujutada, oli osakonna president kirja suhtes skeptiline. Saatsin aga igaks juhuks inseneri kontrollima. Ta oli üllatunud, et talle tuli vastu jõukas, haritud mees, kes elab kaunis piirkonnas. Nad leppisid kokku, et kohtuvad kohe pärast õhtusööki, et saaks kahekesi poodi jäätisele minna. Sel õhtul oli see vanilje ja kui nad auto juurde tagasi jõudsid, ei hakanud see käima.
Insener tuli veel kolm õhtut. Esimesel korral oli jäätis šokolaadine. Auto läks käima. Teisel korral oli maasikajäätis. Auto läks käima. Kolmandal õhtul palus ta vanilli võtta. Auto ei käivitunud.
Ratsionaalselt arutledes keeldus insener uskumast, et auto on vaniljejäätisele allergiline. Seetõttu leppisin auto omanikuga kokku, et ta jätkab oma visiite seni, kuni leiab probleemile lahenduse. Ja tee peal hakkas ta märkmeid tegema: pani kirja kogu teabe, kellaaja, bensiini tüübi, poest saabumise ja tagasituleku aja jne.
Peagi taipas insener, et auto omanik kulutas vanillijäätise ostmisele vähem aega. Põhjuseks oli kauba paigutus poes. Vaniljejäätis oli kõige populaarsem ja seda hoiti poe esiküljel eraldi sügavkülmas, et seda oleks lihtsam leida. Ja kõik muud sordid olid poe tagaküljel ning õige sordi ja tasu leidmine võttis palju rohkem aega.
Nüüd oli küsimus insenerile: miks auto ei käivitunud, kui mootori väljalülitamise hetkest oli möödunud vähem aega? Kuna probleem oli ajas, mitte vaniljejäätises, leidis insener kiirelt vastuse: tegu oli gaasilukuga. Seda juhtus igal õhtul, kuid kui autoomanik rohkem aega jäätise otsimisele kulutas, jõudis mootor piisavalt maha jahtuda ja käivitus kergelt. Ja kui mees vanillijäätist ostis, oli mootor veel liiga kuum ja gaasilukk ei jõudnudki lahustuda.
Moraal: Isegi täiesti hullud probleemid on mõnikord tõelised.
crash bandicoot
Seda on valus kogeda. Programmeerijana harjud süüdistama oma koodi esimesena, teisena, kolmandana... ja kuskil kümnetuhandendal kohal süüdistad kompilaatorit. Ja nimekirjas allpool süüdistate juba seadmeid.
Siin on minu lugu riistvaravea kohta.
Mängu Crash Bandicoot jaoks kirjutasin koodi laadimiseks ja mälukaardile salvestamiseks. Sellise omapäise mänguarendaja jaoks oli see nagu jalutuskäik pargis: arvasin, et töö võtab mitu päeva. Siiski silusin koodi kuus nädalat. Teel lahendasin muid probleeme, kuid iga paari päeva tagant pöördusin mõneks tunniks selle koodi juurde tagasi. See oli agoonia.
Sümptom nägi välja selline: kui salvestate mängu praeguse läbimängimise ja pääsete juurde mälukaardile, läheb kõik peaaegu alati hästi... Kuid mõnikord katkeb lugemis- või kirjutamisoperatsioon ilma selge põhjuseta. Lühike salvestus kahjustab sageli mälukaarti. Kui mängija üritab päästa, ei õnnestu tal mitte ainult päästa, vaid ta hävitab ka kaardi. Jama.
Mõne aja pärast hakkas meie Sony produtsent Connie Bus paanikasse sattuma. Me ei saanud selle veaga mängu saata ja kuus nädalat hiljem ei saanud ma aru, mis probleemi põhjustas. Connie kaudu võtsime ühendust teiste PS1 arendajatega: kas keegi on millegi sarnasega kokku puutunud? Ei. Mälukaardiga kellelgi probleeme ei olnud.
Kui teil pole silumiseks ideid, jääb üle vaid "jaga ja valluta": eemaldage vigasest programmist üha rohkem koodi, kuni alles jääb suhteliselt väike fragment, mis endiselt probleemi põhjustab. See tähendab, et lõikad programmi jupikaupa ära, kuni alles jääb viga sisaldav osa.
Kuid asi on selles, et videomängust on väga raske tükke välja lõigata. Kuidas seda käivitada, kui eemaldasite gravitatsiooni jäljendava koodi? Või joonistada tegelasi?
Seetõttu peame asendama terved moodulid stubidega, mis teesklevad midagi kasulikku, kuid tegelikult teevad midagi väga lihtsat, mis ei sisalda vigu. Peame sellised kargud kirjutama, et mäng vähemalt töötaks. See on aeglane ja valus protsess.
Ühesõnaga, ma tegin seda. Eemaldasin järjest rohkem koodijuppe, kuni mulle jäi alles esialgne kood, mis seadistab süsteemi mängu käima, initsialiseerib renderdamise riistvara jne. Muidugi ei saanud ma selles etapis salvestamise ja laadimise menüüd luua, kuna pean kogu graafikakoodi jaoks looma tünni. Kuid ma võiksin teeselda, et olen kasutaja, kasutades (nähtamatut) salvestamise ja laadimise ekraani ning paluda salvestada ja seejärel mälukaardile kirjutada.
See jättis mulle väikese kooditüki, millel oli ülaltoodud probleem, kuid see juhtus ikkagi juhuslikult! Enamasti töötas kõik hästi, kuid aeg-ajalt esines tõrkeid. Eemaldasin peaaegu kogu mängu koodi, kuid viga oli endiselt elus. See oli mõistatuslik: järelejäänud kood ei teinud tegelikult midagi.
Mingil hetkel, ilmselt kella kolme paiku öösel, tuli mulle pähe mõte. Lugemis- ja kirjutamistoimingud (sisend/väljund) hõlmavad täpseid täitmisaegu. Kui töötate kõvaketta, mälukaardi või Bluetooth-mooduliga, teeb lugemise ja kirjutamise eest vastutav madala taseme kood seda vastavalt kella impulssidele.
Kella abil sünkroonitakse protsessoriga mitteühendatud seade protsessoris töötava koodiga. Kell määrab andmeedastuskiiruse – kiiruse, millega andmeid edastatakse. Kui on segadus ajastustega, siis on segaduses ka riistvara või tarkvara või mõlemad. Ja see on väga halb, sest andmed võivad kahjustada saada.
Mis siis, kui miski meie koodis ajab segi? Kontrollisin testprogrammi koodist kõike sellega seonduvat ja märkasin, et seadsime PS1-s programmeeritava taimeri 1 kHz peale (1000 tikku sekundis). Seda on üsna palju; vaikimisi töötab konsool käivitamisel 100 Hz. Ja enamik mänge kasutab seda sagedust.
Mänguarendaja Andy seadis taimeri 1 kHz peale, et liigutusi oleks täpsemalt arvutatud. Andy kipub üle parda minema ja kui me jäljendame gravitatsiooni, teeme seda nii täpselt kui võimalik!
Aga mis siis, kui taimeri kiirendamine mõjutaks kuidagi programmi üldist ajastust ja seega ka kella, mis reguleerib mälukaardi edastuskiirust?
Kommenteerisin taimeri koodi. Viga ei kordunud. Kuid see ei tähenda, et me selle parandasime, sest rike tekkis juhuslikult. Mis siis, kui mul lihtsalt vedas?
Paar päeva hiljem katsetasin uuesti katseprogrammiga. Viga ei kordunud. Läksin tagasi kogu mängu koodibaasi ja muutsin salvestamis- ja laadimiskoodi nii, et programmeeritav taimer lähtestaks enne mälukaardile juurdepääsu algväärtust (100 Hz) ja lähtestaks seejärel 1 kHz. Rohkem avariisid ei olnud.
Aga miks see juhtus?
Naasin uuesti testprogrammi juurde. Üritasin leida mingit mustrit 1 kHz taimeriga vea ilmnemisel. Lõpuks märkasin, et viga ilmneb siis, kui keegi mängib PS1 kontrolleriga. Kuna ma ise teeksin seda harva - miks peaksin salvestamise ja laadimise koodi testimisel kontrollerit vajama? - Ma isegi ei märganud seda sõltuvust. Aga ühel päeval ootas üks meie artist, et ma testimise lõpetaksin – ma ilmselt kirusin sel hetkel – ja keerutas närviliselt käes olevat kontrollerit. Tekkis viga. "Oota mida?!" Noh, tee seda uuesti!”
Kui mõistsin, et need kaks sündmust on omavahel seotud, suutsin vea hõlpsalt taasesitada: alustasin mälukaardile salvestamist, liigutasin kontrollerit ja rikkusin mälukaardi. Minu jaoks tundus see riistvaraviga.
Tulin Connie juurde ja rääkisin talle oma avastusest. Ta edastas teabe ühele PS1 kujundanud inseneridest. "Võimatu," vastas ta, "see ei saa olla riistvaraprobleem." Palusin Connie'l meie jaoks vestlust korraldada.
Insener helistas mulle ja me vaidlesime tema katkises inglise keeles ja minu (äärmiselt) katkises jaapani keeles. Lõpuks ütlesin: "Las ma saadan lihtsalt oma 30 rea testprogrammi, kus kontrolleri liigutamine põhjustab vea." Ta nõustus. Ütles, et see oli aja raiskamine ja et ta on kohutavalt hõivatud uue projekti kallal, kuid annaks järele, sest olime Sony jaoks väga oluline arendaja. Puhastasin oma testprogrammi ja saatsin selle talle.
Järgmisel õhtul (meie olime Los Angeleses ja tema Tokyos) helistas ta mulle ja palus kartlikult vabandust. See oli riistvaraprobleem.
Ma ei tea, milles viga täpselt oli, aga Sony peakorteris kuuldu põhjal, et kui seada taimer piisavalt kõrgele väärtusele, siis segas see taimeri kristalli läheduses emaplaadi komponente. Üks neist oli mälukaardi edastuskiiruse kontroller, mis määras ka kontrollerite edastuskiiruse. Ma ei ole insener, nii et võisin midagi sassi ajada.
Kuid lõpptulemus on see, et emaplaadi komponentide vahel esines häireid. Andmete samaaegsel edastamisel kontrolleri pordi ja mälukaardi pordi kaudu, mille taimer töötab sagedusel 1 kHz, läksid bitid kaduma, andmed kadusid ja kaart kahjustati.
Halvad lehmad
1980. aastatel kirjutas mu mentor Sergei tarkvara SM-1800 jaoks, mis on PDP-11 Nõukogude kloon. See mikroarvuti paigaldati äsja NSV Liidu olulise transpordisõlme Sverdlovski lähedal asuvasse raudteejaama. Uus süsteem oli mõeldud vagunite ja kaubaliikluse suunamiseks. Kuid see sisaldas tüütut viga, mis põhjustas juhuslikke kokkujooksmisi ja kokkujooksmisi. Kukkumised juhtusid alati siis, kui keegi õhtul koju läks. Kuid vaatamata põhjalikule uurimisele järgmisel päeval töötas arvuti kõigis käsitsi ja automaatsetes testides õigesti. See viitab tavaliselt võistlusseisundile või mõnele muule võistlusveale, mis esineb teatud tingimustel. Hilisõhtustest kõnedest väsinud Sergei otsustas asjaga tegeleda ja ennekõike aru saada, millised tingimused sorteerimisväljakul arvuti rikkeni viisid.
Esiteks kogus ta statistikat kõigi seletamatute kukkumiste kohta ning koostas kuupäeva ja kellaaja järgi graafiku. Muster oli ilmne. Pärast veel paaripäevast jälgimist mõistis Sergei, et suudab hõlpsasti ennustada tulevaste süsteemitõrgete aega.
Peagi sai ta teada, et häireid tekkisid alles siis, kui jaam sorteeris rongikoormaid Põhja-Ukrainast ja Lääne-Venemaalt pärit veiseid, mis suundusid lähedalasuvasse tapamajja. See oli iseenesest kummaline, sest tapamaja varustasid palju lähemal, Kasahstanis, asuvad farmid.
Tšernobõli tuumaelektrijaam plahvatas 1986. aastal ja radioaktiivne sadenemine muutis ümbritsevad alad elamiskõlbmatuks. Suured alad Põhja-Ukrainas, Valgevenes ja Lääne-Venemaal olid saastunud. Kahtlustades kõrget kiirgustaset saabuvates vagunites töötas Sergei välja meetodi selle teooria testimiseks. Elanikul oli dosimeetrite omamine keelatud, mistõttu Sergei registreeris end raudteejaamas mitme sõjaväelase juurde. Pärast mitut jooki viina õnnestus tal veenda sõdurit ühes kahtlases vankris kiirgustaset mõõtma. Selgus, et tase oli mitu korda kõrgem normaalväärtustest.
Veised ei eraldanud mitte ainult palju kiirgust, vaid selle tase oli nii kõrge, et see tõi kaasa juhusliku bittide kadumise jaama kõrval asuvas hoones asuva SM-1800 mälus.
NSV Liidus valitses toidupuudus ja võimud otsustasid segada Tšernobõli liha riigi teistest piirkondadest pärit lihaga. See võimaldas vähendada üldist radioaktiivsuse taset väärtuslikke ressursse kaotamata. Saanud sellest teada, täitis Sergei kohe väljarände dokumendid. Ja arvutijooks lõppes iseenesest, kui kiirgustase aja jooksul vähenes.
Läbi torude
Kunagi lõi Movietech Solutions kinode jaoks tarkvara, mis on mõeldud raamatupidamiseks, piletimüügiks ja üldjuhtimiseks. Lipulaevarakenduse DOS-versioon oli Põhja-Ameerika väikeste ja keskmise suurusega kinokettide seas üsna populaarne. Seega pole üllatav, et kui välja kuulutati Windows 95 versioon, mis oli integreeritud uusimate puuteekraanide ja iseteeninduskioskitega ning varustatud kõikvõimalike aruandlustööriistadega, sai ka see kiiresti populaarseks. Enamasti läks värskendus probleemideta. Kohalikud IT-töötajad paigaldasid uusi seadmeid, migreerisid andmeid ja äri jätkus. Välja arvatud siis, kui see ei kestnud. Kui see juhtus, saatis ettevõte välja Jamesi, hüüdnimega "Koristaja".
Ehkki hüüdnimi viitab pahatahtlikule tüübile, on koristaja lihtsalt kombinatsioon juhendajast, paigaldajast ja kõigist asjatundjatest. James veetis paar päeva kliendi saidil kõiki komponente kokku panemas ja seejärel veel paar päeva, õpetades personalile uue süsteemi kasutamist, lahendades tekkinud riistvaraprobleeme ja aidates tarkvara sisuliselt lapsekingades.
Seetõttu pole üllatav, et nendel kiiretel aegadel jõudis James kontorisse hommikul ja enne kui ta jõudis laua taha jõuda, tervitas teda juhataja, kes oli tavapärasest rohkem kofeiiniga täidetud.
"Ma kardan, et peate esimesel võimalusel minema Nova Scotiasse Annapolisesse." Kogu nende süsteem läks üles ja pärast öist koostööd nende inseneridega ei saa me aru, mis juhtus. Näib, et serveris on võrgu loomine ebaõnnestunud. Kuid alles pärast seda, kui süsteem oli mitu minutit töötanud.
— Kas nad ei pöördunud tagasi vana süsteemi juurde? - vastas James täiesti tõsiselt, kuigi vaimselt ajas ta üllatusest silmad suureks.
— Täpselt nii: nende IT-spetsialist “muutis prioriteete” ja otsustas lahkuda oma vana serveriga. James, nad paigaldasid süsteemi kuuele saidile ja maksid lihtsalt tasulise toe eest ning nende ettevõtet juhitakse nüüd nagu 1950ndatel.
James ajas end kergelt sirgu.
- See on teine asi. Olgu, alustame.
Annapolisesse jõudes leidis ta esimese asjana kliendi esimese teatrimaja, kus oli probleem. Lennujaamas tehtud kaardil tundus kõik korralik, kuid soovitava aadressi ümbrus tundus kahtlane. Mitte geto, vaid meenutab film noir’i. Kui James kesklinna äärekivi äärde parkis, lähenes talle prostituut. Arvestades Annapolise suurust, oli see tõenäoliselt ainus kogu linnas. Tema välimus tõi kohe meelde kuulsa tegelase, kes suurel ekraanil raha eest seksi pakkus. Ei, mitte Julia Robertsi, vaid Jon Voighti kohta [vihje filmile "Midnight Cowboy" - u. sõidurada].
Olles prostituudi teele saatnud, läks James kinno. Ümbruskond oli küll paremaks läinud, aga jättis siiski mahajooksmise mulje. Mitte, et James oleks liiga mures. Ta on varemgi armetutes kohtades käinud. Ja see oli Kanada, kus isegi röövlid on piisavalt viisakad, et öelda "aitäh" pärast rahakoti võtmist.
Kino külgsissepääs oli hämaras allees. James astus ukse juurde ja koputas. Peagi see kriuksus ja avanes kergelt.
- Kas sa oled koristaja? - kostis seest kähe hääl.
- Jah, see olen mina... ma tulin kõike parandama.
James astus kino fuajeesse. Ilmselt ei olnud muud valikut, jagasid töötajad külastajatele paberpileteid. See muutis finantsaruandluse keeruliseks, rääkimata huvitavamatest detailidest. Kuid töötajad tervitasid Jamesi kergendatult ja viisid ta kohe serveriruumi.
Esmapilgul oli kõik hästi. James logis serverisse ja kontrollis tavapäraseid kahtlaseid kohti. Pole probleemi. Siiski sulges James suurest ettevaatlikkusest serveri, vahetas võrgukaardi välja ja keeras süsteemi tagasi. Ta asus kohe täies mahus tööle. Töötajad hakkasid taas pileteid müüma.
James helistas Markile ja andis talle olukorrast teada. Pole raske ette kujutada, et James võib tahta jääda ja vaadata, kas juhtub midagi ootamatut. Ta läks trepist alla ja hakkas töötajatelt küsima, mis juhtus. Ilmselgelt on süsteem lakanud töötamast. Nad lülitasid selle välja ja sisse, kõik töötas. Kuid 10 minuti pärast kukkus süsteem välja.
Just sel hetkel juhtus midagi sarnast. Järsku hakkas piletisüsteem vigu loopima. Töötajad ohkasid ja haarasid paberpiletid ning James kiirustas serveriruumi. Serveriga tundus kõik hästi.
Siis sisenes üks töötajatest.
— Süsteem töötab jälle.
James oli hämmingus, sest ta polnud midagi teinud. Täpsemalt mitte midagi, mis süsteemi tööle paneks. Ta logis välja, võttis telefoni ja helistas oma ettevõtte tugiliinile. Peagi sisenes sama töötaja serveriruumi.
- Süsteem on maas.
James heitis pilgu teenindajale. Ekraanil tantsis huvitav ja tuttav mitmevärviliste kujundite muster - kaootiliselt väänlevad ja põimuvad torud. Me kõik oleme seda ekraanisäästjat mingil hetkel näinud. See oli kaunilt renderdatud ja sõna otseses mõttes hüpnotiseeriv.
James vajutas nuppu ja muster kadus. Ta kiirustas piletikassasse ja kohtas teel tema juurde tagasi pöörduvat töötajat.
— Süsteem töötab jälle.
Kui saate teha vaimse näopalmi, tegi James täpselt seda. Ekraanisäästja. See kasutab OpenGL-i. Seetõttu kulutab see töötamise ajal kõiki serveriprotsessori ressursse. Selle tulemusena lõpeb iga kõne serverile ajalõpuga.
James naasis serveriruumi, logis sisse ja asendas ekraanisäästja ilusate torudega tühja ekraaniga. See tähendab, et 100% protsessoriressurssidest tarbiva ekraanisäästja asemel installisin teise, mis ressursse ei tarbi. Seejärel ootasin 10 minutit, et oma oletust kontrollida.
Kui James järgmisesse kinno jõudis, mõtles ta, kuidas selgitada oma mänedžerile, et ta oli just lennanud 800 km, et ekraanisäästja välja lülitada.
Kokkupõrge teatud kuufaasis
Tõsilugu. Ühel päeval tekkis tarkvaraviga, mis sõltus kuu faasist. Seal oli väike rutiin, mida tavaliselt kasutati erinevates MIT-i programmides Kuu tõelise faasi lähenduse arvutamiseks. GLS ehitas selle rutiini LISP-programmi, mis faili kirjutamisel väljastaks rea, mille ajatempel on peaaegu 80 tähemärki. Väga harva juhtus, et sõnumi esimene rida läks liiga pikaks ja viis järgmisele reale. Ja kui programm hiljem seda faili luges, siis see kirus. Esimese rea pikkus sõltus täpsest kuupäevast ja kellaajast, samuti faasi spetsifikatsiooni pikkusest ajatempli trükkimise ajal. See tähendab, et viga sõltus sõna otseses mõttes kuu faasist!
Esimene paberväljaanne (Steele-1983) sisaldas näidet sellisest reast, mis viis kirjeldatud veani, kuid trükiladuja “parandas” selle. Sellest ajast alates on seda kirjeldatud kui "kuufaasi viga".
Ole aga oletustega ettevaatlik. Mõned aastad tagasi leidsid CERNi (Euroopa Tuumauuringute Keskus) insenerid Suure elektron-positroni põrkeseadme katsetes tehtud vigu. Kuna arvutid töötlevad enne tulemuste teadlastele näitamist aktiivselt selle seadme loodud tohutut andmemahtu, oletasid paljud, et tarkvara oli kuidagi tundlik kuu faasi suhtes. Mitmed meeleheitel insenerid said tõe põhja. Viga tekkis 27 km pikkuse rõnga geomeetria kergest muutumisest, mis on tingitud Maa deformatsioonist Kuu läbimise ajal! See lugu on jõudnud füüsika folkloori kui "Newtoni kättemaks osakeste füüsikale" ja näide seostest kõige lihtsamate ja vanimate füüsikaseaduste ning kõige arenenumate teaduslike kontseptsioonide vahel.
WC-poti loputamine peatab rongi
Parim riistvaraviga, millest ma kunagi kuulnud olen, oli Prantsusmaal kiirrongis. Viga põhjustas rongi hädapidurduse, kuid ainult siis, kui pardal oli reisijaid. Igal sellisel juhul võeti rong kasutusest välja, kontrolliti, kuid midagi ei leitud. Siis saadeti ta liinile tagasi ja ta kukkus koheselt seisma.
Ühe kontrolli ajal läks rongis reisinud insener tualetti. Ta pesi peagi minema, BOOM! Hädapeatus.
Insener võttis juhiga ühendust ja küsis:
— Mida sa tegid vahetult enne pidurdamist?
- Noh, ma aeglustasin laskumisel ...
See oli kummaline, sest normaalse töö käigus aeglustab rong laskumistel kümneid kordi. Rong liikus edasi ja järgmisel laskumisel juht hoiatas:
- Ma võtan tempot maha.
Midagi ei juhtunud.
— Mida sa viimasel pidurdamisel tegid? - küsis juht.
- Noh... ma olin tualetis...
- Noh, siis mine tualetti ja tee seda, mida sa tegid, kui me jälle alla läheme!
Insener läks tualetti ja kui juht hoiatas: "Ma aeglustan", lasi ta vett välja. Rong muidugi peatus kohe.
Nüüd suutsid nad probleemi taastoota ja pidid selle põhjuse leidma.
Kahe minuti pärast märkasid nad, et mootoripiduri puldi juhe (rongil oli mõlemas otsas üks mootor) on elektrikilbi seinast lahti ühendatud ja lebab releel, mis juhtis WC-pistiku solenoidi... Kui relee oli sisse lülitatud, tekitas see häireid piduritrossis ja süsteemi rikete eest kaitses lihtsalt hädapidurdus.
Värav, mis vihkas FORTRANI
Paar kuud tagasi märkasime, et võrguühendused mandril [see oli Hawaiil] muutuvad väga-väga aeglaseks. See võib kesta 10-15 minutit ja siis äkki uuesti. Mõne aja pärast kurtis kolleeg mulle, et võrguühendused mandril üldiselt ei tööta. Tal oli mingi FORTRAN-kood, mis tuli mandril asuvasse masinasse kopeerida, kuid seda ei saanud, sest "võrk ei pidanud FTP üleslaadimise lõpuleviimiseks piisavalt kaua vastu".
Jah, selgus, et võrgutõrkeid tekkis, kui kolleeg üritas FORTRANis lähtekoodiga faili mandril asuvasse masinasse FTP-ga saata. Proovisime faili arhiivida: siis kopeeriti see sujuvalt (aga sihtmasinal polnud lahtipakkijat, nii et probleem ei lahenenud). Lõpuks "jagasime" FORTRANi koodi väga väikesteks tükkideks ja saatsime need ükshaaval. Suurem osa fragmente kopeeriti probleemideta, kuid mõni tükk ei läinud läbi või läks pärast arvukad katsed.
Kui uurisime probleemseid lõike, avastasime, et neil on midagi ühist: need kõik sisaldasid kommentaariplokke, mis algasid ja lõppesid ridadega, mis koosnesid suurest C-st (nagu kolleeg eelistas kommenteerida FORTRANis). Saatsime mandri võrguekspertidele meili ja palusime abi. Muidugi taheti näha näidiseid meie failidest, mida ei saanud FTP kaudu edastada... aga meie kirjad ei jõudnud nendeni. Lõpuks leidsime lihtsa kirjeldadakuidas ülekantavad failid välja näevad. See toimis :) [Kas ma lisan siia näite ühest probleemsest FORTRANi kommentaarist? Tõenäoliselt pole seda väärt!]
Lõpuks õnnestus meil see välja mõelda. Hiljuti paigaldati meie ülikoolilinnaku osa ja mandrivõrgu vahele uus värav. Sellel oli tohutult raske edastada pakette, mis sisaldasid korduvaid suurtähte C! Vaid mõned neist pakettidest võivad hõivata kõik lüüsiressursid ja takistada enamiku teiste pakettide läbipääsu. Kaebasime lüüsi tootjale... ja nad vastasid: “Oh, jah, sa seisad silmitsi korduva C veaga! Me juba teame temast." Lõpuks lahendasime probleemi, ostes teiselt tootjalt uue lüüsi (esimese kaitseks võib FORTRANi programmide ülekandmise võimetus olla mõne jaoks eeliseks!).
Rasked ajad
Mõni aasta tagasi, töötades Perlis ETL-süsteemi loomisel, et vähendada 40. faasi kliiniliste uuringute kulusid, oli mul vaja töödelda umbes 000 1 kuupäeva. Kaks neist ei läbinud testi. See ei häirinud mind eriti, sest need kuupäevad võeti kliendi esitatud andmetest, mis olid sageli, ütleme nii, üllatavad. Kuid algandmeid kontrollides selgus, et need kuupäevad on 2011. jaanuar 1 ja 2007. jaanuar 30. Arvasin, et viga on äsja kirjutatud programmis, kuid selgus, et see oli juba XNUMX aastat vana. vana. See võib tunduda salapärane neile, kes pole tarkvara ökosüsteemiga tuttavad. Teise ettevõtte pikaajalise rahateenimisotsuse tõttu maksis mu klient mulle vea parandamise eest, mille üks ettevõte oli kogemata sisse toonud ja teine sihilikult. Et mõistaksite, millest ma räägin, pean ma rääkima ettevõttest, kes lisas funktsiooni, millest sai viga, ja mõnest muust huvitavast sündmusest, mis aitasid kaasa minu parandatud salapärasele veale.
Vanadel headel aegadel määrasid Apple'i arvutid mõnikord spontaanselt oma kuupäeva 1. jaanuarile 1904. Põhjus oli lihtne: see kasutas kuupäeva ja kellaaja jälgimiseks akutoitega "süsteemikella". Mis juhtus, kui aku tühjaks sai? Arvutid hakkasid kuupäeva jälgima sekundite arvu järgi alates ajastu algusest. Epohhi all pidasime silmas algset viitekuupäeva ja Macintoshi puhul oli see 1. jaanuar 1904. Ja pärast aku tühjenemist lähtestati praegune kuupäev määratud kuupäevale. Aga miks see juhtus?
Varem kasutas Apple algkuupäevast möödunud sekundite salvestamiseks 32 bitti. Üks bitt võib salvestada ühe kahest väärtusest - 1 või 0. Kaks bitti võivad salvestada ühe neljast väärtusest: 00, 01, 10, 11. Kolm bitti - üks väärtus kaheksast: 000, 001, 010, 011, 100 , 101, 110, 111 jne. Ja 32 võiks salvestada ühe 232 väärtusest, see tähendab 4 294 967 296 sekundit. Apple'i kuupäevade puhul võrdub see umbes 136 aastaga, nii et vanemad Macid ei suuda 2040. aastast hilisemaid kuupäevi käsitleda. Ja kui süsteemi aku tühjeneb, lähtestatakse kuupäev 0 sekundile ajastu algusest ja peate kuupäeva käsitsi määrama iga kord, kui arvuti sisse lülitate (või kuni uue aku ostmiseni).
Apple'i otsus salvestada kuupäevi sekunditena alates ajastust tähendas aga seda, et me ei saanud käsitleda kuupäevi enne ajastut, millel olid kaugeleulatuvad tagajärjed, nagu me näeme. Apple tutvustas funktsiooni, mitte viga. Muuhulgas tähendas see, et Macintoshi operatsioonisüsteem oli immuunne "millennium bugile" (mida ei saanud öelda paljude Maci rakenduste kohta, millel olid piirangutest kõrvalehoidmiseks oma kuupäevasüsteemid).
Lase käia. Kasutasime Lotus 1-2-3, IBMi "tapjarakendust", mis aitas käivitada arvutirevolutsiooni, kuigi Apple'i arvutitel oli VisiCalc, mis tegi personaalarvuti edukaks. Ausalt öeldes, kui 1-2-3 poleks ilmunud, poleks arvutid vaevalt lendu tõusnud ja personaalarvutite ajalugu oleks võinud areneda väga erinevalt. Lotus 1-2-3 käsitles 1900. aastat valesti liigaastana. Kui Microsoft avaldas oma esimese arvutustabeli Multiplan, hõivas see väikese turuosa. Ja kui nad käivitasid Exceli projekti, otsustasid nad mitte ainult kopeerida Lotus 1-2-3 ridade ja veergude nimetamise skeemi, vaid ka tagada vigade ühilduvuse, käsitledes 1900. aastat teadlikult liigaastana. See probleem on endiselt olemas. See tähendab, et 1-2-3 puhul oli see viga, kuid Excelis oli see teadlik otsus, mis tagas, et kõik 1-2-3 kasutajad said oma tabeleid Excelisse importida ilma andmeid muutmata, isegi kui need olid valed.
Kuid oli veel üks probleem. Esiteks andis Microsoft välja Exceli Macintoshi jaoks, mis ei tuvastanud kuupäevi enne 1. jaanuari 1904. Ja Excelis peeti ajastu alguseks 1. jaanuari 1900. Seetõttu tegid arendajad muudatuse nii, et nende programm tundis ära ajastu tüübi ja salvestas andmed enda sees vastavalt soovitud ajastule. Microsoft kirjutas selle kohta isegi selgitava artikli. Ja see otsus viis minu veani.
Minu ETL-süsteem sai klientidelt Exceli tabeleid, mis loodi Windowsis, kuid mida sai luua ka Macis. Seetõttu võiks ajastu alguseks tabelis olla kas 1. jaanuar 1900 või 1. jaanuar 1904. Kuidas teada saada? Exceli failivorming näitab vajalikku teavet, kuid parser, mida ma kasutasin, seda ei näidanud (nüüd näitab) ja eeldas, et teate konkreetse tabeli ajastut. Tõenäoliselt oleksin võinud rohkem aega kulutada Exceli binaarvormingu mõistmisele ja parseri autorile plaastri saatmisele, kuid mul oli kliendi jaoks palju rohkem teha, nii et kirjutasin kiiresti ajastu määramiseks heuristika. Ta oli lihtne.
Excelis saab kuupäeva 5. juuli 1998 esitada vormingus "07-05-98" (kasutu Ameerika süsteem), "5. juuli 98", "5. juuli 1998", "5-juuli-98" või mõni muu vorming. veel üks kasutu formaat (iroonilisel kombel oli üks vormingutest, mida minu Exceli versioon ei pakkunud, ISO 8601). Kuid tabelis salvestati vormindamata kuupäev epohhi-35981 jaoks kas "1900" või epohhi-34519 jaoks "1904" (numbrid näitavad päevade arvu ajastust alates). Kasutasin vormindatud kuupäevast aasta eraldamiseks lihtsat parserit ja seejärel vormindamata kuupäevast aasta eraldamiseks Exceli parserit. Kui mõlemad väärtused erinesid 4 aasta võrra, siis teadsin, et kasutan süsteemi epoch-1904-ga.
Miks ma lihtsalt ei kasutanud vormindatud kuupäevi? Sest 5. juuli 1998 saab vormindada kui "juuli 98", kui kuu päev on kadunud. Saime tabeleid nii paljudelt ettevõtetelt, kes neid nii mitmel erineval moel koostasid, et kuupäevade väljamõtlemine oli meie (antud juhul minu) ülesanne. Pealegi, kui Excel saab asja korda, peaksime seda tegema ka meie!
Samal ajal puutusin kokku numbriga 39082. Tuletan meelde, et Lotus 1-2-3 pidas 1900. aastat liigaastaks ja seda korrati truult ka Excelis. Ja kuna see lisas aastale 1900 ühe päeva, võivad paljud kuupäeva arvutamise funktsioonid just selle päeva kohta valed olla. See tähendab, et 39082 võis olla 1. jaanuar 2011 (Maci puhul) või 31. detsember 2006 (Windowsis). Kui minu “aastaparser” eraldas vormindatud väärtusest aasta 2011, siis on kõik korras. Kuid kuna Exceli parser ei tea, mis ajastut kasutatakse, on selle vaikimisi epoch-1900, tagastades aasta 2006. Minu rakendus nägi, et erinevus oli 5 aastat, pidas seda veaks, logis selle ja tagastas vormindamata väärtuse.
Sellest mööda saamiseks kirjutasin selle (pseudokood):
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
Ja siis sõeluti kõik 40 000 kuupäeva õigesti.
Keset suuri prinditöid
1980. aastate alguses töötas mu isa Storage Technology's, mis on nüüdseks tegevuse lõpetanud osakond, mis lõi lindiseadmeid ja pneumaatilisi süsteeme kiireks lindi söötmiseks.
Nad kujundasid draivid ümber nii, et üks keskne A-draiv oleks ühendatud seitsme B-draiviga ja A-draivi kontrolliv RAM-i väike OS võiks delegeerida lugemis- ja kirjutamistoimingud kõigile B-draividele.
Iga kord, kui draiv "A" käivitati, oli vaja "A"-ga ühendatud välisseadmesse sisestada diskett, et laadida operatsioonisüsteem selle mällu. See oli äärmiselt primitiivne: arvutusvõimsust andis 8-bitine mikrokontroller.
Selliste seadmete sihtrühmaks olid väga suurte andmeladudega ettevõtted – pangad, jaeketid jne –, kellel oli vaja trükkida palju aadressisilte või pangaväljavõtteid.
Ühel kliendil oli probleem. Keset prinditööd võib üks konkreetne draiv "A" lakata töötamast, põhjustades kogu töö seiskumise. Draivi töö taastamiseks pidid töötajad kõik taaskäivitama. Ja kui see juhtus keset kuuetunnist ülesannet, läks tohutult palju kallist arvutiaega kaduma ja kogu operatsiooni ajakava rikuti.
Tehnikud saadeti ettevõttest Storage Technologies. Kuid vaatamata oma parimatele pingutustele ei suutnud nad katsetingimustes viga taasesitada: see näis ilmnevat suurte prinditööde keskel. Probleem ei olnud riistvaras, nad asendasid kõik, mis võimalik: RAM, mikrokontroller, disketiseade, kõik lindiseadme mõeldavad osad – probleem püsis.
Seejärel helistasid tehnikud peakorterisse ja kutsusid Eksperdi.
Ekspert haaras tooli ja kohvitassi, istus arvutiruumi – tol ajal olid seal arvutitele pühendatud ruumid – ja vaatas, kuidas töötajad suure trükitöö järjekorda seadsid. Ekspert ootas ebaõnnestumist – ja see juhtus. Kõik vaatasid Eksperti, kuid tal polnud aimugi, miks see juhtus. Nii käskis ta töö uuesti järjekorda panna ning kõik töötajad ja tehnikud naasid tööle.
Ekspert istus uuesti toolile ja hakkas ootama ebaõnnestumist. Möödus umbes kuus tundi ja rike tekkis. Eksperdil polnud jällegi ideid, välja arvatud see, et kõik juhtus inimestega täidetud ruumis. Ta käskis missiooni uuesti käivitada, istus maha ja ootas.
Kolmanda ebaõnnestumise järel märkas Ekspert midagi. Rike tekkis siis, kui töötajad vahetasid võõras draivi linte. Veelgi enam, rike ilmnes kohe, kui üks töötajatest astus läbi teatud põrandaplaadi.
Tõstetud põrand oli valmistatud 6–8 tolli kõrgusele laotud alumiiniumplaatidest. Tõstetud põranda alla jooksid arvukad arvutite juhtmed, et keegi kogemata tähtsa kaabli peale ei astuks. Plaadid asetati väga tihedalt, et praht kõrgendatud põranda alla ei satuks.
Ekspert sai aru, et üks plaatidest on deformeerunud. Kui töötaja selle nurga peale astus, hõõrusid plaadi servad vastu kõrvalolevaid plaate. Nendega hõõrusid ka plaate ühendanud plastosad, mis tekitasid staatilisi mikrolahendusi, mis tekitasid raadiosageduslikke häireid.
Tänapäeval on RAM palju paremini kaitstud raadiosageduslike häirete eest. Kuid neil aastatel see nii ei olnud. Ekspert sai aru, et see häire häiris mälu ja koos sellega ka operatsioonisüsteemi tööd. Ta helistas tugiteenindusse, tellis uued plaadid, paigaldas need ise ja probleem kadus.
On tõusulaine!
Lugu toimus serveriruumis, Portsmouthi kontori neljandal või viiendal korrusel (ma arvan, et dokkide piirkonnas).
Ühel päeval jooksis Unixi server koos põhiandmebaasiga kokku. Nad taaskäivitasid ta, kuid ta kukkus rõõmsalt ikka ja jälle. Otsustasime helistada kellelegi tugiteenistusest.
Tugimees... Ma arvan, et ta nimi oli Mark, aga see ei loe... Ma arvan, et ma ei tunne teda. Vahet pole, tegelikult. Jääme Marki juurde, eks? Suurepärane.
Nii et mõni tund hiljem saabus Mark (teate küll, Leedsist Portsmouthi pole kaugel), lülitas serveri sisse ja kõik töötas probleemideta. Tüüpiline neetud tugi, klient läheb selle peale väga pahaseks. Mark vaatab logifailid läbi ja ei leia midagi ebameeldivat. Nii et Mark läheb tagasi rongile (või mis iganes transpordiliigiga ta saabus, minu teada võis see olla lonkav lehm... igatahes, see pole oluline, okei?) ja suundub raisata tagasi Leedsi päev.
Samal õhtul jookseb server uuesti kokku. Lugu on sama... server ei tõuse. Mark püüab eemalt aidata, kuid klient ei saa serverit käivitada.
Veel üks rong, buss, sidruni-besee või mõni muu jama ja Mark on tagasi Portsmouthis. Vaata, server käivitub ilma probleemideta! Ime. Mark kontrollib mitu tundi, kas operatsioonisüsteemi või tarkvaraga on kõik korras, ja asub teele Leedsi.
Umbes keset päeva jookseb server kokku (võtke rahulikult!). Seekord tundub mõistlik riistvaratoe inimesed serveri väljavahetamiseks kohale tuua. Aga ei, ca 10 tunni pärast kukub ka.
Olukord kordus mitu päeva. Server töötab, jookseb kokku umbes 10 tunni pärast ja ei käivitu järgmise 2 tunni jooksul. Nad kontrollisid jahutust, mälulekkeid, nad kontrollisid kõike, kuid ei leidnud midagi. Siis avariid peatusid.
Nädal möödus muretult...kõik olid rõõmsad. Õnnelik, kuni kõik algab uuesti. Pilt on sama. 10 tundi tööd, 2-3 tundi seisakuid...
Ja siis keegi (ma arvan, et nad ütlesid mulle, et sellel inimesel pole IT-ga midagi pistmist) ütles:
"See on mõõn!"
Hüüatus võeti vastu tühjade pilkudega ja ilmselt kõhkles kellegi käsi turvakutsungi nupul.
"See ei tööta koos tõusuga."
IT-tugitöötajatele tunduks see olevat täiesti võõras mõiste, kes tõenäoliselt ei loe kohvi jooma istudes Tide aastaraamatut. Nad selgitasid, et see ei saa olla mõõnaga kuidagi seotud, sest server oli nädal aega tõrgeteta töötanud.
"Eelmisel nädalal oli mõõn madal, kuid sel nädalal kõrge."
Natuke terminoloogiat neile, kel jahiluba pole. Looded sõltuvad Kuu tsüklist. Ja kui Maa pöörleb, tekitab Päikese ja Kuu gravitatsiooniline tõmbejõud iga 12,5 tunni järel tõusulaine. 12,5-tunnise tsükli alguses on mõõn, tsükli keskel mõõn ja lõpus jälle mõõn. Kuid Kuu orbiidi muutudes muutub mõõna ja mõõna erinevus. Kui Kuu on Päikese ja Maa vahel või Maa vastasküljel (täiskuu või mittekuud), saame Syzygyni looded – kõrgeimad tõusud ja madalaimad mõõnad. Poolkuu ajal saame kvadratuursed looded – kõige madalamad looded. Erinevus kahe äärmuse vahel väheneb oluliselt. Kuutsükkel kestab 28 päeva: syzygian - kvadratuur - syzygian - kvadratuur.
Kui tehnikutele mõõnajõudude olemust selgitati, mõtlesid nad kohe, et tuleb politsei kutsuda. Ja üsna loogiline. Aga tuli välja, et mehel oli õigus. Kaks nädalat varem sildus kontorist mitte kaugel hävitaja. Iga kord, kui mõõn selle teatud kõrgusele tõstis, sattus laeva radaripost serveriruumi põranda kõrgusele. Ja radar (või elektrooniline sõjavarustus või mõni muu sõjaline mänguasi) tekitas arvutites kaose.
Raketi lennuülesanne
Sain ülesandeks portida suur (umbes 400 tuhat rida) raketiheite juhtimis- ja jälgimissüsteem operatsioonisüsteemi, kompilaatori ja keele uutesse versioonidesse. Täpsemalt Solaris 2.5.1-st kuni Solaris 7-ni ja Verdix Ada arendussüsteemist (VADS), mis on kirjutatud Ada 83-s, kuni Rational Apex Ada-süsteemini, mis on kirjutatud Ada 95-s. VADS-i ostis Rational ja selle toode oli vananenud, kuigi Rational püüdis rakendada VADS-spetsiifiliste pakettide ühilduvaid versioone, et hõlbustada üleminekut Apexi kompilaatorile.
Kolm inimest aitasid mul koodi puhtaks kompileerida. Kulus kaks nädalat. Ja siis töötasin üksinda, et süsteem tööle panna. Lühidalt öeldes oli see halvim tarkvarasüsteemi arhitektuur ja teostus, millega ma kokku puutusin, nii et pordi valmimiseks kulus veel kaks kuud. Seejärel esitati süsteem testimisele, mis võttis aega veel mitu kuud. Testimise käigus leitud vead parandasin kohe ära, kuid nende arv vähenes kiiresti (lähtekoodiks oli tootmissüsteem, mistõttu selle funktsionaalsus töötas üsna töökindlalt, tuli lihtsalt uue kompilaatoriga kohanemisel tekkinud vead eemaldada). Lõpuks, kui kõik töötas nii, nagu peab, viidi mind üle teise projekti.
Ja reedel enne tänupüha helises telefon.
Raketi starti pidi katsetama umbes kolme nädala pärast ja pöördloenduse laboratoorsete katsete käigus blokeeriti käskude jada. Reaalses elus katkestaks see katse ja kui ummistus tekiks mõne sekundi jooksul pärast mootori käivitamist, tekiks abisüsteemides mitu pöördumatut tegevust, mis eeldaks raketi pikka – ja kulukat – valmisolekut. See poleks alanud, kuid paljud inimesed oleksid aja ja palju-palju raha kaotamise pärast väga ärritunud. Ärge laske kellelgi öelda, et kaitseministeerium kulutab raha hoolimatult – ma pole kunagi kohanud lepingulist juhti, kes poleks seadnud esikohale või teisele kohale eelarve ja sellele järgnenud ajakava.
Varasematel kuudel oli seda loendusväljakutset läbi viidud sadu kordi paljudes variatsioonides, ainult mõne väiksema luksumisega. Seega oli selle esinemise tõenäosus väga väike, kuid selle tagajärjed olid väga olulised. Korrutage need mõlemad tegurid ja saate aru, et uudised ennustasid mulle ja kümnetele inseneridele ja juhtidele rikutud puhkusenädalat.
Ja tähelepanu pöörati mulle kui süsteemi teisaldajale.
Nagu enamiku turvakriitiliste süsteemide puhul, logiti palju parameetreid, mistõttu oli üsna lihtne tuvastada mõned koodiridad, mis käivitati enne süsteemi kokkujooksmist. Ja loomulikult polnud neis absoluutselt midagi ebatavalist; samu väljendeid oli sama jooksu jooksul edukalt sooritatud sõna otseses mõttes tuhandeid kordi.
Kutsusime Apexi inimesed Rationalisse, sest nemad arendasid kompilaatorit ja mõned nende väljatöötatud rutiinid kutsuti kahtlases koodis. Neile (ja kõigile teistele) avaldas muljet, et oli vaja jõuda sõna otseses mõttes riikliku tähtsusega probleemi juurteni.
Kuna ajakirjades polnud midagi huvitavat, otsustasime proovida probleemi kohalikus laboris reprodutseerida. See ei olnud lihtne ülesanne, kuna sündmus leidis aset ligikaudu kord 1000 jooksmise kohta. Üks kahtlustatav põhjus oli see, et kõne müüja poolt välja töötatud mutex-funktsioonile (VADS-i migratsioonipaketi osa) Unlock avamiseni ei viinud. Funktsiooni kutsunud töötlemislõng töötles südamelöögiteateid, mis saabusid nominaalselt iga sekund. Tõstsime sageduse 10 Hz-ni ehk 10 korda sekundis ja hakkasime jooksma. Umbes tund hiljem lukustus süsteem ise. Logis nägime, et salvestatud sõnumite jada oli sama, mis ebaõnnestunud testi ajal. Tegime veel mitu sõitu, süsteem oli järjekindlalt blokeeritud 45-90 minutit peale starti ja iga kord sisaldas logi sama marsruuti. Kuigi me kasutasime tehniliselt erinevat koodi – sõnumite sagedus oli erinev –, oli süsteemi käitumine sama, seega olime kindlad, et see laadimisstsenaarium põhjustab sama probleemi.
Nüüd oli vaja välja selgitada, kus blokeering avaldiste jadas täpselt toimus.
See süsteemi rakendamine kasutas Ada ülesannete süsteemi ja kasutas seda uskumatult halvasti. Ülesanded on Adas kõrgetasemeline samaaegselt käivitatav konstruktsioon, mis on midagi täitmislõime, mis on ainult keelde sisse ehitatud. Kui kaks ülesannet peavad suhtlema, seavad nad kokku kohtumise, vahetavad vajalikke andmeid ja seejärel peatavad kohtumise ja naasevad iseseisvate täitmiste juurde. Süsteemi rakendati aga teisiti. Pärast sihtülesande kohtumist kohtus see sihtülesanne teise ülesandega, mis seejärel kohtus kolmanda ülesandega ja nii edasi, kuni töötlemine oli lõpetatud. Pärast seda olid kõik need kohtumised lõpetatud ja iga ülesanne pidi naasma oma täitmise juurde. See tähendab, et meil oli tegemist maailma kõige kallima funktsioonikõnede süsteemiga, mis peatas kogu "multitegumtöötluse" protsessi, samal ajal kui töötles osa sisendandmetest. Ja enne ei toonud see probleeme ainult seetõttu, et läbilaskevõime oli väga madal.
Kirjeldasin seda ülesannete mehhanismi, sest kui kohtumist taotleti või eeldati, et see peaks lõpule jõudma, võib juhtuda "ülesannete vahetamine". See tähendab, et protsessor võib hakata töötlema teist ülesannet, mis on täitmiseks valmis. Selgub, et kui üks ülesanne on valmis kohtuma teise ülesandega, võib hakata täitma hoopis teistsugust ülesannet ja lõpuks naaseb juhtimine esimesele kohtumisele. Samuti võivad ilmneda muud sündmused, mis põhjustavad ülesande ümberlülitumise; üks selline sündmus on süsteemifunktsiooni kutsumine, näiteks trükkimine või mutexi käivitamine.
Et mõista, milline koodirida probleemi põhjustas, pidin leidma viisi, kuidas salvestada edenemist lausete jada kaudu ilma tegumilülitit käivitamata, mis hoiaks ära krahhi. Nii et ma ei saanud seda ära kasutada Put_Line()et vältida I/O toimingute tegemist. Ma saaksin määrata loenduri muutuja või midagi sarnast, aga kuidas ma saan selle väärtust näha, kui ma ei saa seda ekraanil kuvada?
Samuti selgus logi uurides, et vaatamata südamelöögiteadete töötlemise takerdumisele, mis blokeeris kõik protsessi I/O toimingud ja takistas muude töötluste sooritamist, jätkati muude iseseisvate ülesannete täitmist. See tähendab, et tööd ei blokeeritud täielikult, vaid ainult (kriitiline) ülesannete ahel.
See oli blokeeriva väljendi hindamiseks vajalik vihje.
Tegin Ada paketi, mis sisaldas ülesannet, loendatavat tüüpi ja seda tüüpi globaalset muutujat. Loendatavad literaalid olid seotud probleemse jada spetsiifiliste väljenditega (nt. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked) ja seejärel sisestas sellesse määramisavaldised, mis määrasid globaalsele muutujale vastava loendi. Kuna selle kõige objektikood salvestas lihtsalt mällu konstandi, oli selle täitmise tulemusel ülesannete vahetamine äärmiselt ebatõenäoline. Eelkõige kahtlustasime väljendeid, mis võisid ülesande ümber lülitada, kuna blokeerimine toimus täitmisel, mitte ülesande tagasilülitamisel (mitmel põhjusel).
Jälgimisülesanne jooksis lihtsalt tsüklina ja kontrollis perioodiliselt, kas globaalse muutuja väärtus on muutunud. Iga muudatusega salvestati väärtus faili. Siis väike ootamine ja uus kontroll. Muutuja kirjutasin faili, kuna ülesanne käivitati alles siis, kui süsteem probleemipiirkonnas ülesande ümberlülitamisel selle täitmiseks valis. Ükskõik, mis selle ülesandega juhtus, ei mõjuta see teisi, mitteseotud blokeeritud ülesandeid.
Eeldati, et kui süsteem jõuab probleemse koodi täitmise punktini, lähtestatakse globaalne muutuja iga järgmise avaldise juurde liikumisel. Siis juhtub midagi, mis paneb ülesande ümber lülituma ja kuna selle täitmissagedus (10 Hz) on madalam kui seireülesandel, võiks monitor globaalse muutuja väärtuse kinni püüda ja selle kirjutada. Tavaolukorras võiksin saada loenduste alamhulga korduva jada: muutuja viimased väärtused ülesande vahetamise ajal. Rippumisel ei tohiks globaalne muutuja enam muutuda ja viimane kirjutatud väärtus näitab, milline avaldis ei lõpetatud.
Käivitasin koodi jälgimisega. Ta tardus. Ja jälgimine töötas nagu kellavärk.
Logi sisaldas oodatud jada, mille katkestas väärtus, mis viitas mutexi väljakutsumisele Unlock, ja ülesanne pole lõpetatud – nagu tuhandete varasemate kõnede puhul.
Apexi insenerid analüüsisid sel ajal palavikuliselt oma koodi ja leidsid mutexis koha, kus teoreetiliselt võib lukk tekkida. Kuid selle tõenäosus oli väga väike, kuna ainult teatud sündmuste jada teatud ajahetkel võis põhjustada blokeerimise. Murphy seadus, poisid, see on Murphy seadus.
Vajaliku koodilõigu kaitsmiseks asendasin mutex-funktsiooni kõned (ehitatud OS-i mutex-funktsioonile) väikese Ada mutex-paketiga, et juhtida sellele tükile Mutexi juurdepääsu.
Sisestasin selle koodi ja tegin testi. Seitse tundi hiljem töötas kood endiselt.
Minu kood esitati Rationalile, kus nad selle koostasid, võtsid lahti ja kontrollisid, et see ei kasutaks sama lähenemisviisi, mida kasutati probleemsetes mutex-funktsioonides.
See oli minu karjääri kõige rahvarohkem koodiülevaade 🙂 Minuga koos oli ruumis kümmekond inseneri ja juhti, veel kümme inimest olid konverentskõnes – ja nad kõik uurisid umbes 20 koodirida.
Kood vaadati üle, komplekteeriti uued käivitatavad failid ja esitati ametlikule regressioonitestile. Paar nädalat hiljem oli loenduskatse edukas ja rakett tõusis õhku.
Olgu, see kõik on hea, aga mis on selle loo mõte?
See oli täiesti vastik probleem. Sajad tuhanded koodiridad, paralleelne täitmine, üle tosina interakteeruvat protsessi, kehv arhitektuur ja kehv juurutamine, manustatud süsteemide liidesed ja miljonid kulutatud dollarid. Ei mingit survet, eks.
Ma ei olnud ainuke, kes selle probleemiga tegeles, kuigi olin teisaldamise ajal tähelepanu keskpunktis. Kuid kuigi ma seda tegin, ei tähenda see, et oleksin kõigist sadadest tuhandetest koodiridadest aru saanud või neid isegi lugenud. Koodi ja logisid analüüsisid insenerid üle riigi, kuid kui nad rääkisid mulle oma hüpoteesid rikke põhjuste kohta, kulus mul nende ümberlükkamiseks vaid pool minutit. Ja kui mul paluti teooriaid analüüsida, annaksin selle edasi kellelegi teisele, sest mulle oli näha, et need insenerid läksid valele teele. Kõlab jultunult? Jah, see on tõsi, kuid lükkasin hüpoteesid ja taotlused ümber teisel põhjusel.
Sain probleemi olemusest aru. Ma ei teadnud täpselt, kus see juhtus või miks, aga ma teadsin, mis juhtus.
Aastate jooksul on mul kogunenud palju teadmisi ja kogemusi. Olin üks Ada kasutamise pioneere ja mõistsin selle eeliseid ja puudusi. Tean, kuidas Ada käitusaegsed teegid ülesandeid käsitlevad ja paralleelkäivitamisega tegelevad. Ja ma saan aru madala taseme programmeerimisest mälu, registrite ja assembleri tasemel. Teisisõnu, mul on sügavad teadmised oma valdkonnas. Ja ma kasutasin neid probleemi põhjuse leidmiseks. Ma ei tegelenud lihtsalt veaga, vaid mõistsin, kuidas seda väga tundlikus käituskeskkonnas leida.
Sellised koodiga võitluse lood pole eriti huvitavad neile, kes pole sellise võitluse tunnuste ja tingimustega tuttavad. Kuid need lood aitavad meil mõista, mida on vaja tõeliselt keeruliste probleemide lahendamiseks.
Tõeliselt raskete probleemide lahendamiseks peate olema midagi enamat kui lihtsalt programmeerija. Peate mõistma koodi "saatust", seda, kuidas see oma keskkonnaga suhtleb ja kuidas keskkond ise töötab.
Ja siis on teil oma rikutud puhkusenädal.
Et jätkata.
Allikas: www.habr.com