Ĉi tio estas elekto de rakontoj el la Interreto pri kiel cimoj foje havas tute nekredeblajn manifestiĝojn. Eble ankaŭ vi havas ion por rakonti.
Aŭta alergio al vanila glaciaĵo
Rakonto por inĝenieroj, kiuj komprenas, ke la evidenta ne ĉiam estas la respondo, kaj ke kiom ajn malproksime la faktoj ŝajnas, ili ankoraŭ estas la faktoj. La Pontiac Dividado de General Motors Corporation ricevis plendon:
Jen la duan fojon, ke mi skribas al vi, kaj mi ne riproĉas vin, ke vi ne respondis, ĉar ĝi sonas freneze. Nia familio havas tradicion manĝi glaciaĵon ĉiunokte post la vespermanĝo. La specoj de glaciaĵo ŝanĝiĝas ĉiufoje, kaj post la vespermanĝo, la tuta familio elektas kiun glaciaĵon aĉeti, post kio mi iras al la vendejo. Mi ĵus aĉetis novan Pontiac kaj ekde tiam miaj vojaĝoj por akiri glaciaĵon fariĝis problemo. Vi vidas, ĉiufoje kiam mi aĉetas vanilan glaciaĵon kaj revenas de la vendejo, la aŭto ne startos. Se mi alportas alian glaciaĵon, la aŭto startas senprobleme. Mi volas fari seriozan demandon, kiom ajn stulte ĝi sonas: "Kio estas pri la Pontiac, kiu faras ĝin ne komenci kiam mi alportas vanilan glaciaĵon, sed komenciĝas facile kiam mi alportas alian guston de glaciaĵo?" "
Kiel vi povas imagi, la divizia prezidanto estis skeptika pri la letero. Tamen, ĉiaokaze, mi sendis inĝenieron por kontroli. Li estis surprizita ke li estis renkontita fare de riĉa, bone edukita viro vivanta en bela areo. Ili konsentis renkontiĝi tuj post la vespermanĝo, por ke ili du povu iri al la vendejo por glaciaĵo. Tiun vesperon estis vanilo, kaj kiam ili revenis al la aŭtomobilo, ĝi ne startis.
La inĝeniero venis ankoraŭ tri vesperojn. La unuan fojon la glaciaĵo estis ĉokolado. La aŭto startis. La duan fojon estis fraga glaciaĵo. La aŭto startis. La trian vesperon li petis preni vanilon. La aŭto ne startis.
Rezonante racie, la inĝeniero rifuzis kredi, ke la aŭto estas alergia kontraŭ vanila glaciaĵo. Tial mi konsentis kun la posedanto de la aŭto, ke li daŭrigos siajn vizitojn ĝis li trovos solvon al la problemo. Kaj survoje, li komencis preni notojn: li notis ĉiujn informojn, horon de la tago, specon de benzino, tempon de alveno kaj reveno de la vendejo, ktp.
La inĝeniero baldaŭ rimarkis, ke la posedanto de la aŭto pasigis malpli da tempo aĉetante vanilglaciaĵon. La kialo estis la aranĝo de la varoj en la vendejo. Vanila glaciaĵo estis la plej populara kaj estis konservita en aparta frostujo ĉe la fronto de la vendejo por faciligi ĝin trovi. Kaj ĉiuj aliaj varioj estis en la malantaŭo de la vendejo, kaj necesis multe pli da tempo por trovi la ĝustan varion kaj pagi.
Nun la demando estis por la inĝeniero: kial la aŭto ne startis, se pasis malpli da tempo ekde la momento, kiam la motoro estis malŝaltita? Ĉar la problemo estis tempo, ne vanila glaciaĵo, la inĝeniero rapide trovis la respondon: ĝi estis gaskluzo. Okazis ĉiuvespere, sed kiam la aŭtoposedanto pasigis pli da tempo serĉante glaciaĵon, la motoro sukcesis sufiĉe malvarmetiĝi kaj facile ekfunkciis. Kaj kiam la viro aĉetis vanilan glaciaĵon, la motoro ankoraŭ estis tro varma kaj la gasseruro ne havis tempon por dissolviĝi.
Moralo: Eĉ tute frenezaj problemoj foje estas realaj.
kraŝo Bandicoot
Estas dolorige sperti ĉi tion. Kiel programisto, vi kutimas kulpigi vian kodon unue, due, trie... kaj ie en la dekmila loko vi kulpigas la kompililon. Kaj pli malsupre en la listo vi jam kulpigas la ekipaĵon.
Jen mia rakonto pri la aparatara cimo.
Por la ludo Crash Bandicoot, mi skribis kodon por ŝargi kaj konservi al memorkarto. Por tia kontenta ludprogramisto, ĝi estis kiel promeno en la parko: mi pensis, ke la laboro daŭros plurajn tagojn. Tamen mi finis sencimigi la kodon dum ses semajnoj. Survoje mi solvis aliajn problemojn, sed ĉiujn kelkajn tagojn mi revenis al ĉi tiu kodo dum kelkaj horoj. Estis agonio.
La simptomo aspektis jene: kiam vi konservas la nunan ludadon de la ludo kaj aliras la memorkarton, ĉio preskaŭ ĉiam iras bone... Sed foje la legado aŭ skriba operacio malĉerpas sen evidenta kialo. Mallonga registrado ofte difektas la memorkarton. Kiam ludanto provas ŝpari, li ne nur malsukcesas ŝpari, sed ankaŭ detruas la mapon. Crap.
Post iom da tempo, nia produktanto ĉe Sony, Connie Bus, komencis panikiĝi. Ni ne povis sendi la ludon kun ĉi tiu cimo, kaj ses semajnojn poste mi ne komprenis, kio kaŭzas la problemon. Pere de Connie, ni kontaktis aliajn programistojn de PS1: ĉu iu renkontis ion similan? Ne. Neniu havis problemojn kun la memorkarto.
Kiam vi ne havas ideojn por sencimigi, la sola aliro restanta estas "dividi kaj konkeri": forigu pli kaj pli da kodo de la misa programo ĝis restas relative malgranda fragmento kiu ankoraŭ kaŭzas la problemon. Tio estas, vi detranĉas la programon pecon post peco ĝis la parto kiu enhavas la cimon restas.
Sed la afero estas, ke estas tre malfacile tranĉi pecojn el videoludo. Kiel ruli ĝin se vi forigis la kodon, kiu imitas graviton? Aŭ desegnante rolulojn?
Tial ni devas anstataŭigi tutajn modulojn per stumpoj, kiuj ŝajnigas fari ion utilan, sed fakte faras ion tre simplan, kiu ne povas enhavi erarojn. Ni devas skribi tiajn lambastonojn por ke la ludo almenaŭ funkciu. Ĉi tio estas malrapida kaj dolora procezo.
Resume, mi faris ĝin. Mi forigis pli kaj pli da pecoj de kodo ĝis mi restis kun la komenca kodo kiu agordas la sistemon por ruli la ludon, pravalorigas la bildigan aparataron, ktp. Kompreneble, en ĉi tiu etapo mi ne povis krei konservi kaj ŝargi menuon, ĉar mi devus krei stumblon por la tuta grafika kodo. Sed mi povus ŝajnigi esti uzanto uzante la (nevideblan) konservan kaj ŝargi ekranon kaj peti konservi kaj poste skribi al la memorkarto.
Ĉi tio lasis min kun malgranda peco de kodo kiu ankoraŭ havis la supran problemon - sed ĝi ankoraŭ okazis hazarde! Plej ofte ĉio funkciis bone, sed foje estis misfunkciadoj. Mi forigis preskaŭ la tutan ludkodon, sed la cimo ankoraŭ vivis. Ĉi tio estis konfuziga: la restanta kodo fakte nenion faris.
En iu momento, verŝajne ĉirkaŭ la tria matene, ekpensis al mi penso. Legado kaj skribado (enigo/eligo) operacioj implikas precizajn ekzekuttempojn. Kiam vi laboras kun malmola disko, memorkarto aŭ Bluetooth-modulo, la malaltnivela kodo respondeca por legado kaj skribo faras tion laŭ horloĝpulsoj.
Helpe de horloĝo, aparato kiu ne estas rekte konektita al la procesoro estas sinkronigita kun la kodo ekzekutanta sur la procesoro. La horloĝo determinas la baudrapidecon - la rapidecon je kiu datumoj estas transdonitaj. Se estas konfuzo kun tempoj, tiam aŭ la aparataro aŭ la programaro, aŭ ambaŭ, ankaŭ estas konfuzitaj. Kaj ĉi tio estas tre malbona, ĉar la datumoj povas esti damaĝitaj.
Kio se io en nia kodo konfuzas la tempojn? Mi kontrolis ĉion rilatan al ĉi tio en la testa programo-kodo kaj rimarkis, ke ni agordis la programeblan tempigilon en PS1 al 1 kHz (1000 tiktakoj por sekundo). Ĉi tio estas sufiĉe multe; defaŭlte, kiam la konzolo komenciĝas, ĝi funkcias je 100 Hz. Kaj plej multaj ludoj uzas ĉi tiun frekvencon.
Andy, la ludprogramisto, starigis la tempigilon al 1 kHz tiel ke movoj estus kalkulitaj pli precize. Andy emas superflugi, kaj se ni imitas graviton, ni faras ĝin kiel eble plej precize!
Sed kio se akceli la tempigilon iel influis la ĝeneralan tempigon de la programo, kaj tial la horloĝon kiu reguligas la baudrapidecon por la memorkarto?
Mi komentis la kodon de temporizilo. La eraro ne okazis denove. Sed ĉi tio ne signifas, ke ni riparis ĝin, ĉar la fiasko okazis hazarde. Kio se mi estus nur bonŝanca?
Kelkajn tagojn poste mi denove eksperimentis kun la testprogramo. La cimo ne ripetiĝis. Mi reiris al la plena ludkodbazo kaj modifis la konservadon kaj ŝarĝon kodon por ke la programebla tempigilo restarigiĝu al sia originala valoro (100Hz) antaŭ ol aliri la memorkarton, kaj poste restarigis al 1kHz. Ne plu estis kraŝoj.
Sed kial tio okazis?
Mi revenis al la testprogramo denove. Mi provis trovi iun ŝablonon en la okazo de eraro kun 1 kHz tempigilo. Fine mi rimarkis, ke la eraro okazas kiam iu ludas per PS1-regilo. Ĉar mi malofte farus tion mem - kial mi bezonus regilon kiam mi provas konservi kaj ŝargi kodon? - Mi eĉ ne rimarkis ĉi tiun dependecon. Sed iun tagon unu el niaj artistoj atendis, ke mi finos la testadon – mi verŝajne malbenis en tiu momento – kaj nervoze turnis la regilon en siaj manoj. Eraro okazis. "Atendu kio?!" Nu, faru ĝin denove!”
Kiam mi konstatis, ke ĉi tiuj du eventoj estas interkonektitaj, mi povis facile reprodukti la eraron: mi komencis registri al la memorkarto, movis la regilon kaj ruinigis la memorkarton. Al mi ĝi aspektis kiel aparatara cimo.
Mi venis al Connie kaj rakontis al ŝi pri mia malkovro. Ŝi elsendis la informojn al unu el la inĝenieroj kiuj dizajnis la PS1. "Neeble," li respondis, "Ĝi ne povas esti aparatara problemo." Mi petis Connie aranĝi konversacion por ni.
La inĝeniero vokis min kaj ni kverelis en lia rompita angla kaj mia (ege) rompita japana. Fine mi diris: "Lasu min nur sendi mian 30-linian testprogramon, kie movi la regilon kaŭzas cimon." Li konsentis. Li diris, ke ĝi estas tempoperdo kaj ke li estas terure okupata pri nova projekto, sed cedos ĉar ni estas tre grava programisto por Sony. Mi purigis mian testprogramon kaj sendis ĝin al li.
La sekvan vesperon (ni estis en Los-Anĝeleso kaj li estis en Tokio) li vokis min kaj ŝatine petis pardonon. Ĝi estis aparatara problemo.
Mi ne scias, kio precize estis la cimo, sed laŭ tio, kion mi aŭdis ĉe la ĉefsidejo de Sony, se vi agordis la tempigilon al sufiĉe alta valoro, ĝi malhelpis komponantojn sur la baztabulo en la najbareco de la tempigilo-kristalo. Unu el ili estis baŭdrapideco por la memorkarto, kiu ankaŭ starigis la baŭdrapidecon por la regiloj. Mi ne estas inĝeniero, do mi eble fuŝis ion.
Sed la fundo estas, ke estis interfero inter komponantoj sur la baztabulo. Kaj dum transdonado de datumoj samtempe tra la regilhaveno kaj la memorkarthaveno kun tempigilo funkcianta je 1 kHz, bitoj estis perditaj, datumoj estis perditaj, kaj la karto estis difektita.
Malbonaj bovinoj
En la 1980-aj jaroj, mia mentoro Sergei verkis programaron por la SM-1800, sovetia klono de la PDP-11. Tiu ĉi mikrokomputilo ĵus estis instalita ĉe fervoja stacidomo apud Sverdlovsk, grava transporta centro en Sovetunio. La nova sistemo estis dizajnita por direkti ĉarojn kaj vartrafikon. Sed ĝi enhavis ĝenan cimon, kiu kondukis al hazardaj kraŝoj kaj kraŝoj. Faloj ĉiam okazis kiam iu iris hejmen vespere. Sed malgraŭ ĝisfunda esploro la sekvan tagon, la komputilo funkciis ĝuste en ĉiuj manaj kaj aŭtomataj testoj. Ĉi tio kutime indikas raskondiĉon aŭ iun alian konkurencivan cimon kiu okazas sub certaj kondiĉoj. Laca de vokoj malfrue en la nokto, Sergei decidis atingi la fundon de ĝi, kaj unue kompreni, kiaj kondiĉoj ĉe la marshaling-korto kondukis al la komputila paneo.
Unue, li kolektis statistikojn de ĉiuj neklarigitaj faloj kaj kreis grafeon laŭ dato kaj tempo. La ŝablono estis evidenta. Post observado dum kelkaj pliaj tagoj, Sergei rimarkis, ke li povas facile antaŭdiri la tempon de estontaj sistemaj misfunkciadoj.
Li baldaŭ lernis ke interrompoj okazis nur kiam la stacio ordigis trajnoŝarĝojn de brutaro de norda Ukrainio kaj okcidenta Rusio direktiĝis al proksima buĉejo. Ĉi tio en si mem estis stranga, ĉar la buĉejon estis provizita de bienoj situantaj multe pli proksime, en Kazaĥio.
La nuklea centralo de Ĉernobilo eksplodis en 1986, kaj radioaktiva postlasaĵo igis la ĉirkaŭajn regionojn neloĝeblaj. Vastaj areoj en norda Ukrainio, Belorusio kaj okcidenta Rusio estis poluitaj. Suspektante altajn nivelojn de radiado en la alvenantaj vagonoj, Sergei evoluigis metodon por testi tiun teorion. La loĝantaro estis malpermesita havi dozimetrojn, do Sergei registris sin ĉe pluraj militistoj ĉe la stacidomo. Post pluraj trinkaĵoj da vodko, li sukcesis konvinki soldaton mezuri la radiadan nivelon en unu el la suspektindaj vagonoj. Montriĝis, ke la nivelo estis plurajn fojojn pli alta ol normalaj valoroj.
Ne nur la brutaro elsendis multe da radiado, sed ĝia nivelo estis tiel alta, ke ĝi kaŭzis hazardan perdon de bitoj en la memoro pri la SM-1800, kiu troviĝis en konstruaĵo apud la stacio.
En Sovetunio mankis manĝaĵoj, kaj la aŭtoritatoj decidis miksi ĉernobilan viandon kun viando el aliaj regionoj de la lando. Tio ebligis redukti la totalan nivelon de radioaktiveco sen perdi valorajn rimedojn. Sciinte pri tio, Sergej tuj plenigis dokumentojn por elmigrado. Kaj la komputilaj kraŝoj ĉesis memstare kiam la radiada nivelo malpliiĝis kun la tempo.
Tra la tuboj
Iam, Movietech Solutions kreis programaron por kinejoj, dizajnitajn por kontado, biletvendado kaj ĝenerala administrado. La DOS-versio de la frontmontra programo estis tre populara inter malgrandaj kaj mezgrandaj kinaj ĉenoj en Nordameriko. Do ne estas mirinde, ke kiam oni anoncis version de Windows 95, integrita kun la plej novaj tuŝekranoj kaj memservaj kioskoj, kaj ekipita per ĉiaj raportiloj, ĝi ankaŭ rapide populariĝis. Plej ofte la ĝisdatigo iris sen problemoj. La loka IT-kunlaborantaro instalis novan ekipaĵon, migris datumojn, kaj komerco daŭris. Krom kiam ĝi ne daŭris. Kiam tio okazis, la firmao sendos Jakobo'n, moknomitan "La Purigisto".
Kvankam la kromnomo sugestas malbonan tipon, la purigilo estas nur kombinaĵo de instrukciisto, instalilo kaj kompromiso. Jakobo pasigus kelkajn tagojn ĉe la kliento kunmetante ĉiujn komponantojn, kaj poste pasigis pliajn kelkajn tagojn instruante la personaron kiel uzi la novan sistemon, solvante ajnajn aparatajn problemojn kiuj aperis kaj esence helpante la programaron tra ĝia infanaĝo.
Tial, ne estas surprize, ke dum ĉi tiuj streĉaj tempoj, Jakobo alvenis al la oficejo matene, kaj antaŭ ol li povis atingi sian skribotablon, li estis salutita de la administranto, plenigita de kafeino pli ol kutime.
"Mi timas, ke vi devas iri al Annapolis, Nov-Skotio, kiel eble plej baldaŭ." Ilia tuta sistemo malfunkciis, kaj post nokto da laborado kun iliaj inĝenieroj, ni ne povas eltrovi kio okazis. Ŝajnas, ke la reto malsukcesis sur la servilo. Sed nur post kiam la sistemo funkciis dum kelkaj minutoj.
— Ĉu ili ne revenis al la malnova sistemo? - respondis Jakobo tute serioze, kvankam mense li surprizite larĝigis la okulojn.
— Ĝuste: ilia IT-specialisto "ŝanĝis prioritatojn" kaj decidis foriri kun sia malnova servilo. James, ili instalis la sistemon ĉe ses ejoj kaj ĵus pagis por altkvalita subteno, kaj ilia komerco nun funkcias kiel ĝi estis en la 1950-aj jaroj.
Jakobo iomete rektiĝis.
- Tio estas alia afero. Bone, ni komencu.
Kiam li alvenis en Annapolis, la unua aĵo kiun li faris estis trovi la unuan teatron de la kliento kiu havis problemon. Sur la mapo prenita en la flughaveno, ĉio aspektis deca, sed la areo ĉirkaŭ la dezirata adreso aspektis suspektinda. Ne geto, sed rememoriga pri filmo noir. Dum Jakobo parkumis ĉe la trotujo urbocentre, prostituitino alproksimiĝis al li. Konsiderante la grandecon de Annapolis, ĝi estis plej verŝajne la nura en la tuta grandurbo. Ŝia aspekto tuj memorigis la faman karakteron, kiu proponis sekson por mono sur la granda ekrano. Ne, ne pri Julia Roberts, sed pri Jon Voight [aludo al la filmo "Noktomeza Vakero" - ĉ. lane].
Sendinte la prostituitinon sur sian vojon, Jakobo iris al la kinejo. La ĉirkaŭaĵo pliboniĝis, sed ĝi ankoraŭ donis la impreson, ke ĝi estas mallevita. Ne ke Jakobo estis tro maltrankvila. Li jam estis en mizeraj lokoj. Kaj ĉi tio estis Kanado, kie eĉ ŝtelistoj estas sufiĉe ĝentilaj por diri "dankon" post preni vian monujon.
La flanka enirejo al la kinejo estis en malseka strateto. Jakobo iris al la pordo kaj frapis. Baldaŭ ĝi knaris kaj iomete malfermiĝis.
-Ĉu vi estas purigisto? — el interne aŭdiĝis raŭka voĉo.
- Jes, estas mi... mi venis por ripari ĉion.
James eniris la kinejon. Ŝajne ne havante alian elekton, personaro komencis disdoni paperajn biletojn al vizitantoj. Ĉi tio malfaciligis financan raportadon, des pli interesajn detalojn. Sed la personaro salutis Jakobon kun trankvilo kaj tuj kondukis lin al la servila ĉambro.
Unuavide, ĉio estis en ordo. James ensalutis en la servilon kaj kontrolis la kutimajn suspektindajn lokojn. Nedankinde. Tamen, pro abundo da singardemo, Jakobo malŝaltis la servilon, anstataŭigis la retkarton, kaj malfunkciigis la sistemon. Ŝi tuj eklaboris plene. La kunlaborantaro komencis vendi biletojn denove.
Jakobo telefonis al Mark kaj informis lin pri la situacio. Ne estas malfacile imagi, ke Jakobo eble volas resti kaj vidi ĉu okazas io neatendita. Li malsupreniris la ŝtuparon kaj komencis demandi al la dungitoj kio okazis. Evidente la sistemo ĉesis funkcii. Ili malŝaltis kaj ŝaltis, ĉio funkciis. Sed post 10 minutoj la sistemo defalis.
Ĝuste ĉi-momente io simila okazis. Subite, la biletsistemo komencis ĵeti erarojn. La personaro suspiris kaj kaptis la paperajn biletojn, kaj Jakobo rapidis al la servila ĉambro. Ĉio aspektis bone kun la servilo.
Tiam unu el la dungitoj eniris.
— La sistemo denove funkcias.
Jakobo estis konfuzita ĉar li faris nenion. Pli precize, nenio, kio igus la sistemon funkcii. Li elsalutis, prenis sian telefonon kaj telefonis al la subtenlinio de sia firmao. Baldaŭ la sama dungito eniris la servilĉambron.
- La sistemo malfunkcias.
James ekrigardis la servilon. Interesa kaj konata ŝablono de multkoloraj formoj dancis sur la ekrano - kaose tordiĝantaj kaj interplektiĝantaj pipoj. Ni ĉiuj vidis ĉi tiun ekranŝirmilon iam. Ĝi estis bele igita kaj laŭvorte hipnotiga.
Jakobo premis butonon kaj la ŝablono malaperis. Li rapidis al la biletvendejo kaj survoje renkontis dungiton revenantan al li.
— La sistemo denove funkcias.
Se vi povas fari mensan vizaĝpalmon, ĝuste tion Jakobo faris. Ekrankurteno. Ĝi uzas OpenGL. Kaj tial, dum operacio, ĝi konsumas ĉiujn rimedojn de la servila procesoro. Kiel rezulto, ĉiu alvoko al la servilo finiĝas per tempo-tempo.
James revenis al la servila ĉambro, ensalutinta, kaj anstataŭigis la ekranŝirmilon per la belaj tuboj kun malplena ekrano. Tio estas, anstataŭ ekranŝirmilo, kiu konsumas 100% de procesoraj rimedoj, mi instalis alian, kiu ne konsumas rimedojn. Poste mi atendis 10 minutojn por kontroli mian divenon.
Kiam Jakobo alvenis al la sekva kinejo, li scivolis kiel klarigi al sia administranto, ke li ĵus flugis 800 km por malŝalti la ekranŝparilon.
Kraŝo dum certa fazo de la luno
Vera rakonto. Iun tagon aperis programara cimo, kiu dependis de la fazo de la luno. Estis eta rutino, kiu estis kutime uzata en diversaj MIT-programoj por kalkuli la proksimumon al la vera fazo de la Luno. GLS enkonstruis ĉi tiun rutinon en LISP-programon kiu, skribante dosieron, eligus linion kun tempomarko preskaŭ 80 signojn longa. Estis tre malofte, ke la unua linio de mesaĝo finiĝus tro longa kaj kondukus al la sekva linio. Kaj kiam la programo poste legis ĉi tiun dosieron, ĝi malbenis. La longo de la unua linio dependis de la preciza dato kaj tempo, same kiel la longo de la fazspecifo tiutempe kiam la tempomarko estis presita. Tio estas, la cimo laŭvorte dependis de la fazo de la luno!
Unua papera eldono (Steele-1983) enhavis ekzemplon de tia linio kiu kondukis al la priskribita cimo, sed la kompostisto "fiksis" ĝin. Tio poste estis priskribita kiel "lunfaza cimo".
Tamen, atentu kun supozoj. Antaŭ kelkaj jaroj, inĝenieroj de CERN (Eŭropa Centro por Nuklea Esploro) renkontis erarojn en eksperimentoj faritaj ĉe la Granda Elektrona-Positrona Koliziilo. Ĉar komputiloj aktive prilaboras la grandegan kvanton da datumoj generitaj de ĉi tiu aparato antaŭ ol montri la rezulton al sciencistoj, multaj konjektis, ke la programaro estas iel sentema al la fazo de la luno. Pluraj malesperaj inĝenieroj atingis la fundon de la vero. La eraro estiĝis pro eta ŝanĝo en la geometrio de la 27 km longa ringo pro la deformado de la Tero dum la trairo de la Luno! Ĉi tiu rakonto eniris fizikan folkloron kiel "La Venĝo de Newton pri Partikla Fiziko" kaj ekzemplo de la ligo inter la plej simplaj kaj plej malnovaj leĝoj de fiziko kaj la plej progresintaj sciencaj konceptoj.
Fluvado de la necesejo haltigas la trajnon
La plej bona aparatara cimo pri kiu mi iam aŭdis estis sur altrapida trajno en Francio. La cimo kondukis al urĝa bremsado de la trajno, sed nur se estis pasaĝeroj surŝipe. En ĉiu tia kazo, la trajno estis forigita, kontrolita, sed nenio estis trovita. Poste li estis resendita al la linio, kaj li tuj haltis.
Dum unu el la kontroloj, inĝeniero vojaĝanta en la trajno iris al la necesejo. Li baldaŭ forlavis, BUM! Urĝa halto.
La inĝeniero kontaktis la ŝoforon kaj demandis:
— Kion vi faris ĝuste antaŭ bremsado?
- Nu, mi malrapidiĝis dum la malsupreniro...
Tio estis stranga, ĉar dum normala funkciado la trajno malrapidiĝas je malsupreniroj dekoj da fojoj. La trajno pluiris, kaj dum la sekva malsupreniro la ŝoforo avertis:
- Mi tuj malrapidiĝos.
Nenio okazis.
— Kion vi faris dum la lasta bremsado? - demandis la ŝoforo.
- Nu... mi estis en la necesejo...
- Nu, do iru al la necesejo kaj faru tion, kion vi faris, kiam ni denove malsupreniros!
La inĝeniero iris al la necesejo, kaj kiam la ŝoforo avertis: "Mi malrapidiĝas," li fluflugis la akvon. Kompreneble la trajno tuj haltis.
Nun ili povis reprodukti la problemon kaj bezonis trovi la kaŭzon.
Post du minutoj, ili rimarkis, ke la motorbremsa teleregilkablo (la trajno havis po unu motoro ĉe ĉiu fino) estis malkonektita de la muro de la elektra kabineto kaj kuŝas sur la relajso, kiu regis la necesejan ŝtopilon... Kiam la relajso estis ŝaltita, ĝi kreis enmiksiĝon en la bremskablo, kaj la sistema protekto kontraŭ fiaskoj simple inkludis krizbremsadon.
La enirejo kiu malamis FORTRAN
Antaŭ kelkaj monatoj ni rimarkis, ke la retaj konektoj sur la ĉeftero [ĉi tio estis en Havajo] tre, tre malrapidiĝas. Ĉi tio povus daŭri 10-15 minutojn kaj tiam subite denove okazi. Post iom da tempo, mia kolego plendis al mi, ke la retaj konektoj sur la ĉeftero ĝenerale ne funkcias. Li havis iun FORTRAN-kodon kiu devis esti kopiita al maŝino sur la ĉeftero, sed ĝi ne povis ĉar "la reto ne daŭris sufiĉe longe por la FTP-alŝuto por kompletigi."
Jes, montriĝis, ke retaj fiaskoj okazis kiam kolego provis FTP dosieron kun fontkodo en FORTRAN al maŝino sur la ĉeftero. Ni provis arkivi la dosieron: tiam ĝi estis kopiita glate (sed la celmaŝino ne havis malpakilon, do la problemo ne estis solvita). Fine ni "dividas" la FORTRAN-kodon en tre malgrandajn pecojn kaj sendis ilin unuope. La plej multaj el la fragmentoj estis kopiitaj sen problemoj, sed kelkaj pecoj ne pasis, aŭ pasis poste multnombraj provoj.
Kiam ni ekzamenis la problemajn trairejojn, ni malkovris, ke ili havas ion komunan: ili ĉiuj enhavis komentblokojn, kiuj komenciĝis kaj finiĝis per linioj konsistantaj el majusklo C (kiel kolego preferis komenti en FORTRAN). Ni retpoŝtigis retajn spertulojn sur la ĉeftero kaj petis helpon. Kompreneble, ili volis vidi specimenojn de niaj dosieroj, kiujn oni ne povis transdoni per FTP... sed niaj leteroj ne atingis ilin. Fine ni elpensis simplan priskribikiel aspektas netransdoneblaj dosieroj. Ĝi funkciis :) [Ĉu mi aŭdacas aldoni ekzemplon de unu el la problemaj FORTRAN-komentoj ĉi tie? Verŝajne ne valoras ĝin!]
Fine ni sukcesis eltrovi ĝin. Nova enirejo estis ĵus instalita inter nia parto de kampuso kaj la kontinenta reto. Ĝi havis GERAN malfacilon transdoni pakaĵetojn, kiuj enhavis ripetajn pecojn da majuskla C! Nur kelkaj el ĉi tiuj pakoj povus preni ĉiujn enirejojn kaj malhelpi la plej multajn aliajn pakojn trairi. Ni plendis al la fabrikanto de la enirejo... kaj ili respondis: “Ho jes, vi estas antaŭ cimo de ripeta C! Ni jam scias pri li.” Ni finfine solvis la problemon aĉetante novan enirejon de alia fabrikanto (en la defendo de la unua, la malkapablo translokigi FORTRAN-programojn povas esti avantaĝo por iuj!).
Malfacilaj tempoj
Antaŭ kelkaj jaroj, laborante pri kreado de ETL-sistemo en Perl por redukti la kostojn de fazo 40 klinikaj provoj, mi bezonis prilabori ĉirkaŭ 000 datojn. Du el ili ne trapasis la teston. Ĉi tio ne tro ĝenis min ĉar ĉi tiuj datoj estis prenitaj el kliento-provizitaj datumoj kiuj ofte estis, ni diru, surprizaj. Sed kiam mi kontrolis la originalajn datumojn, montriĝis, ke ĉi tiuj datoj estas la 1-a de januaro 2011 kaj la 1-a de januaro 2007. Mi pensis, ke la cimo estas enhavita en la programo, kiun mi ĵus skribis, sed montriĝis, ke ĝi jam estas 30 jaroj. maljuna. Ĉi tio povas soni mistera por tiuj, kiuj ne konas la programaran ekosistemon. Pro la longdaŭra decido de alia kompanio gajni monon, mia kliento pagis min por ripari cimon, kiun unu kompanio hazarde enkondukis kaj la alia intence. Por ke vi komprenu, pri kio mi parolas, mi devas paroli pri la kompanio, kiu aldonis la funkcion, kiu fariĝis cimo, kaj ankaŭ pri kelkaj aliaj interesaj eventoj, kiuj kontribuis al la mistera cimo, kiun mi riparis.
En la bonaj tempoj, Apple-komputiloj foje spontanee restarigis sian daton al januaro 1, 1904. La kialo estis simpla: ĝi uzis baterian "sisteman horloĝon" por konservi trakon de la dato kaj horo. Kio okazis kiam la baterio mortis? Komputiloj komencis spuri la daton laŭ la nombro da sekundoj ekde la komenco de epoko. Laŭ epoko ni celis la referencan originan daton, kaj por Makintoŝoj ĝi estis la 1-a de januaro 1904. Kaj post kiam la baterio mortis, la nuna dato estis rekomencigita al la specifita. Sed kial tio okazis?
Antaŭe, Apple uzis 32 bitojn por konservi la nombron da sekundoj ekde la origina dato. Unu bito povas stoki unu el du valoroj - 1 aŭ 0. Du bitoj povas stoki unu el kvar valoroj: 00, 01, 10, 11. Tri bitoj - unu valoro el ok: 000, 001, 010, 011, 100 , 101, 110, 111, ktp. Kaj 32 povus stoki unu el 232 valoroj, tio estas, 4 sekundoj. Por Apple-datoj, tio egalis al ĉirkaŭ 294 jaroj, do pli malnovaj Macs ne povas trakti datojn post 967. Kaj se la sistema baterio mortas, la dato estas rekomencigita al 296 sekundoj ekde la komenco de la epoko, kaj vi devas permane agordi la daton ĉiufoje kiam vi ŝaltas la komputilon (aŭ ĝis vi aĉetas novan kuirilaron).
Tamen, la decido de Apple konservi datojn kiel sekundojn ekde la epoko signifis, ke ni ne povis trakti datojn antaŭ la epoko, kio havis vastajn sekvojn, kiel ni vidos. Apple enkondukis funkcion, ne cimon. Interalie, tio signifis ke la Macintosh operaciumo estis imuna kontraŭ la "jarmila cimo" (kiu ne povus esti dirita pri multaj Mac-aplikoj kiuj havis siajn proprajn datsistemojn por eviti restriktojn).
Antaŭeniri. Ni uzis Lotus 1-2-3, la "mortiga aplikaĵo" de IBM, kiu helpis lanĉi la PC-revolucion, kvankam Apple-komputiloj havis VisiCalc, kiu sukcesigis la personan komputilon. Verdire, se 1-2-3 ne aperus, komputiloj apenaŭ ekflugus, kaj la historio de personaj komputiloj povus esti evoluinta tre malsame. Lotuso 1-2-3 neĝuste traktis 1900 kiel superjaron. Kiam Mikrosofto publikigis sian unuan kalkultabelon, Multiplan, ĝi kaptis malgrandan parton de la merkato. Kaj kiam ili lanĉis la Excel-projekton, ili decidis ne nur kopii la skemon de nomado de vicoj kaj kolumnoj de Lotus 1-2-3, sed ankaŭ certigi cimkongruon per intence traktante 1900 kiel superjaron. Ĉi tiu problemo ankoraŭ ekzistas hodiaŭ. Tio estas, en 1-2-3 ĉi tio estis cimo, sed en Excel ĝi estis konscia decido, kiu certigis, ke ĉiuj 1-2-3-uzantoj povus importi siajn tabelojn en Excel sen ŝanĝi la datumojn, eĉ se ĝi estis malĝusta.
Sed estis alia problemo. Unue, Microsoft publikigis Excel por Macintosh, kiu ne rekonis datojn antaŭ la 1-a de januaro 1904. Kaj en Excel, la 1-a de januaro 1900 estis konsiderita la komenco de la epoko. Tial la programistoj faris ŝanĝon por ke ilia programo rekonis la tipon de epoko kaj stokis datumojn en si mem laŭ la dezirata epoko. Mikrosofto eĉ skribis klariga artikolo pri tio. Kaj ĉi tiu decido kondukis al mia cimo.
Mia ETL-sistemo ricevis Excel-kalkultabelojn de klientoj, kiuj estis kreitaj en Vindozo, sed ankaŭ povus esti kreitaj en Mac. Tial, la komenco de la epoko en la tabelo povus esti aŭ januaro 1, 1900, aŭ januaro 1, 1904. Kiel ekscii? La Excel-dosierformato montras la necesajn informojn, sed la analizilo, kiun mi uzis, ne montris ĝin (nun jes), kaj supozis, ke vi konas la epokon por specifa tabelo. Mi verŝajne povus pasigi pli da tempo por kompreni la binaran formaton de Excel kaj sendi flikaĵon al la analizisto-aŭtoro, sed mi havis multe pli por fari por la kliento, do mi rapide skribis heŭristiko por determini la epokon. Ŝi estis simpla.
En Excel, la dato 5-a de julio 1998 povas esti reprezentita en la formato "07-05-98" (senutila usona sistemo), "5-a de julio 98", "5-a de julio 1998", "5-a de julio-98" aŭ iu alia formato.alia senutila formato (ironie, unu el la formatoj, kiujn mia versio de Excel ne proponis, estis ISO 8601). Tamen, ene de la tabelo, la neformata dato estis stokita kiel aŭ "35981" por epoko-1900 aŭ "34519" por epoko-1904 (la nombroj reprezentas la nombron da tagoj ekde la epoko). Mi simple uzis simplan analizilon por ĉerpi la jaron el la formatita dato, kaj poste uzis la Excel-annalizilon por ĉerpi la jaron el la neformata dato. Se ambaŭ valoroj malsamis je 4 jaroj, tiam mi sciis, ke mi uzas sistemon kun epoko-1904.
Kial mi ne simple uzis formatitajn datojn? Ĉar julio 5, 1998 povas esti formatita kiel "July, 98" kun la monatotago perdita. Ni ricevis tabelojn de tiom da kompanioj, kiuj kreis ilin en tiom da malsamaj manieroj, ke dependis de ni (ĉi-kaze, mi) eltrovi la datojn. Cetere, se Excel korektas, tiam ankaŭ ni devus!
Samtempe mi renkontis 39082. Mi memorigu, ke Lotus 1-2-3 konsideris 1900 superjaron, kaj tio estis fidele ripetita en Excel. Kaj ĉar ĉi tio aldonis unu tagon al la jaro 1900, multaj dataj kalkulfunkcioj povus esti malĝustaj por tiu sama tago. Tio estas, 39082 povus esti la 1-a de januaro 2011 (ĉe Macs) aŭ la 31-a de decembro 2006 (ĉe Vindozo). Se mia "jara analizisto" ĉerpis la jaron 2011 el la formatita valoro, tiam ĉio estas en ordo. Sed ĉar la Excel-analizilo ne scias, kian epokon oni uzas, ĝi defaŭlte al epoko-1900, revenante la jaron 2006. Mia aplikaĵo vidis, ke la diferenco estis 5 jaroj, konsideris ĝin eraro, ensalutis ĝin kaj resendis neformatan valoron.
Por ĉirkaŭiri ĉi tion, mi skribis ĉi tion (pseŭdokodo):
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
Kaj tiam ĉiuj 40 datoj estis ĝuste analizitaj.
En la mezo de grandaj preslaboroj
Komence de la 1980-aj jaroj, mia patro laboris ĉe Stokado-Teknologio, nun malfunkcia dividado, kiu kreis bendodiskojn kaj pneŭmatikajn sistemojn por altrapida benda nutrado.
Ili restrukturis la veturadojn tiel ke ili povis havi unu centran "A" stiradon ligitan al sep "B" stiradoj, kaj la malgranda OS en RAM kiu kontrolis la "A" stiradon povis delegi legado- kaj skribi operaciojn al ĉiuj "B" stiradoj.
Ĉiufoje kiam oni ekfunkciigis stiradon "A", necesis enmeti disketon en la ekstercentran diskon konektitan al "A" por ŝargi la operaciumon en ĝian memoron. Ĝi estis ekstreme primitiva: komputa potenco estis disponigita per 8-bita mikroregilo.
La celgrupo por tiaj ekipaĵoj estis kompanioj kun tre grandaj datumstokejoj - bankoj, podetalaj ĉenoj, ktp. - kiuj bezonis presi multajn adresetikedojn aŭ bankdeklarojn.
Unu kliento havis problemon. En la mezo de presado, unu aparta stirado "A" povus ĉesi funkcii, kaŭzante la tutan laboron halti. Por restarigi la funkciadon de la stirado, dungitaro devis rekomenci ĉion. Kaj se tio okazis meze de ses-hora tasko, tiam grandega kvanto da multekosta komputila tempo estis perdita kaj la horaro de la tuta operacio estis interrompita.
Teknikistoj estis senditaj de Storage Technologies. Sed malgraŭ iliaj plej bonaj klopodoj, ili ne povis reprodukti la cimon sub testkondiĉoj: ĝi ŝajnis okazi meze de grandaj presaj laboroj. La problemo ne estis la aparataro, ili anstataŭigis ĉion kion ili povis: RAM, mikroregilo, disketo, ĉiu imagebla parto de la bendodisko - la problemo daŭris.
Tiam la teknikistoj vokis la ĉefsidejon kaj vokis la Fakulon.
La fakulo kaptis seĝon kaj tason da kafo, sidis en la komputilejo — en tiuj tagoj estis ĉambroj dediĉitaj al komputiloj — kaj rigardis, kiel la personaro vicigas grandan preslaboron. La fakulo atendis, ke okazos malsukceso – kaj jes. Ĉiuj rigardis la Fakulon, sed li tute ne sciis kial tio okazis. Do li ordonis, ke la tasko estu ree vicigita, kaj ĉiuj dungitoj kaj teknikistoj reiris al la laboro.
La fakulo denove sidiĝis sur la seĝon kaj komencis atendi malsukceson. Proksimume ses horoj pasis kaj la fiasko okazis. La Fakulo denove ne havis ideojn, krom ke ĉio okazis en ĉambro plenplena de homoj. Li ordonis rekomenci la mision, sidiĝis kaj atendis.
Je la tria malsukceso, la Fakulo rimarkis ion. La fiasko okazis kiam personaro ŝanĝis glubendojn en fremda disko. Krome, la fiasko okazis tuj kiam unu el la dungitoj trairis certan kahelon sur la planko.
La levita planko estis farita el aluminiaj kaheloj metitaj ĉe alteco de 6 ĝis 8 coloj. Multnombraj dratoj de komputiloj kuris sub la levita planko por malhelpi iu ajn hazarde treti sur gravan kablon. La kaheloj estis metitaj tre malloze por malhelpi derompaĵojn eniri sub la levita planko.
La fakulo rimarkis, ke unu el la kaheloj estas misformita. Kiam oficisto paŝis sur ĝian angulon, la randoj de la kahelo frotis kontraŭ la apudaj kaheloj. Ankaŭ la plastaj partoj, kiuj kunligis la kahelojn, frotis kun ili, kio kaŭzis senmovajn mikrosenŝargiĝojn, kiuj kreis radiofrekvencan interferon.
Hodiaŭ, RAM estas multe pli bone protektita kontraŭ radiofrekvenca interfero. Sed en tiuj jaroj tio ne estis la kazo. La fakulo rimarkis, ke ĉi tiu interfero interrompis la memoron, kaj kun ĝi la funkciadon de la operaciumo. Li telefonis al la helpservo, mendis novajn kahelojn, instalis ilin mem, kaj la problemo malaperis.
Estas alta tajdo!
La rakonto okazis en servila ĉambro, sur la kvara aŭ kvina etaĝo de oficejo en Portsmouth (mi pensas), en la haveno areo.
Iun tagon la Unikso-servilo kun la ĉefa datumbazo kraŝis. Ili rekomencis lin, sed li feliĉe daŭre falis denove kaj denove. Ni decidis voki iun de la helpservo.
La subtenulo... Mi pensas, ke lia nomo estis Marko, sed tio ne gravas... Mi kredas, ke mi ne konas lin. Ne gravas, vere. Ni restu kun Marko, ĉu bone? Bonege.
Do, kelkajn horojn poste alvenis Marko (ne estas longa vojo de Leeds al Portsmouth, vi scias), ŝaltis la servilon kaj ĉio funkciis senprobleme. Tipa malbenita subteno, la kliento tre ĉagreniĝas pri ĝi. Marko trarigardas la protokolojn kaj trovas nenion malbonan. Do Marko reiras sur la trajnon (aŭ laŭ kia ajn transportmaniero li alvenis, ĝi povus esti lama bovino laŭ ĉio, kion mi scias... ĉiuokaze, ne gravas, ĉu bone?) kaj reiras al Leeds, malŝparinte. la tago.
Tiun saman vesperon la servilo denove kraŝas. La historio estas la sama... la servilo ne leviĝas. Mark provas helpi malproksime, sed la kliento ne povas lanĉi la servilon.
Alia trajno, buso, citronmeringo aŭ iu alia aĉaĵo, kaj Mark estas reen en Portsmouth. Rigardu, la servilo startas senprobleme! Miraklo. Mark pasigas plurajn horojn kontrolante, ke ĉio estas en ordo kun la operaciumo aŭ programaro kaj ekiras al Leeds.
Ĉirkaŭ la mezo de la tago la servilo kraŝas (trankvile!). Ĉi-foje ŝajnas racie alporti la aparataron-subtenajn homojn por anstataŭigi la servilon. Sed ne, post ĉirkaŭ 10 horoj ĝi ankaŭ falas.
La situacio ripetiĝis dum pluraj tagoj. La servilo funkcias, kraŝas post ĉirkaŭ 10 horoj kaj ne komenciĝas dum la sekvaj 2 horoj. Ili kontrolis malvarmigon, memorfluojn, ili kontrolis ĉion, sed trovis nenion. Tiam la kraŝoj ĉesis.
La semajno pasis senzorge... ĉiuj estis feliĉaj. Feliĉa ĝis ĉio komenciĝos denove. La bildo estas la sama. 10 horoj da laboro, 2-3 horoj da malfunkcio...
Kaj tiam iu (mi pensas, ke ili diris al mi, ke ĉi tiu persono havas nenion komunan kun IT) diris:
"Estas la tajdo!"
La ekkrio estis renkontita per malplenaj rigardoj, kaj ies mano verŝajne hezitis ĉe la sekureca vokobutono.
"Ĝi ĉesas funkcii kun la tajdo."
Ĉi tio ŝajnus esti tute fremda koncepto por IT-subtenaj laboristoj, kiuj verŝajne ne legos la Tajdan Jarlibron sidiĝante por kafo. Ili klarigis, ke tio neniel povus rilati al la tajdo, ĉar la servilo funkciis dum semajno sen fiaskoj.
"Lastan semajnon la tajdo estis malalta, sed ĉi-semajne ĝi estas alta."
Iom da terminologio por tiuj, kiuj ne havas jaktolicencon. Tajdoj dependas de la luna ciklo. Kaj dum la Tero turniĝas, ĉiujn 12,5 horojn la gravita tiro de la Suno kaj Luno kreas ondon. Komence de la 12,5-hora ciklo estas alta tajdo, meze de la ciklo estas malfluo, kaj je la fino denove alta tajdo. Sed dum la orbito de la luno ŝanĝiĝas, ankaŭ ŝanĝiĝas la diferenco inter malalta kaj alta tajdo. Kiam la Luno estas inter la Suno kaj la Tero aŭ sur la kontraŭa flanko de la Tero (plenluno aŭ neniu luno), ni ricevas Syzygyn-tajdojn - la plej altajn altajn tajdojn kaj la plej malsuprajn malflusojn. Je duonluno ni ricevas kvadratajn tajdojn - la plej malaltajn tajdojn. La diferenco inter la du ekstremoj multe malpliiĝas. La luna ciklo daŭras 28 tagojn: sizigo - kvadraturo - sizigo - kvadraturo.
Kiam oni klarigis al la teknikistoj la esencon de tajdaj fortoj, ili tuj pensis, ke ili bezonas voki la policon. Kaj sufiĉe logike. Sed rezultas, ke la ulo pravis. Du semajnojn pli frue, destrojero alligis ne malproksime de la oficejo. Ĉiufoje kiam la tajdo levis ĝin al certa alteco, la radarposteno de la ŝipo alvenis ĉe la nivelo de la servilĉambroplanko. Kaj la radaro (aŭ elektronika milita ekipaĵo, aŭ iu alia milita ludilo) kreis kaoson en la komputiloj.
Flugmisio por la raketo
Mi estis komisiita porti grandan (ĉirkaŭ 400 mil liniojn) raket-lanĉan kontrolon kaj monitoran sistemon al novaj versioj de la operaciumo, kompililo kaj lingvo. Pli precize, de Solaris 2.5.1 ĝis Solaris 7, kaj de la Verdix Ada Development System (VADS), skribita en Ada 83, ĝis la Rational Apex Ada-sistemo, skribita en Ada 95. VADS estis aĉetita de Rational, kaj ĝia produkto estis malnoviĝinta, kvankam Rational provis efektivigi kongruajn versiojn de VADS-specifaj pakaĵoj por faciligi la transiron al la Apex-kompililo.
Tri homoj helpis min simple kompili la kodon pure. Ĝi daŭris du semajnojn. Kaj poste mi mem laboris por ke la sistemo funkciu. Resume, ĝi estis la plej malbona arkitekturo kaj efektivigo de programara sistemo, kiun mi renkontis, do daŭris aliajn du monatojn por kompletigi la havenon. La sistemo tiam estis submetita por testado, kiu daŭris plurajn pliajn monatojn. Mi tuj korektis la erarojn, kiuj estis trovitaj dum testado, sed ilia nombro rapide malpliiĝis (la fontkodo estis produkta sistemo, do ĝia funkcieco funkciis sufiĉe fidinde, mi devis nur forigi la erarojn, kiuj aperis dum adaptiĝo al la nova kompililo). Fine, kiam ĉio funkciis kiel ĝi devus, mi estis translokigita al alia projekto.
Kaj vendrede antaŭ Danktago, la telefono sonoris.
La raketlanĉo laŭsupoze estis provita en proksimume tri semajnoj, kaj dum laboratoriotestoj de la retronombrado, la sekvenco de komandoj estis blokita. En la reala vivo, tio abortus la teston, kaj se la blokado okazus ene de kelkaj sekundoj post ekfunkciigo de la motoro, pluraj neinversigeblaj agoj okazus en la helpsistemoj, kiuj postulus longan - kaj multekostan - pretecon de la raketo. Ĝi ne estus komencinta, sed multaj homoj tre ĉagrenus pro la perdo de tempo kaj multe, multe da mono. Ne lasu neniun diri al vi, ke la Departemento pri Defendo elspezas monon malzorge—mi neniam renkontis kontraktan manaĝeron, kiu ne metis buĝeton unue aŭ due, sekvate de horaro.
En antaŭaj monatoj, ĉi tiu retronombrada defio estis rulita centojn da fojoj en multaj varioj, kun nur kelkaj negravaj singultoj. Do la verŝajneco de tio okazanta estis tre malalta, sed ĝiaj konsekvencoj estis tre signifaj. Multipliku ambaŭ ĉi tiujn faktorojn, kaj vi komprenos, ke la novaĵo antaŭdiris ruinitan ferian semajnon por mi kaj dekoj da inĝenieroj kaj administrantoj.
Kaj oni atentis min kiel la persono kiu portis la sistemon.
Kiel ĉe la plej multaj sekurec-kritikaj sistemoj, multaj parametroj estis registritaj, do estis sufiĉe facile identigi la malmultajn liniojn de kodo, kiuj estis ekzekutitaj antaŭ ol la sistemo kraŝis. Kaj kompreneble, estis absolute nenio nekutima pri ili; la samaj esprimoj estis sukcese ekzekutitaj laŭvorte miloj da fojoj dum la sama kuro.
Ni vokis homojn de Apex en Rational ĉar ili estis tiuj kiuj evoluigis la kompililon kaj iuj el la rutinoj kiujn ili evoluigis estis nomitaj en la suspektinda kodo. Ili (kaj ĉiuj aliaj) estis impresitaj, ke necesas atingi la radikon de problemo laŭvorte nacia graveco.
Ĉar estis nenio interesa en la ĵurnaloj, ni decidis provi reprodukti la problemon en loka laboratorio. Tio ne estis facila tasko ĉar la okazaĵo okazis proksimume unufoje po 1000 kuroj. Unu ŝajna kialo estis ke voko al vendist-evoluinta mutex-funkcio (parto de la VADS-migradpakaĵo) Unlock ne kondukis al malŝlosado. La pretigfadeno kiu vokis la funkcion prilaboris korbatmesaĝojn, kiuj nominale alvenis ĉiun sekundon. Ni altigis la frekvencon al 10 Hz, tio estas, 10 fojojn sekundo, kaj komencis kuri. Ĉirkaŭ unu horo poste la sistemo ŝlosis sin. En la protokolo, ni vidis, ke la sekvenco de registritaj mesaĝoj estis la sama kiel dum la malsukcesa testo. Ni faris plurajn pliajn kurojn, la sistemo estis konstante blokita 45-90 minutojn post la komenco, kaj ĉiufoje la ŝtipo enhavis la saman itineron. Kvankam ni teknike funkciis malsaman kodon - la mesaĝfrekvenco estis malsama - la konduto de la sistemo estis la sama, do ni estis certaj, ke ĉi tiu ŝarĝoscenaro kaŭzas la saman problemon.
Nun ni bezonis eltrovi kie ĝuste la blokado okazis en la sinsekvo de esprimoj.
Ĉi tiu efektivigo de la sistemo uzis la Ada taskosistemon, kaj uzis ĝin nekredeble malbone. Taskoj estas altnivela samtempe plenumebla konstruo en Ada, io kiel fadenoj de ekzekuto, nur konstruita en la lingvo mem. Kiam du taskoj bezonas komuniki, ili "starigas rendevuon", interŝanĝas la necesajn datumojn, kaj poste ĉesigas la rendevuon kaj revenas al siaj sendependaj ekzekutoj. Tamen, la sistemo estis efektivigita alimaniere. Post kiam celtasko estis rendevuo, tiu celtasko rendevuis kun alia tasko, kiu tiam rendevuis kun tria tasko, kaj tiel plu ĝis iu prilaborado estis finita. Post tio, ĉiuj tiuj rendevuoj estis kompletigitaj kaj ĉiu tasko devis reveni al sia ekzekuto. Tio estas, ni traktis la plej multekostan funkcion-vokan sistemon en la mondo, kiu ĉesigis la tutan "multaska" procezon dum ĝi prilaboris parton de la eniga datumo. Kaj antaŭe ĉi tio ne kaŭzis problemojn nur ĉar la trafluo estis tre malalta.
Mi priskribis ĉi tiun taskan mekanismon ĉar kiam rendevuo estis petita aŭ atendita finiĝi, "taskoŝanĝo" povus okazi. Tio estas, la procesoro povus komenci prilabori alian taskon, kiu estas preta por esti efektivigita. Montriĝas, ke kiam unu tasko estas preta rendevuo kun alia tasko, tute malsama tasko povas komenciĝi, kaj eventuale kontrolo revenas al la unua rendevuo. Kaj aliaj eventoj povas okazi, kiuj igas la taskon ŝanĝi; unu tia evento estas voko al sistemfunkcio, kiel presi aŭ ekzekuti mutekso.
Por kompreni kiu linio de kodo kaŭzis la problemon, mi devis trovi manieron registri progreson per sekvenco de deklaroj sen ekigi taskoŝanĝon, kiu malhelpus kraŝon. Do mi ne povis profiti Put_Line()por eviti fari I/O-operaciojn. Mi povus agordi nombrilon aŭ ion similan, sed kiel mi povas vidi ĝian valoron se mi ne povas montri ĝin sur la ekrano?
Ankaŭ, ekzamenante la protokolon, montriĝis, ke malgraŭ la frosto en la prilaborado de korbataj mesaĝoj, kiu blokis ĉiujn I/O-operaciojn de la procezo kaj malhelpis, ke alia pretigo estu plenumita, aliaj sendependaj taskoj daŭre estis ekzekutitaj. Tio estas, la laboro ne estis tute blokita, nur (kritika) ĉeno de taskoj.
Ĉi tio estis la indico bezonata por taksi la blokan esprimon.
Mi faris Ada-pakaĵon, kiu enhavis taskon, listigitan tipon kaj tutmondan variablon de tiu tipo. Nombreblaj literaloj estis ligitaj al specifaj esprimoj de la problema sinsekvo (ekz. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), kaj poste enmetis en ĝi atribuajn esprimojn, kiuj atribuis la respondan listigon al tutmonda variablo. Ĉar la objektokodo de ĉio ĉi simple konservis konstanton en memoro, taskoŝanĝo kiel rezulto de ĝia ekzekuto estis ege neverŝajna. Ni ĉefe suspektis pri esprimoj, kiuj povus ŝanĝi la taskon, ĉar la blokado okazis dum ekzekuto prefere ol reveni kiam la tasko reŝanĝas (pro pluraj kialoj).
La spura tasko simple kuris en buklo kaj periode kontrolis por vidi ĉu la valoro de la tutmonda variablo ŝanĝiĝis. Kun ĉiu ŝanĝo, la valoro estis konservita al dosiero. Tiam mallonga atendo kaj nova kontrolo. Mi skribis la variablon al la dosiero ĉar la tasko estis efektivigita nur kiam la sistemo elektis ĝin por ekzekuto kiam ŝanĝi la taskon en la problema areo. Kio ajn okazis en ĉi tiu tasko, ne influus aliajn, senrilatajn blokitajn taskojn.
Estis atendite ke kiam la sistemo atingis la punkton de ekzekuto de la problema kodo, la tutmonda variablo estus rekomencigita kiam moviĝado al ĉiu sekva esprimo. Tiam io okazos, kio igas la taskon ŝanĝi, kaj ĉar ĝia ekzekutfrekvenco (10 Hz) estas pli malalta ol tiu de la monitora tasko, la monitoro povus kapti la valoron de la tutmonda variablo kaj skribi ĝin. En normala situacio, mi povus ricevi ripetan sekvencon de subaro de enumeradoj: la lastaj valoroj de la variablo en la momento de la taskoŝanĝo. Dum pendado, la tutmonda variablo ne plu ŝanĝiĝu, kaj la lasta valoro skribita indikos, kiu esprimo ne finiĝis.
Mi kuris la kodon kun spurado. Li frostiĝis. Kaj la monitorado funkciis kiel horloĝmekanismo.
La protokolo enhavis la atendatan sekvencon, kiu estis interrompita per valoro indikanta ke mutex estis vokita Unlock, kaj la tasko ne estas finita - kiel okazas kun miloj da antaŭaj vokoj.
Apex-inĝenieroj febre analizis sian kodon ĉi-momente kaj trovis lokon en la mutex kie, teorie, seruro povus okazi. Sed ĝia probableco estis tre malalta, ĉar nur certa sinsekvo de eventoj okazantaj en certa tempo povis konduki al blokado. La Leĝo de Murphy, infanoj, ĝi estas la Leĝo de Murphy.
Por protekti la kodon, kiun mi bezonis, mi anstataŭigis la mutex-funkcivokojn (konstruitajn sur la OS-mutex-funkcio) per malgranda denaska Ada-mutex-pakaĵo por kontroli mutex-aliron al tiu peco.
Mi enigis ĝin en la kodon kaj faris la teston. Sep horojn poste la kodo ankoraŭ funkciis.
Mia kodo estis sendita al Rational, kie ili kompilis ĝin, malmuntis ĝin kaj kontrolis ke ĝi ne uzis la saman aliron kiu estis uzita en la problemaj mutex-funkcioj.
Ĉi tio estis la plej plenplena koda revizio de mia kariero 🙂 Estis ĉirkaŭ dek inĝenieroj kaj administrantoj en la ĉambro kun mi, aliaj dek homoj estis en konferenco - kaj ili ĉiuj ekzamenis ĉirkaŭ 20 liniojn de kodo.
La kodo estis reviziita, novaj ruleblaj dosieroj estis kunvenitaj kaj senditaj por formala regrestestado. Kelkajn semajnojn poste, la retronombrada testo estis sukcesa kaj la raketo ekis.
Bone, ĉio estas bona, sed kio estas la signifo de la rakonto?
Ĝi estis absolute naŭza problemo. Centmiloj da linioj de kodo, paralela ekzekuto, pli ol dekduo interagaj procezoj, malbona arkitekturo kaj malbona efektivigo, interfacoj por enkonstruitaj sistemoj kaj milionoj da dolaroj elspezitaj. Neniu premo, ĝuste.
Mi ne estis la sola laboranta pri ĉi tiu problemo, kvankam mi estis en la fokuso dum mi faris la portadon. Sed kvankam mi faris ĝin, tio ne signifas, ke mi komprenis ĉiujn centojn da miloj da linioj de kodo, aŭ eĉ trapasis ilin. La kodon kaj protokolojn analizis inĝenieroj tra la tuta lando, sed kiam ili rakontis al mi siajn hipotezojn pri la kaŭzoj de la malsukceso, mi bezonis nur duonminuton por refuti ilin. Kaj kiam oni petis min analizi teoriojn, mi transdonos ĝin al iu alia, ĉar estis evidente al mi, ke ĉi tiuj inĝenieroj iras la malĝustan vojon. Sonas arogante? Jes, tio estas vera, sed mi malakceptis la hipotezojn kaj petojn pro alia kialo.
Mi komprenis la naturon de la problemo. Mi ne sciis precize kie ĝi okazas aŭ kial, sed mi sciis kio okazas.
Tra la jaroj, mi amasigis multajn sciojn kaj spertojn. Mi estis unu el la pioniroj uzi Ada kaj komprenis ĝiajn avantaĝojn kaj malavantaĝojn. Mi scias kiel la Ada rultempaj bibliotekoj pritraktas taskojn kaj traktas paralelan ekzekuton. Kaj mi komprenas malaltnivelan programadon je la nivelo de memoro, registroj kaj asemblero. Alivorte, mi havas profundan scion pri mia fako. Kaj mi uzis ilin por trovi la kaŭzon de la problemo. Mi ne nur ĉirkaŭlaboris la cimon, mi komprenis kiel trovi ĝin en tre sentema rultempa medio.
Tiaj rakontoj pri lukto kun kodo ne estas tre interesaj por tiuj, kiuj ne konas la trajtojn kaj kondiĉojn de tia lukto. Sed ĉi tiuj rakontoj helpas nin kompreni kion necesas por solvi vere malfacilajn problemojn.
Por solvi vere malfacilajn problemojn, vi devas esti pli ol nur programisto. Vi devas kompreni la "sorton" de la kodo, kiel ĝi interagas kun sia medio, kaj kiel la medio mem funkcias.
Kaj tiam vi havos vian propran ruinitan ferian semajnon.
Daŭrigota.
fonto: www.habr.com