Hierdie is 'n seleksie van stories van die internet oor hoe goggas soms heeltemal ongelooflike manifestasies het. Miskien het jy ook iets om te vertel.
Motorallergie vir vanieljeroomys
’n Storie vir ingenieurs wat verstaan dat die voor die hand liggende nie altyd die antwoord is nie, en hoe vergesog die feite ook al lyk, dit steeds die feite is. Die Pontiac-afdeling van General Motors Corporation het 'n klagte ontvang:
Dit is die tweede keer dat ek vir jou skryf, en ek neem jou nie kwalik dat jy nie antwoord nie, want dit klink mal. Ons gesin het 'n tradisie om elke aand na aandete roomys te eet. Die soorte roomys verander elke keer, en na aandete kies die hele gesin watter roomys om te koop, waarna ek winkel toe gaan. Ek het onlangs 'n nuwe Pontiac gekoop en sedertdien het my reise om roomys te kry 'n probleem geword. Jy sien, elke keer as ek vanieljeroomys koop en terugkom van die winkel af, wil die kar nie start nie. As ek enige ander roomys bring, start die kar sonder enige probleem. Ek wil 'n ernstige vraag vra, maak nie saak hoe dom dit klink nie: "Wat is dit van die Pontiac wat maak dat dit nie begin as ek vanieljeroomys bring nie, maar maklik begin as ek nog 'n geur roomys bring?"
Soos jy jou kan voorstel, was die afdelingspresident skepties oor die brief. Ek het egter net vir ingeval 'n ingenieur gestuur om na te gaan. Hy was verbaas dat hy ontmoet is deur 'n ryk, goed opgevoede man wat in 'n pragtige omgewing woon. Hulle het ooreengekom om dadelik na ete te ontmoet sodat hulle twee winkel toe kon gaan vir roomys. Die aand was dit vanielje, en toe hulle terugkom by die kar, wou dit nie begin nie.
Die ingenieur het nog drie aande gekom. Die eerste keer was die roomys sjokolade. Die motor het begin. Die tweede keer was daar aarbeiroomys. Die motor het begin. Die derde aand het hy gevra om vanielje te neem. Die kar het nie gestart nie.
Die ingenieur het rasioneel geredeneer en geweier om te glo dat die motor allergies was vir vanieljeroomys. Daarom het ek met die eienaar van die motor ooreengekom dat hy sy besoeke sal voortsit totdat hy 'n oplossing vir die probleem gevind het. En langs die pad het hy begin aantekeninge maak: hy het al die inligting neergeskryf, tyd van die dag, tipe petrol, tyd van aankoms en terugkeer van die winkel af, ens.
Die ingenieur het gou besef dat die eienaar van die motor minder tyd spandeer het om vanieljeroomys te koop. Die rede was die uitleg van die goedere in die winkel. Vanieljeroomys was die gewildste en is in 'n aparte vrieskas aan die voorkant van die winkel gehou om dit makliker te maak om dit te vind. En al die ander variëteite was agter in die winkel, en dit het baie meer tyd geneem om die regte verskeidenheid te vind en te betaal.
Nou was die vraag vir die ingenieur: hoekom het die motor nie gestart as minder tyd verloop het sedert die oomblik wat die enjin afgeskakel is nie? Aangesien die probleem tyd was, nie vanieljeroomys nie, het die ingenieur vinnig die antwoord gevind: dit was 'n gasslot. Dit het elke aand plaasgevind, maar toe die motoreienaar meer tyd spandeer het om roomys te soek, kon die enjin genoeg afkoel en het dit maklik begin. En toe die man vanieljeroomys koop, was die enjin nog te warm en het die gasslot nie tyd gehad om op te los nie.
Morele: Selfs heeltemal mal probleme is soms werklik.
Crash buideldas
Dit is pynlik om dit te ervaar. As programmeerder raak jy gewoond daaraan om jou kode eerste, tweede, derde te blameer... en iewers in die tienduisendste plek blameer jy die samesteller. En verder op die lys blameer jy reeds die toerusting.
Hier is my storie oor die hardeware fout.
Vir die speletjie Crash Bandicoot het ek kode geskryf om te laai en op 'n geheuekaart te stoor. Vir so 'n selfvoldane speletjie-ontwikkelaar was dit soos 'n wandeling in die park: ek het gedink die werk sou 'n paar dae neem. Ek het egter uiteindelik ses weke lank die kode ontfout. Langs die pad het ek ander probleme opgelos, maar elke paar dae het ek vir 'n paar uur na hierdie kode teruggekeer. Dit was angs.
Die simptoom het soos volg gelyk: wanneer jy die huidige deurspeel van die speletjie stoor en toegang tot die geheuekaart kry, gaan alles byna altyd goed... Maar soms word die lees- of skryfwerk-time-outs vir geen ooglopende rede nie. 'n Kort opname beskadig dikwels die geheuekaart. Wanneer 'n speler probeer red, misluk hy nie net om te red nie, maar vernietig ook die kaart. Knap.
Na 'n rukkie het ons vervaardiger by Sony, Connie Bus, paniekerig begin raak. Ons kon nie die speletjie met hierdie fout stuur nie, en ses weke later het ek nie verstaan wat die probleem veroorsaak nie. Deur Connie het ons ander PS1-ontwikkelaars gekontak: het iemand iets soortgelyks teëgekom? Geen. Niemand het probleme met die geheuekaart gehad nie.
Wanneer jy geen idees vir ontfouting het nie, is die enigste benadering wat oorbly om te "verdeel en oorheers": verwyder meer en meer kode uit die foutiewe program totdat daar 'n relatief klein fragment oor is wat steeds die probleem veroorsaak. Dit wil sê, jy sny die program stuk vir stuk af totdat die deel wat die gogga bevat oorbly.
Maar die ding is dat dit baie moeilik is om stukke uit 'n videospeletjie te sny. Hoe om dit te laat loop as jy die kode verwyder het wat swaartekrag naboots? Of karakters teken?
Daarom moet ons hele modules vervang met stompe wat voorgee om iets nuttigs te doen, maar in werklikheid iets baie eenvoudig doen wat nie foute kan bevat nie. Ons moet sulke krukke skryf vir die spel om darem te werk. Dit is 'n stadige en pynlike proses.
Kortom, ek het dit gedoen. Ek het meer en meer stukke kode verwyder totdat ek oorgebly het met die aanvanklike kode wat die stelsel konfigureer om die speletjie te laat loop, die weergawe-hardeware inisialiseer, ens. Natuurlik kon ek op hierdie stadium nie 'n stoor en laai spyskaart skep nie, want ek sal 'n stomp vir al die grafiese kode moet skep. Maar ek kan voorgee dat ek 'n gebruiker is wat die (onsigbare) stoor en laai skerm gebruik en vra om te stoor en dan na die geheuekaart te skryf.
Dit het my met 'n klein stukkie kode gelaat wat steeds die bogenoemde probleem gehad het - maar dit het steeds lukraak gebeur! Meestal het alles goed gewerk, maar soms was daar foute. Ek het amper al die speletjie-kode verwyder, maar die fout het nog gelewe. Dit was raaiselagtig: die oorblywende kode het eintlik niks gedoen nie.
Op 'n stadium, seker so drieuur die oggend, het 'n gedagte by my opgekom. Lees en skryf (invoer/uitvoer) bewerkings behels presiese uitvoeringstye. Wanneer jy met 'n hardeskyf, geheuekaart of Bluetooth-module werk, doen die laevlakkode wat vir lees en skryf verantwoordelik is dit in ooreenstemming met klokpulse.
Met die hulp van 'n horlosie word 'n toestel wat nie direk aan die verwerker gekoppel is nie, gesinchroniseer met die kode wat op die verwerker uitgevoer word. Die horlosie bepaal die baud-tempo—die spoed waarteen data versend word. As daar verwarring is met tydsberekeninge, dan is óf die hardeware óf die sagteware, of albei, ook verwar. En dit is baie sleg, want die data kan beskadig word.
Wat as iets in ons kode die tydsberekeninge verwar? Ek het alles wat hiermee verband hou in die toetsprogramkode nagegaan en opgemerk dat ons die programmeerbare timer in PS1 op 1 kHz (1000 regmerkies per sekonde) gestel het. Dit is nogal baie; by verstek, wanneer die konsole begin, loop dit teen 100 Hz. En die meeste speletjies gebruik hierdie frekwensie.
Andy, die speletjie-ontwikkelaar, het die timer op 1 kHz gestel sodat bewegings meer akkuraat bereken sou word. Andy is geneig om oorboord te gaan, en as ons swaartekrag naboots, doen ons dit so akkuraat as moontlik!
Maar wat as die bespoediging van die timer op een of ander manier die algehele tydsberekening van die program beïnvloed het, en dus die klok wat die baudtempo vir die geheuekaart reguleer?
Ek het die timer-kode kommentaar gelewer. Die fout het nie weer voorgekom nie. Maar dit beteken nie dat ons dit reggemaak het nie, want die mislukking het lukraak plaasgevind. Wat as ek net gelukkig was?
’n Paar dae later het ek weer met die toetsprogram geëksperimenteer. Die fout het nie herhaal nie. Ek het teruggegaan na die volledige speletjie-kodebasis en die stoor- en laaikode gewysig sodat die programmeerbare timer na sy oorspronklike waarde (100Hz) sou terugstel voordat ek toegang tot die geheuekaart kry, en dan teruggestel word na 1kHz. Daar was nie meer ongelukke nie.
Maar hoekom het dit gebeur?
Ek het weer teruggekeer na die toetsprogram. Ek het probeer om 'n patroon te vind in die voorkoms van 'n fout met 'n 1 kHz timer. Uiteindelik het ek opgemerk dat die fout voorkom wanneer iemand met 'n PS1-beheerder speel. Aangesien ek dit selde self sal doen - hoekom sou ek 'n kontroleerder nodig hê wanneer ek stoor- en laaikode toets? - Ek het nie eers hierdie afhanklikheid opgemerk nie. Maar een van ons kunstenaars het eendag vir my gewag om klaar te toets – ek het seker op daardie oomblik gevloek – en het die kontroleerder senuweeagtig in sy hande gedraai. N fout het voorgekom. "Wag wat?!" Wel, doen dit weer!”
Toe ek besef dat hierdie twee gebeurtenisse met mekaar verbind is, kon ek die fout maklik weergee: Ek het op die geheuekaart begin opneem, die beheerder geskuif en die geheuekaart verwoes. Vir my het dit soos 'n hardeware fout gelyk.
Ek het na Connie gekom en haar van my ontdekking vertel. Sy het die inligting aan een van die ingenieurs oorgedra wat die PS1 ontwerp het. "Onmoontlik," het hy geantwoord, "dit kan nie 'n hardewareprobleem wees nie." Ek het vir Connie gevra om vir ons 'n gesprek te reël.
Die ingenieur het my gebel en ons het in sy gebroke Engels en my (uiters) gebroke Japannees gestry. Uiteindelik het ek gesê: "Laat ek net my 30 reëls toetsprogram stuur waar die beweging van die beheerder 'n fout veroorsaak." Hy het ingestem. Het gesê dit is 'n mors van tyd en dat hy vreeslik besig is om aan 'n nuwe projek te werk, maar sal ingee omdat ons 'n baie belangrike ontwikkelaar vir Sony is. Ek het my toetsprogram skoongemaak en dit vir hom gestuur.
Die volgende aand (ons was in Los Angeles en hy was in Tokio) het hy my gebel en skaapagtig om verskoning gevra. Dit was 'n hardeware probleem.
Ek weet nie presies wat die fout was nie, maar van wat ek by Sony-hoofkwartier gehoor het, as jy die timer op 'n hoog genoeg waarde gestel het, het dit ingemeng met komponente op die moederbord in die omgewing van die timerkristal. Een van hulle was 'n baudrate-beheerder vir die geheuekaart, wat ook die baudrate vir die beheerders gestel het. Ek is nie 'n ingenieur nie, so ek het dalk iets gemors.
Maar die slotsom is dat daar inmenging tussen komponente op die moederbord was. En wanneer data gelyktydig deur die kontroleerderpoort en die geheuekaartpoort gestuur word met 'n timer wat teen 1 kHz loop, is stukkies verlore, data is verlore en die kaart is beskadig.
Slegte koeie
In die 1980's het my mentor Sergei sagteware geskryf vir die SM-1800, 'n Sowjet-kloon van die PDP-11. Hierdie mikrorekenaar is pas by 'n spoorwegstasie naby Sverdlovsk, 'n belangrike vervoerkern in die USSR, geïnstalleer. Die nuwe stelsel is ontwerp om waens en vragverkeer te stuur. Maar dit het 'n irriterende fout bevat wat gelei het tot willekeurige ineenstortings en ineenstortings. Vals het altyd plaasgevind wanneer iemand saans huis toe gegaan het. Maar ten spyte van 'n deeglike ondersoek die volgende dag, het die rekenaar in alle hand- en outomatiese toetse reg gewerk. Dit dui gewoonlik op 'n rastoestand of 'n ander mededingende fout wat onder sekere toestande voorkom. Moeg vir oproepe laat in die nag, het Sergei besluit om tot die onderkant daarvan te kom, en eerstens te verstaan watter toestande by die rangskikkingswerf tot die rekenaaronderbreking gelei het.
Eerstens het hy statistieke van alle onverklaarde valle versamel en 'n grafiek volgens datum en tyd geskep. Die patroon was duidelik. Nadat hy nog 'n paar dae waargeneem het, het Sergei besef dat hy maklik die tyd van toekomstige stelselfoute kan voorspel.
Hy het gou verneem dat ontwrigtings net plaasgevind het toe die stasie treinvragte beeste van die noorde van die Oekraïne en Wes-Rusland na 'n nabygeleë slaghuis gesorteer het. Dit op sigself was vreemd, want die slaghuis is verskaf deur plase wat baie nader geleë is, in Kazakstan.
Die Tsjernobil-kernkragsentrale het in 1986 ontplof, en radioaktiewe uitval het die omliggende gebiede onbewoonbaar gemaak. Groot gebiede in die noorde van die Oekraïne, Wit-Rusland en Wes-Rusland is besmet. Sergei het hoë vlakke van bestraling in die aankomende waens vermoed en 'n metode ontwikkel om hierdie teorie te toets. Die bevolking is verbied om dosimeters te hê, so Sergei het homself by verskeie militêre manne by die spoorwegstasie geregistreer. Na verskeie drankies vodka het hy daarin geslaag om 'n soldaat te oortuig om die stralingsvlak in een van die verdagte waens te meet. Dit het geblyk dat die vlak verskeie kere hoër as normale waardes was.
Die bees het nie net baie straling uitgestraal nie, die vlak daarvan was so hoog dat dit gelei het tot willekeurige verlies van stukkies in die geheue van die SM-1800, wat in 'n gebou langs die stasie geleë was.
Daar was 'n voedseltekort in die USSR, en die owerhede het besluit om Tsjernobil-vleis met vleis uit ander streke van die land te meng. Dit het dit moontlik gemaak om die algehele vlak van radioaktiwiteit te verminder sonder om waardevolle hulpbronne te verloor. Nadat hy hiervan geleer het, het Sergei onmiddellik dokumente vir emigrasie ingevul. En die rekenaar crashes op hul eie gestop toe die bestraling vlak afgeneem met verloop van tyd.
Deur die pype
Eens op 'n tyd het Movietech Solutions sagteware vir rolprentteaters geskep, ontwerp vir rekeningkunde, kaartjieverkope en algemene bestuur. Die DOS-weergawe van die vlagskip-toepassing was baie gewild onder klein en middelgroot rolprentteaterkettings in Noord-Amerika. Dit is dus nie verbasend nie dat toe 'n Windows 95-weergawe aangekondig is, geïntegreer met die nuutste raakskerms en selfdienskiosks, en toegerus is met allerhande verslagdoeningsinstrumente, dit ook vinnig gewild geword het. Die opdatering het meestal sonder probleme verloop. Die plaaslike IT-personeel het nuwe toerusting geïnstalleer, data gemigreer en besigheid het voortgegaan. Behalwe wanneer dit nie gehou het nie. Wanneer dit gebeur het, sou die maatskappy James uitstuur, met die bynaam "The Cleaner."
Alhoewel die bynaam 'n onheilspellende tipe voorstel, is die skoonmaker net 'n kombinasie van instrukteur, installeerder en jack-of-all-ambagte. James sou 'n paar dae by die kliënt se webwerf spandeer om al die komponente bymekaar te sit, en dan nog 'n paar dae spandeer om die personeel te leer hoe om die nuwe stelsel te gebruik, enige hardewareprobleme wat ontstaan het op te los en die sagteware in wese deur sy kinderskoene te help.
Daarom is dit nie verbasend dat James gedurende hierdie gejaagde tye die oggend by die kantoor aangekom het, en voordat hy sy lessenaar kon bereik, is hy deur die bestuurder gegroet, gevul met kafeïen bo gewoonlik.
“Ek is bevrees jy moet so gou moontlik na Annapolis, Nova Scotia gaan.” Hulle hele stelsel het afgegaan, en na 'n nag se werk met hul ingenieurs, kan ons nie uitvind wat gebeur het nie. Dit lyk of die netwerk op die bediener misluk het. Maar eers nadat die stelsel vir 'n paar minute aan die gang was.
— Hulle het nie teruggekeer na die ou stelsel nie? - James het heeltemal ernstig geantwoord, hoewel hy geestelik sy oë verbaas groot gemaak het.
— Presies: hul IT-spesialis het “prioriteite verander” en besluit om met hul ou bediener te vertrek. James, hulle het die stelsel op ses terreine geïnstalleer en net vir premium-ondersteuning betaal, en hul besigheid word nou bestuur soos dit in die 1950's was.
James kom effens regop.
- Dis 'n ander saak. Goed, kom ons begin.
Toe hy in Annapolis aankom, was die eerste ding wat hy gedoen het om die klant se eerste teater te vind wat 'n probleem gehad het. Op die kaart wat by die lughawe geneem is, het alles ordentlik gelyk, maar die area rondom die verlangde adres het verdag gelyk. Nie ghetto nie, maar herinner aan film noir. Terwyl James by die randsteen in die middestad parkeer het, het 'n prostituut hom genader. Gegewe die grootte van Annapolis, was dit heel waarskynlik die enigste in die hele stad. Haar voorkoms het dadelik die beroemde karakter wat seks vir geld aangebied het op die grootskerm laat dink. Nee, nie oor Julia Roberts nie, maar oor Jon Voight [toespeling op die film "Midnight Cowboy" - ongeveer. baan].
Nadat hy die prostituut op haar pad gestuur het, het James na die bioskoop gegaan. Die omgewing het beter geword, maar dit het steeds die indruk gewek dat dit vervalle is. Nie dat James te bekommerd was nie. Hy was al voorheen op ellendige plekke. En dit was Kanada, waar selfs rowers beleefd genoeg is om "dankie" te sê nadat hulle jou beursie geneem het.
Die syingang na die bioskoop was in 'n nat stegie. James stap na die deur en klop. Gou het dit gekraak en effens oopgemaak.
-Is jy 'n skoonmaker? - 'n hees stem kom van binne.
- Ja, dis ek... ek het alles kom regmaak.
James stap by die bioskoop se voorportaal in. Personeel het blykbaar geen ander keuse gehad nie en begin papierkaartjies aan besoekers uitdeel. Dit het finansiële verslagdoening moeilik gemaak, laat staan nog interessante besonderhede. Maar die personeel het James met verligting gegroet en hom dadelik na die bedienerkamer geneem.
Met die eerste oogopslag was alles reg. James het by die bediener aangemeld en die gewone verdagte plekke nagegaan. Geen probleem. James het egter uit 'n oorvloed van versigtigheid die bediener gesluit, die netwerkkaart vervang en die stelsel teruggedraai. Sy het dadelik voluit begin werk. Die personeel het weer kaartjies begin verkoop.
James het Mark gebel en hom van die situasie ingelig. Dit is nie moeilik om te dink dat James dalk wil bybly en kyk of iets onverwags gebeur nie. Hy het by die trappe afgegaan en die werknemers begin vra wat gebeur het. Dit is duidelik dat die stelsel ophou werk het. Hulle het dit afgeskakel en aangeskakel, alles het gewerk. Maar na 10 minute het die stelsel afgeval.
Net op hierdie oomblik het iets soortgelyks gebeur. Skielik het die kaartjiestelsel foute begin gooi. Die personeel het gesug en die papierkaartjies gegryp, en James het hom na die bedienerkamer gehaas. Alles het goed gelyk met die bediener.
Toe kom een van die werknemers in.
— Die stelsel werk weer.
James was verbaas omdat hy niks gedoen het nie. Meer presies, niks wat die stelsel sou laat werk nie. Hy het uitgeteken, sy foon opgetel en sy maatskappy se ondersteuningslyn gebel. Kort voor lank het dieselfde werknemer die bedienerkamer binnegekom.
- Die stelsel is af.
James het na die bediener gekyk. ’n Interessante en bekende patroon van veelkleurige vorms het op die skerm gedans – chaoties kronkelend en ineenvleg pype. Ons het almal op 'n stadium hierdie skermbewaarder gesien. Dit was pragtig weergegee en letterlik hipnotiserend.
James het 'n knoppie gedruk en die patroon het verdwyn. Hy het hom na die kaartjiekantoor gehaas en op pad ’n werknemer ontmoet wat na hom terugkeer.
— Die stelsel werk weer.
As jy 'n geestelike gesigpalm kan doen, is dit presies wat James gedoen het. Skermbeveiliging. Dit gebruik OpenGL. En daarom, tydens werking, verbruik dit al die hulpbronne van die bedienerverwerker. Gevolglik eindig elke oproep na die bediener met 'n uitteltyd.
James het teruggekeer na die bedienerkamer, aangemeld en die skermbewaarder met die pragtige pype met 'n leë skerm vervang. Dit wil sê, in plaas van 'n skermbewaarder wat 100% van verwerkerhulpbronne verbruik, het ek 'n ander een geïnstalleer wat nie hulpbronne verbruik nie. Toe wag ek 10 minute om my raaiskoot na te gaan.
Toe James by die volgende bioskoop aankom, het hy gewonder hoe om aan sy bestuurder te verduidelik dat hy pas 800 km gevlieg het om die skermbewaarder af te skakel.
Botsing tydens 'n sekere fase van die maan
Ware verhaal. Op 'n dag het 'n sagtewarefout ontstaan wat van die fase van die maan afhang. Daar was 'n bietjie roetine wat algemeen in verskeie MIT-programme gebruik is om die benadering tot die ware fase van die Maan te bereken. GLS het hierdie roetine in 'n LISP-program ingebou wat, wanneer 'n lêer geskryf word, 'n reël met 'n tydstempel van byna 80 karakters lank sal uitvoer. Dit was baie selde dat die eerste reël van 'n boodskap uiteindelik te lank sou wees en na die volgende reël sou lei. En toe die program later hierdie lêer lees, het dit gevloek. Die lengte van die eerste reël het afgehang van die presiese datum en tyd, sowel as die lengte van die fasespesifikasie op die tydstip waarop die tydstempel gedruk is. Dit wil sê, die gogga het letterlik van die fase van die maan afgehang!
Eerste papieruitgawe (Steele-1983) het 'n voorbeeld van so 'n lyn bevat wat tot die beskrewe fout gelei het, maar die tipesetter het dit “reggemaak”. Dit is sedertdien beskryf as 'n "maanfase gogga".
Wees egter versigtig met aannames. 'n Paar jaar gelede het ingenieurs van CERN (Europese Sentrum vir Kernnavorsing) foute teëgekom in eksperimente wat by die Large Electron-Positron Collider uitgevoer is. Aangesien rekenaars aktief die enorme hoeveelheid data verwerk wat deur hierdie toestel gegenereer word voordat hulle die resultaat aan wetenskaplikes gewys het, het baie bespiegel dat die sagteware op een of ander manier sensitief was vir die fase van die maan. Verskeie desperate ingenieurs het tot die bodem van die waarheid gekom. Die fout het ontstaan as gevolg van 'n effense verandering in die geometrie van die 27 km lange ring as gevolg van die vervorming van die Aarde tydens die deurgang van die Maan! Hierdie verhaal het die fisika-folklore betree as "Newton's Revenge on Particle Physics" en 'n voorbeeld van die verband tussen die eenvoudigste en oudste wette van fisika en die mees gevorderde wetenskaplike konsepte.
Om die toilet te spoel stop die trein
Die beste hardeware fout waarvan ek nog ooit gehoor het was op 'n hoëspoed trein in Frankryk. Die fout het gelei tot noodrem van die trein, maar slegs as daar passasiers aan boord was. In elke sodanige geval is die trein uit diens geneem, nagegaan, maar niks is gevind nie. Toe is hy terug na die tou gestuur, en hy het dadelik tot stilstand gekom.
Tydens een van die kontroles het 'n ingenieur wat op die trein gery het, toilet toe gegaan. Hy het gou weggespoel, BOEM! Noodstop.
Die ingenieur het die bestuurder gekontak en gevra:
— Wat het jy gedoen net voor jy gerem het?
- Wel, ek het stadiger gery op die afdraande ...
Dit was vreemd, want tydens normale werking vertraag die trein tientalle kere op afdraandes. Die trein het aanbeweeg, en met die volgende afdraande het die drywer gewaarsku:
- Ek gaan stadiger ry.
Niks het gebeur nie.
— Wat het jy gedoen tydens die laaste rem? - vra die bestuurder.
- Wel... ek was in die toilet...
- Wel, gaan dan toilet toe en doen wat jy gedoen het as ons weer afgaan!
Die ingenieur het toilet toe gegaan en toe die bestuurder waarsku: “Ek ry stadiger,” het hy die water gespoel. Natuurlik het die trein dadelik gestop.
Nou kon hulle die probleem reproduseer en moes die oorsaak vind.
Na twee minute het hulle opgemerk dat die enjinremafstandbeheerkabel (die trein het een enjin aan elke kant gehad) van die muur van die elektriese kas ontkoppel en op die aflos gelê het wat die toiletprop-solenoïde beheer het... Toe die aflos aangeskakel is, het dit inmenging in die remkabel geskep, en die stelselbeskerming teen foute het bloot noodrem ingesluit.
Die poort wat FORTRAN gehaat het
'n Paar maande gelede het ons opgemerk dat die netwerkverbindings op die vasteland [dit was in Hawaii] baie, baie stadig raak. Dit kan vir 10-15 minute duur en dan skielik weer voorkom. Na 'n geruime tyd het my kollega by my gekla dat die netwerkverbindings op die vasteland in die algemeen werk nie. Hy het 'n FORTRAN-kode gehad wat na 'n masjien op die vasteland gekopieer moes word, maar dit kon nie omdat "die netwerk nie lank genoeg gehou het vir die FTP-oplaai om te voltooi nie."
Ja, dit het geblyk dat netwerkfoute plaasgevind het toe 'n kollega probeer het om 'n lêer met bronkode in FORTRAN na 'n masjien op die vasteland te FTP. Ons het probeer om die lêer te argiveer: toe is dit glad gekopieer (maar die teikenmasjien het nie 'n uitpakker gehad nie, so die probleem is nie opgelos nie). Uiteindelik "verdeel" ons die FORTRAN-kode in baie klein stukkies en stuur dit een op 'n slag. Die meeste van die fragmente is sonder probleme gekopieer, maar 'n paar stukke het nie geslaag nie, of daarna geslaag talle pogings.
Nadat ons die problematiese gedeeltes ondersoek het, het ons ontdek dat hulle iets in gemeen het: hulle het almal kommentaarblokke bevat wat begin en eindig met reëls wat uit hoofletter C bestaan (soos 'n kollega verkies om kommentaar te lewer in FORTRAN). Ons het netwerkkundiges op die vasteland e-pos gestuur en om hulp gevra. Natuurlik wou hulle voorbeelde van ons lêers sien wat nie via FTP oorgedra kon word nie... maar ons briewe het hulle nie bereik nie. Uiteindelik het ons met 'n eenvoudige vorendag gekom beskryfhoe nie-oordraagbare lêers lyk. Dit het gewerk :) [Durf ek 'n voorbeeld van een van die problematiese FORTRAN-kommentaar hier byvoeg? Waarskynlik nie die moeite werd nie!]
Op die ou end het ons dit reggekry. 'n Nuwe poort is onlangs tussen ons deel van die kampus en die vastelandnetwerk geïnstalleer. Dit het GROOT probleme gehad om pakkies te stuur wat herhaalde stukkies hoofletter C bevat het! Net 'n paar van hierdie pakkies kan al die poorthulpbronne opneem en verhoed dat die meeste ander pakkies deurkom. Ons het by die gateway-vervaardiger gekla... en hulle het geantwoord: “O, ja, jy word gekonfronteer met ’n fout van herhaalde C! Ons weet reeds van hom.” Ons het uiteindelik die probleem opgelos deur 'n nuwe poort van 'n ander vervaardiger te koop (in eersgenoemde se verdediging kan die onvermoë om FORTRAN-programme oor te dra vir sommige 'n voordeel wees!).
Moeilike tye
'n Paar jaar gelede, terwyl ek besig was om 'n ETL-stelsel in Perl te skep om die koste van fase 40-kliniese proewe te verminder, moes ek ongeveer 000 1 datums verwerk. Twee van hulle het nie die toets geslaag nie. Dit het my nie te veel gepla nie, want hierdie datums is geneem uit data wat deur die kliënt verskaf is, wat dikwels, sal ons sê, verbasend was. Maar toe ek die oorspronklike data nagaan, het dit geblyk dat hierdie datums 2011 Januarie 1 en 2007 Januarie 30 was. Ek het gedink die fout is vervat in die program wat ek sopas geskryf het, maar dit het geblyk dat dit reeds XNUMX jaar was oud. Dit klink dalk geheimsinnig vir diegene wat nie vertroud is met die sagteware-ekosisteem nie. As gevolg van 'n ander maatskappy se jarelange besluit om geld te maak, het my kliënt my betaal om 'n fout reg te stel wat die een maatskappy per ongeluk bekendgestel het en die ander doelbewus. Vir u om te verstaan waarvan ek praat, moet ek praat oor die maatskappy wat die kenmerk bygevoeg het wat uiteindelik 'n fout geword het, sowel as 'n paar ander interessante gebeurtenisse wat bygedra het tot die geheimsinnige fout wat ek reggemaak het.
In die goeie ou dae het Apple-rekenaars soms spontaan hul datum na 1 Januarie 1904 teruggestel. Die rede was eenvoudig: dit het 'n battery-aangedrewe "stelselklok" gebruik om tred te hou met die datum en tyd. Wat het gebeur toe die battery dood is? Rekenaars het begin om die datum op te spoor volgens die aantal sekondes sedert die begin van 'n epog. Met epog het ons die oorspronklike verwysingsdatum bedoel, en vir Macintoshes was dit 1 Januarie 1904. En nadat die battery dood is, is die huidige datum teruggestel na die gespesifiseerde een. Maar hoekom het dit gebeur?
Voorheen het Apple 32 bisse gebruik om die aantal sekondes sedert die oorspronklike datum te stoor. Een bis kan een van twee waardes stoor - 1 of 0. Twee bisse kan een van vier waardes stoor: 00, 01, 10, 11. Drie bisse - een waarde uit agt: 000, 001, 010, 011, 100 , 101, 110, 111, ens. En 32 kan een van 232 waardes stoor, dit wil sê 4 sekondes. Vir Apple-datums is dit gelykstaande aan ongeveer 294 jaar, dus kan ouer Macs nie datums na 967 hanteer nie. En as die stelselbattery doodgaan, word die datum teruggestel na 296 sekondes sedert die begin van die epog, en jy moet die datum handmatig instel elke keer as jy die rekenaar aanskakel (of totdat jy 'n nuwe battery koop).
Apple se besluit om datums sedert die epog as sekondes te stoor, het egter beteken dat ons nie datums voor die epog kon verwerk nie, wat verreikende gevolge gehad het, soos ons sal sien. Apple het 'n kenmerk bekendgestel, nie 'n fout nie. Dit het onder meer beteken dat die Macintosh-bedryfstelsel immuun was teen die “millennium-gogga” (wat nie gesê kon word van baie Mac-toepassings wat hul eie datumstelsels gehad het om beperkings te omseil nie).
Gaan voort. Ons het Lotus 1-2-3, IBM se "moordenaartoepassing" gebruik wat gehelp het om die PC-rewolusie te begin, hoewel Apple-rekenaars VisiCalc gehad het, wat die persoonlike rekenaar 'n sukses gemaak het. In regverdigheid, as 1-2-3 nie verskyn het nie, sou rekenaars skaars opgestyg het, en die geskiedenis van persoonlike rekenaars kon baie anders ontwikkel het. Lotus 1-2-3 het 1900 verkeerdelik as 'n skrikkeljaar behandel. Toe Microsoft sy eerste sigblad, Multiplan, vrygestel het, het dit 'n klein deel van die mark verower. En toe hulle die Excel-projek van stapel gestuur het, het hulle besluit om nie net die ry- en kolomnaamskema van Lotus 1-2-3 te kopieer nie, maar ook om foutversoenbaarheid te verseker deur 1900 doelbewus as 'n skrikkeljaar te hanteer. Hierdie probleem bestaan vandag nog. Dit wil sê, in 1-2-3 was dit 'n fout, maar in Excel was dit 'n bewuste besluit wat verseker het dat alle 1-2-3 gebruikers hul tabelle in Excel kon invoer sonder om die data te verander, selfs al was dit verkeerd.
Maar daar was 'n ander probleem. Eerstens het Microsoft Excel vir die Macintosh vrygestel, wat nie datums voor 1 Januarie 1904 herken het nie. En in Excel is 1 Januarie 1900 as die begin van die era beskou. Daarom het die ontwikkelaars 'n verandering gemaak sodat hul program die tipe era herken en data in homself gestoor het in ooreenstemming met die verlangde era. Microsoft het selfs 'n verduidelikende artikel hieroor geskryf. En hierdie besluit het tot my gogga gelei.
My ETL-stelsel het Excel-sigblaaie van kliënte ontvang wat op Windows geskep is, maar ook op 'n Mac geskep kon word. Daarom kan die begin van die era in die tabel óf 1 Januarie 1900 óf 1 Januarie 1904 wees. Hoe om uit te vind? Die Excel-lêerformaat wys die nodige inligting, maar die ontleder wat ek gebruik het, het dit nie gewys nie (nou wel), en het aangeneem dat jy die epog vir 'n spesifieke tabel ken. Ek kon waarskynlik meer tyd spandeer het om die Excel-binêre formaat te verstaan en 'n pleister na die ontleder outeur te stuur, maar ek het baie meer gehad om vir die kliënt te doen, so ek het vinnig 'n heuristiek geskryf om die epog te bepaal. Sy was eenvoudig.
In Excel kan die datum 5 Julie 1998 voorgestel word in die formaat "07-05-98" (nuttelose Amerikaanse stelsel), "5 Julie 98", "5 Julie 1998", "5-Jul-98" of 'n ander formaat, 'n ander nuttelose formaat (ironies genoeg was een van die formate wat my weergawe van Excel nie aangebied het nie, ISO 8601). Binne die tabel is die ongeformateerde datum egter gestoor as óf "35981" vir epog-1900 of "34519" vir epog-1904 (die getalle verteenwoordig die aantal dae sedert die epog). Ek het eenvoudig 'n eenvoudige ontleder gebruik om die jaar van die geformateerde datum te onttrek, en dan die Excel-ontleder gebruik om die jaar uit die ongeformateerde datum te onttrek. As beide waardes met 4 jaar verskil, dan het ek geweet dat ek 'n stelsel met epog-1904 gebruik.
Hoekom het ek nie net geformateerde datums gebruik nie? Omdat 5 Julie 1998 geformateer kan word as "Julie, 98" met die dag van die maand verlore. Ons het tabelle van soveel maatskappye ontvang wat dit op soveel verskillende maniere geskep het dat dit aan ons (in hierdie geval, ek) was om die datums uit te vind. Buitendien, as Excel dit regkry, dan moet ons ook!
Terselfdertyd het ek 39082 teëgekom. Laat ek jou herinner dat Lotus 1-2-3 1900 as 'n skrikkeljaar beskou het, en dit is getrou in Excel herhaal. En aangesien dit een dag by die jaar 1900 gevoeg het, kan baie datumberekeningsfunksies vir daardie einste dag verkeerd wees. Dit wil sê, 39082 kon 1 Januarie 2011 (op Macs) of 31 Desember 2006 (op Windows) gewees het. As my "year parser" die jaar 2011 uit die geformateerde waarde onttrek het, dan is alles in orde. Maar aangesien die Excel-ontleder nie weet watter epog gebruik word nie, is dit verstek na epog-1900, wat die jaar 2006 terugkeer. My aansoek het gesien dat die verskil 5 jaar was, het dit as 'n fout beskou, dit aangeteken en 'n ongeformateerde waarde teruggestuur.
Om dit te omseil, het ek hierdie geskryf (pseudokode):
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
En toe is al 40 000 datums korrek ontleed.
In die middel van groot druktake
In die vroeë 1980's het my pa by Storage Technology gewerk, 'n nou-ontbinde afdeling wat bandaandrywers en pneumatiese stelsels vir hoëspoed-bandtoevoer geskep het.
Hulle het die aandrywers herontwerp sodat hulle een sentrale "A"-aandrywer kon hê wat aan sewe "B"-aandrywers gekoppel is, en die klein bedryfstelsel in RAM wat die "A"-aandrywing beheer het, kon lees- en skryfbewerkings aan al die "B"-aandrywers delegeer.
Elke keer wanneer skyf "A" begin is, was dit nodig om 'n diskette in die randaandrywer wat aan "A" gekoppel is, te plaas om die bedryfstelsel in sy geheue te laai. Dit was uiters primitief: rekenaarkrag is verskaf deur 'n 8-bis mikrobeheerder.
Die teikengehoor vir sulke toerusting was maatskappye met baie groot datapakhuise - banke, kleinhandelkettings, ens. - wat baie adresetikette of bankstate moes druk.
Een kliënt het 'n probleem gehad. In die middel van 'n druktaak kan een spesifieke aandrywing "A" ophou werk, wat veroorsaak dat die hele taak stilstaan. Om die aandrywer se werking te herstel, moes personeel alles herlaai. En as dit in die middel van 'n ses-uur-taak gebeur het, het 'n groot hoeveelheid duur rekenaartyd verlore gegaan en die skedule van die hele operasie is ontwrig.
Tegnici is van Storage Technologies gestuur. Maar ten spyte van hul beste pogings, was hulle nie in staat om die fout onder toetstoestande te reproduseer nie: dit het gelyk of dit in die middel van groot druktake voorkom. Die probleem was nie die hardeware nie, hulle het alles vervang wat hulle kon: RAM, mikrobeheerder, diskettestasie, elke denkbare deel van die bandstasie - die probleem het voortgeduur.
Toe het die tegnici die hoofkwartier gebel en die Deskundige gebel.
Die kenner het 'n stoel en 'n koppie koffie gegryp, in die rekenaarkamer gesit – in daardie dae was daar kamers wat aan rekenaars toegewy was – en gekyk hoe die personeel 'n groot druktaak in die ry staan. Die deskundige het gewag dat 'n mislukking sou plaasvind - en dit het gebeur. Almal het na die Deskundige gekyk, maar hy het geen idee gehad hoekom dit gebeur het nie. Hy het dus beveel dat die werk weer in die ry moet staan, en al die personeel en tegnici het teruggekeer werk toe.
Die kenner het weer in die stoel gaan sit en begin wag vir 'n mislukking. Ongeveer ses uur het verloop en die mislukking het plaasgevind. Die Expert het weer geen idees gehad nie, behalwe dat alles gebeur het in 'n kamer vol mense. Hy het beveel dat die sending weer begin moet word, gaan sit en wag.
By die derde mislukking het die Deskundige iets opgemerk. Die mislukking het plaasgevind toe personeel bande in 'n buitelandse skyf verander het. Boonop het die mislukking plaasgevind sodra een van die werknemers deur 'n sekere teël op die vloer gestap het.
Die verhoogde vloer is gemaak van aluminiumteëls wat op 'n hoogte van 6 tot 8 duim gelê is. Talle drade van rekenaars het onder die verhoogde vloer deurgeloop om te verhoed dat iemand per ongeluk op 'n belangrike kabel trap. Die teëls is baie styf gelê om te verhoed dat rommel onder die verhoogde vloer inkom.
Die kenner het besef dat een van die teëls vervorm is. Toe 'n werknemer op sy hoek trap, het die rande van die teël teen die aangrensende teëls gevryf. Die plastiekonderdele wat die teëls verbind het, het ook daarmee gevryf, wat statiese mikro-ontladings veroorsaak het wat radiofrekwensie-steurings veroorsaak het.
Vandag is RAM baie beter beskerm teen radiofrekwensie-interferensie. Maar in daardie jare was dit nie die geval nie. Die deskundige het besef dat hierdie steuring die geheue, en daarmee saam die werking van die bedryfstelsel, ontwrig het. Hy het die ondersteuningsdiens gebel, nuwe teëls bestel, dit self geïnstalleer en die probleem het verdwyn.
Dis hoogwater!
Die storie het afgespeel in 'n bedienerkamer, op die vierde of vyfde vloer van 'n kantoor in Portsmouth (dink ek), in die dokke-area.
Eendag het die Unix-bediener met die hoofdatabasis neergestort. Hulle het hom herlaai, maar hy het gelukkig oor en oor bly val. Ons het besluit om iemand van die ondersteuningsdiens te bel.
Die support ou... ek dink sy naam was Mark, maar dit maak nie saak nie... ek dink nie ek ken hom nie. Dit maak nie saak nie, regtig. Kom ons hou by Mark, reg? Groot.
So, 'n paar uur later het Mark aangekom (dit is nie 'n lang pad van Leeds na Portsmouth nie, jy weet), het die bediener aangeskakel en alles het sonder probleme gewerk. Tipiese donnerse ondersteuning, die kliënt raak baie ontsteld daaroor. Mark kyk deur die loglêers en vind niks onaangenaam nie. Dus klim Mark weer op die trein (of met watter vervoermiddel hy ook al aangekom het, dit kon 'n lam koei gewees het vir al wat ek weet ... in elk geval, dit maak nie saak nie, okay?) en gaan terug na Leeds, nadat hy gemors het. die dag.
Dieselfde aand crash die bediener weer. Die storie is dieselfde... die bediener styg nie. Mark probeer oor 'n afstand help, maar die kliënt kan nie die bediener begin nie.
Nog 'n trein, bus, suurlemoen meringue of 'n ander kak, en Mark is terug in Portsmouth. Kyk, die bediener begin sonder enige probleme! Wonderwerk. Mark spandeer etlike ure om te kyk of alles in orde is met die bedryfstelsel of sagteware en vertrek na Leeds.
Rondom die middel van die dag stort die bediener ineen (neem dit rustig!). Hierdie keer lyk dit redelik om die hardeware-ondersteuningsmense in te bring om die bediener te vervang. Maar nee, na so 10 ure val dit ook.
Die situasie het hom vir etlike dae herhaal. Die bediener werk, crash na ongeveer 10 uur en begin nie vir die volgende 2 uur nie. Hulle het verkoeling, geheuelekkasies nagegaan, hulle het alles nagegaan, maar niks gevind nie. Toe stop die ineenstortings.
Die week het sorgeloos verloop... almal was gelukkig. Gelukkig totdat alles weer begin. Die prentjie is dieselfde. 10 ure se werk, 2-3 ure stilstand ...
En toe sê iemand (ek dink hulle het vir my gesê dat hierdie persoon niks met IT te doen het nie) sê:
"Dis die gety!"
Die uitroep is met leë blikke ontvang, en iemand se hand het waarskynlik by die sekuriteitsoproepknoppie gehuiwer.
"Dit hou op om saam met die gety te werk."
Dit lyk na 'n heeltemal vreemde konsep vir IT-ondersteuningswerkers, wat waarskynlik nie die Tide Yearbook sal lees terwyl hulle vir koffie sit nie. Hulle het verduidelik dat dit op geen manier met die gety verband kan hou nie, want die bediener het vir 'n week sonder mislukkings gewerk.
“Verlede week was die gety laag, maar hierdie week is dit hoog.”
'n Bietjie terminologie vir diegene wat nie 'n seiljaglisensie het nie. Getye hang af van die maansiklus. En soos die Aarde roteer, skep die swaartekrag van die Son en Maan elke 12,5 uur 'n vloedgolf. Aan die begin van die 12,5-uur siklus is daar 'n hoogwater, in die middel van die siklus is daar 'n eb, en aan die einde is daar weer 'n hoogwater. Maar soos die maan se wentelbaan verander, verander die verskil tussen laag- en hoogwater ook. Wanneer die Maan tussen die Son en die Aarde of aan die teenoorgestelde kant van die Aarde is (volmaan of geen maan), kry ons Syzygyn getye – die hoogste hooggetye en die laagste laagwater. Met halfmaan kry ons kwadratuurgetye – die laagste getye. Die verskil tussen die twee uiterstes neem baie af. Die maansiklus duur 28 dae: sisigiese - kwadratuur - sisigiese - kwadratuur.
Toe die tegnici die essensie van getykragte verduidelik is, het hulle dadelik gedink dat hulle die polisie moet ontbied. En nogal logies. Maar dit blyk dat die ou reg was. Twee weke tevore het 'n vernietiger nie ver van die kantoor vasgemeer nie. Elke keer as die gety dit tot 'n sekere hoogte opgelig het, het die skip se radarpos op die vlak van die bedienerkamervloer beland. En die radar (of elektroniese oorlogvoeringstoerusting, of een of ander militêre speelding) het chaos in die rekenaars geskep.
Vlugsending vir die vuurpyl
Ek het die taak gehad om 'n groot (ongeveer 400 duisend lyne) vuurpyllanseringsbeheer- en moniteringstelsel na nuwe weergawes van die bedryfstelsel, samesteller en taal oor te dra. Meer presies, van Solaris 2.5.1 tot Solaris 7, en van die Verdix Ada-ontwikkelingstelsel (VADS), geskryf in Ada 83, tot die Rational Apex Ada-stelsel, geskryf in Ada 95. VADS is deur Rational gekoop, en sy produk was verouderd, hoewel Rational probeer het om versoenbare weergawes van VADS-spesifieke pakkette te implementeer om die oorgang na die Apex-samesteller te vergemaklik.
Drie mense het my gehelp om net die kode netjies saamgestel te kry. Dit het twee weke geneem. En toe het ek op my eie gewerk om die stelsel te laat werk. Kortom, dit was die swakste argitektuur en implementering van 'n sagtewarestelsel wat ek teëgekom het, so dit het nog twee maande geneem om die poort te voltooi. Die stelsel is toe vir toetsing ingedien, wat nog 'n paar maande geneem het. Ek het dadelik die foute wat tydens toetsing gevind is, reggestel, maar hul getal het vinnig afgeneem (die bronkode was 'n produksiestelsel, so die funksionaliteit daarvan het redelik betroubaar gewerk, ek moes net die foute verwyder wat tydens aanpassing na die nuwe samesteller ontstaan het). Uiteindelik, toe alles werk soos dit moes, is ek na 'n ander projek oorgeplaas.
En op die Vrydag voor Thanksgiving lui die telefoon.
Die vuurpyllansering was veronderstel om oor ongeveer drie weke getoets te word, en tydens laboratoriumtoetse van die aftelling is die volgorde van opdragte geblokkeer. In die werklike lewe sou dit die toets staak, en as die blokkasie binne 'n paar sekondes van die aanskakel van die enjin plaasgevind het, sou verskeie onomkeerbare aksies in die hulpstelsels plaasvind, wat 'n lang - en duur - gereedheid van die vuurpyl sou vereis. Dit sou nie begin het nie, maar baie mense sou baie ontsteld gewees het oor die verlies aan tyd en baie, baie geld. Moenie dat iemand jou vertel dat die departement van verdediging geld roekeloos bestee nie—ek het nog nooit 'n kontrakterende bestuurder ontmoet wat nie begroting eerste of tweede gestel het nie, gevolg deur skedule.
In vorige maande is hierdie afteluitdaging honderde kere in baie variasies uitgevoer, met slegs 'n paar klein haakplekke. Die waarskynlikheid dat dit sou plaasvind was dus baie laag, maar die gevolge daarvan was baie beduidend. Vermenigvuldig beide hierdie faktore, en jy sal verstaan dat die nuus 'n verwoeste vakansieweek vir my en dosyne ingenieurs en bestuurders voorspel het.
En daar is aandag aan my gegee as die persoon wat die stelsel oorgedra het.
Soos met die meeste sekuriteitskritiese stelsels, is baie parameters aangeteken, so dit was redelik maklik om die paar reëls kode te identifiseer wat uitgevoer is voordat die stelsel neergestort het. En natuurlik was daar absoluut niks ongewoon aan hulle nie; dieselfde uitdrukkings is letterlik duisende kere suksesvol uitgevoer tydens dieselfde lopie.
Ons het die mense van Apex na Rational geroep, want dit was hulle wat die samesteller ontwikkel het en sommige van die roetines wat hulle ontwikkel het, is in die verdagte kode genoem. Hulle (en almal anders) was beïndruk dat daar 'n behoefte was om by die wortel uit te kom van 'n probleem van letterlik nasionale belang.
Aangesien daar niks interessants in die joernale was nie, het ons besluit om die probleem in 'n plaaslike laboratorium te probeer reproduseer. Dit was nie 'n maklike taak nie aangesien die gebeurtenis ongeveer een keer per 1000 lopies plaasgevind het. Een vermoedelike rede was dat 'n oproep na 'n verskaffer-ontwikkelde mutex-funksie (deel van die VADS-migrasiepakket) Unlock het nie tot ontsluiting gelei nie. Die verwerkingsdraad wat die funksie genoem het, het hartklopboodskappe verwerk, wat nominaal elke sekonde aangekom het. Ons het die frekwensie tot 10 Hz verhoog, dit wil sê 10 keer per sekonde, en begin hardloop. Sowat 'n uur later het die stelsel homself gesluit. In die log het ons gesien dat die volgorde van aangetekende boodskappe dieselfde was as tydens die mislukte toets. Ons het nog verskeie lopies gemaak, die stelsel was konsekwent 45-90 minute na die wegspring geblokkeer, en elke keer het die log dieselfde roete bevat. Alhoewel ons tegnies verskillende kodes gebruik het - die boodskapfrekwensie was anders - was die gedrag van die stelsel dieselfde, so ons was vol vertroue dat hierdie lasscenario dieselfde probleem veroorsaak.
Nou moes ons uitvind waar presies die blokkering in die volgorde van uitdrukkings plaasgevind het.
Hierdie implementering van die stelsel het die Ada-taakstelsel gebruik en dit ongelooflik swak gebruik. Take is 'n hoëvlak gelyktydig uitvoerbare konstruk in Ada, iets soos drade van uitvoering, net ingebou in die taal self. Wanneer twee take moet kommunikeer, "stel 'n rendezvous", ruil die nodige data uit, en stop dan die rendezvous en keer terug na hul onafhanklike teregstellings. Die stelsel is egter anders geïmplementeer. Nadat 'n teikentaak afspraak was, het daardie teikentaak afgespreek met 'n ander taak, wat dan met 'n derde taak ontmoet het, en so aan totdat 'n mate van verwerking voltooi is. Hierna is al hierdie afsprake afgehandel en elke taak moes terugkeer na sy uitvoering. Dit wil sê, ons het te doen gehad met die duurste funksie-oproepstelsel ter wêreld, wat die hele "multitasking"-proses gestop het terwyl dit 'n deel van die insetdata verwerk het. En voorheen het dit nie tot probleme gelei net omdat die deurset baie laag was nie.
Ek het hierdie taakmeganisme beskryf, want wanneer 'n rendezvous versoek is of verwag word om te voltooi, kan 'n "taakwisseling" plaasvind. Dit wil sê, die verwerker kan 'n ander taak begin verwerk wat gereed is om uitgevoer te word. Dit blyk dat wanneer een taak gereed is om met 'n ander taak te ontmoet, 'n heeltemal ander taak kan begin uitvoer, en uiteindelik keer beheer terug na die eerste ontmoeting. En ander gebeurtenisse kan voorkom wat veroorsaak dat die taak verander; een so 'n gebeurtenis is 'n oproep na 'n stelselfunksie, soos om 'n mutex te druk of uit te voer.
Om te verstaan watter reël kode die probleem veroorsaak, moes ek 'n manier vind om vordering deur 'n reeks stellings aan te teken sonder om 'n taakskakelaar te aktiveer, wat sou verhoed dat 'n ongeluk plaasvind. So ek kon nie voordeel trek nie Put_Line()om die uitvoer van I/O-bewerkings te vermy. Ek kan 'n tellerveranderlike of iets soortgelyks stel, maar hoe kan ek die waarde daarvan sien as ek dit nie op die skerm kan vertoon nie?
Ook, toe die logboek ondersoek is, het dit geblyk dat, ten spyte van die vriespunt in die verwerking van hartklopboodskappe, wat alle I/O-bewerkings van die proses geblokkeer het en verhoed het dat ander verwerking uitgevoer word, ander onafhanklike take voortgegaan om uitgevoer te word. Dit wil sê, die werk is nie heeltemal geblokkeer nie, slegs 'n (kritieke) ketting van take.
Dit was die leidraad wat nodig was om die blokkerende uitdrukking te evalueer.
Ek het 'n Ada-pakket gemaak wat 'n taak, 'n opgesomde tipe en 'n globale veranderlike van daardie tipe bevat het. Talle letterlike woorde was gebind aan spesifieke uitdrukkings van die problematiese volgorde (bv. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), en het dan toewysingsuitdrukkings daarin ingevoeg wat die ooreenstemmende opsomming aan 'n globale veranderlike toegewys het. Aangesien die objekkode van dit alles bloot 'n konstante in die geheue gestoor het, was taakwisseling as gevolg van die uitvoering daarvan uiters onwaarskynlik. Ons was hoofsaaklik agterdogtig oor uitdrukkings wat die taak kon verander, aangesien die blokkering plaasgevind het met uitvoering eerder as om terug te keer toe die taak teruggeskakel is (om verskeie redes).
Die opsporingstaak het eenvoudig in 'n lus gehardloop en periodiek nagegaan om te sien of die waarde van die globale veranderlike verander het. Met elke verandering is die waarde in 'n lêer gestoor. Dan 'n kort wag en 'n nuwe tjek. Ek het die veranderlike na die lêer geskryf omdat die taak slegs uitgevoer is toe die stelsel dit vir uitvoering gekies het toe die taak in die probleemarea verander is. Wat ook al in hierdie taak gebeur het, sal nie ander, onverwante geblokkeerde take beïnvloed nie.
Daar is verwag dat wanneer die stelsel die punt bereik het om die problematiese kode uit te voer, die globale veranderlike teruggestel sou word wanneer na elke volgende uitdrukking beweeg word. Dan sal iets gebeur wat die taak laat oorskakel, en aangesien die uitvoeringsfrekwensie daarvan (10 Hz) laer is as dié van die moniteringstaak, kan die monitor die waarde van die globale veranderlike vasvang en dit skryf. In 'n normale situasie kan ek 'n herhalende volgorde van 'n subset van opsommings kry: die laaste waardes van die veranderlike ten tyde van die taakskakelaar. Wanneer dit hang, behoort die globale veranderlike nie meer te verander nie, en die laaste waarde wat geskryf is, sal aandui watter uitdrukking nie voltooi is nie.
Ek het die kode met opsporing uitgevoer. Hy het gevries. En die monitering het soos klokslag gewerk.
Die log het die verwagte volgorde bevat, wat onderbreek is deur 'n waarde wat aandui dat 'n mutex geroep is Unlock, en die taak is nie voltooi nie - soos die geval is met duisende vorige oproepe.
Apex-ingenieurs was op hierdie tydstip koorsig besig om hul kode te ontleed en het 'n plek in die mutex gevind waar, teoreties, 'n slot kon voorkom. Maar die waarskynlikheid daarvan was baie laag, aangesien slegs 'n sekere volgorde van gebeure wat op 'n sekere tyd plaasvind, tot blokkering kon lei. Murphy se wet, ouens, dit is Murphy se wet.
Om die stukkie kode te beskerm wat ek nodig gehad het, het ek die mutex-funksie-oproepe (wat bo-op die OS-mutex-funksionaliteit gebou is) vervang met 'n klein inheemse Ada mutex-pakket om mutex-toegang tot daardie stuk te beheer.
Ek het dit in die kode ingevoeg en die toets uitgevoer. Sewe uur later het die kode nog gewerk.
My kode is by Rational ingedien, waar hulle dit saamgestel het, dit uitmekaar gehaal het en gekontroleer het dat dit nie dieselfde benadering gebruik wat in die problematiese mutex-funksies gebruik is nie.
Dit was die mees vol kode-oorsig van my loopbaan 🙂 Daar was omtrent tien ingenieurs en bestuurders in die kamer saam met my, nog tien mense was op 'n konferensie-oproep - en hulle het almal ongeveer 20 reëls kode ondersoek.
Die kode is hersien, nuwe uitvoerbare lêers is saamgestel en ingedien vir formele regressietoetsing. ’n Paar weke later was die afteltoets suksesvol en die vuurpyl het opgestyg.
Goed, dit is alles goed en wel, maar wat is die punt van die storie?
Dit was 'n absoluut walglike probleem. Honderde duisende reëls kode, parallelle uitvoering, meer as 'n dosyn interaksie prosesse, swak argitektuur en swak implementering, koppelvlakke vir ingebedde stelsels en miljoene dollars bestee. Geen druk nie, reg.
Ek was nie die enigste een wat aan hierdie probleem gewerk het nie, alhoewel ek in die kollig was toe ek die oordrag gedoen het. Maar alhoewel ek dit gedoen het, beteken dit nie dat ek al die honderdduisende reëls kode verstaan het, of selfs daarvan afgekyk het nie. Die kode en logs is deur ingenieurs oor die hele land ontleed, maar toe hulle my hul hipoteses oor die oorsake van die mislukking vertel, het dit my net 'n halwe minuut geneem om dit te weerlê. En toe ek gevra is om teorieë te ontleed, sou ek dit aan iemand anders oorgee, want dit was vir my duidelik dat hierdie ingenieurs die verkeerde kant toe gaan. Klink aanmatigend? Ja, dit is waar, maar ek het die hipoteses en versoeke om 'n ander rede verwerp.
Ek het die aard van die probleem verstaan. Ek het nie presies geweet waar dit gebeur of hoekom nie, maar ek het geweet wat gebeur.
Oor die jare het ek baie kennis en ervaring opgedoen. Ek was een van die baanbrekers van die gebruik van Ada en het die voordele en nadele daarvan verstaan. Ek weet hoe die Ada-looptydbiblioteke take hanteer en parallelle uitvoering hanteer. En ek verstaan laevlak-programmering op die vlak van geheue, registers en samesteller. Met ander woorde, ek het diep kennis in my veld. En ek het hulle gebruik om die oorsaak van die probleem te vind. Ek het nie net om die fout gewerk nie, ek het verstaan hoe om dit in 'n baie sensitiewe runtime-omgewing te vind.
Sulke stories van stryd met kode is nie baie interessant vir diegene wat nie vertroud is met die kenmerke en toestande van so 'n stryd nie. Maar hierdie stories help ons om te verstaan wat dit verg om werklik moeilike probleme op te los.
Om werklik moeilike probleme op te los, moet jy meer as net 'n programmeerder wees. Jy moet die "lot" van die kode verstaan, hoe dit in wisselwerking is met sy omgewing, en hoe die omgewing self werk.
En dan sal jy jou eie verwoeste vakansieweek hê.
Om voortgesit te word.
Bron: will.com