Folklore om programmerere og ingeniører (del 1)

Dette er et utvalg historier fra Internett om hvordan feil noen ganger har helt utrolige manifestasjoner. Kanskje du også har noe å fortelle.

Bilallergi mot vaniljeis

En historie for ingeniører som forstår at det åpenbare ikke alltid er svaret, og at uansett hvor langsiktige fakta kan virke, er de fortsatt fakta. Pontiac-divisjonen i General Motors Corporation mottok en klage:

Dette er andre gang jeg skriver til deg, og jeg klandrer deg ikke for ikke å svare, for det høres sprøtt ut. Familien vår har tradisjon for å spise is hver kveld etter middag. Istypene skifter hver gang, og etter middagen velger hele familien hvilken is de skal kjøpe, deretter går jeg til butikken. Jeg har nylig kjøpt en ny Pontiac, og siden den gang har turene mine for å få is blitt et problem. Du skjønner, hver gang jeg kjøper vaniljeis og kommer tilbake fra butikken, vil ikke bilen starte. Tar jeg med annen is, starter bilen uten problem. Jeg vil stille et seriøst spørsmål, uansett hvor dumt det høres ut: "Hva er det med Pontiac som gjør at den ikke starter når jeg tar med vaniljeis, men starter lett når jeg tar med en annen smak av is?" "

Som du kan forestille deg, var divisjonspresidenten skeptisk til brevet. Men for sikkerhets skyld sendte jeg en ingeniør for å sjekke. Han ble overrasket over at han ble møtt av en velstående, velutdannet mann som bodde i et vakkert område. De ble enige om å møtes umiddelbart etter middagen slik at de to kunne gå til butikken for iskrem. Den kvelden var det vanilje, og da de kom tilbake til bilen, ville den ikke starte.

Ingeniøren kom tre kvelder til. Første gang isen var sjokolade. Bilen startet. Andre gang var det jordbæris. Bilen startet. Den tredje kvelden ba han om å få ta vanilje. Bilen startet ikke.

Rasjonelt resonnement nektet ingeniøren å tro at bilen var allergisk mot vaniljeis. Derfor ble jeg enig med eieren av bilen om at han skulle fortsette besøkene sine til han fant en løsning på problemet. Og underveis begynte han å ta notater: han skrev ned all informasjon, tid på dagen, type bensin, ankomsttid og retur fra butikken, etc.

Ingeniøren innså snart at eieren av bilen brukte mindre tid på å kjøpe vaniljeis. Årsaken var utformingen av varene i butikken. Vaniljeis var den mest populære og ble oppbevart i en egen fryser foran i butikken for å gjøre den lettere å finne. Og alle de andre variantene lå bakerst i butikken, og det tok mye mer tid å finne riktig sort og betale.

Nå var spørsmålet til ingeniøren: hvorfor startet ikke bilen hvis det hadde gått mindre tid siden det øyeblikket motoren ble slått av? Siden problemet var tid, ikke vaniljeis, fant ingeniøren raskt svaret: det var en gasslås. Det skjedde hver kveld, men da bileieren brukte mer tid på å lete etter is, klarte motoren å kjøle seg nok ned og startet lett. Og da mannen kjøpte vaniljeis, var motoren fortsatt for varm og gasslåsen rakk ikke å løse seg opp.

Moral: Selv helt sprø problemer er noen ganger reelle.

Crash Bandicoot

Det er vondt å oppleve dette. Som programmerer blir du vant til å skylde på koden din først, andre, tredje... og et sted på ti tusende plass skylder du på kompilatoren. Og lenger ned på listen skylder du allerede på utstyret.

Her er min historie om maskinvarefeilen.

For spillet Crash Bandicoot skrev jeg kode for å laste og lagre på et minnekort. For en så selvglad spillutvikler var det som en tur i parken: Jeg trodde arbeidet ville ta flere dager. Imidlertid endte jeg opp med å feilsøke koden i seks uker. Underveis løste jeg andre problemer, men med noen få dager kom jeg tilbake til denne koden i noen timer. Det var smerte.

Symptomet så slik ut: når du lagrer gjeldende gjennomspilling av spillet og får tilgang til minnekortet, går alt nesten alltid bra... Men noen ganger blir lese- eller skriveoperasjonen tidsavbrudd uten åpenbar grunn. Et kort opptak skader ofte minnekortet. Når en spiller prøver å redde, klarer han ikke bare å redde, men ødelegger også kartet. Dritt.

Etter en stund begynte vår produsent hos Sony, Connie Bus, å få panikk. Vi kunne ikke sende spillet med denne feilen, og seks uker senere forsto jeg ikke hva som forårsaket problemet. Gjennom Connie tok vi kontakt med andre PS1-utviklere: har noen vært borti noe lignende? Nei. Ingen hadde problemer med minnekortet.

Når du ikke har noen ideer for feilsøking, er den eneste tilnærmingen som gjenstår å "dele og herske": fjern mer og mer kode fra det defekte programmet til det er et relativt lite fragment igjen som fortsatt forårsaker problemet. Det vil si at du klipper av programmet bit for bit til den delen som inneholder feilen gjenstår.

Men saken er at det er veldig vanskelig å kutte biter ut av et videospill. Hvordan kjører du det hvis du fjernet koden som emulerer tyngdekraften? Eller tegne karakterer?

Derfor må vi erstatte hele moduler med stubber som later til å gjøre noe nyttig, men som faktisk gjør noe veldig enkelt som ikke kan inneholde feil. Vi må skrive slike krykker for at spillet i det minste skal fungere. Dette er en langsom og smertefull prosess.

Kort sagt, jeg gjorde det. Jeg fjernet flere og flere kodebiter til jeg satt igjen med den første koden som konfigurerer systemet til å kjøre spillet, initialiserer gjengivelsesmaskinvaren osv. Selvfølgelig kunne jeg på dette stadiet ikke lage en lagrings- og lastmeny, fordi jeg måtte lage en stubbe for all grafikkkoden. Men jeg kunne late som om jeg var en bruker ved å bruke den (usynlige) lagre- og lasteskjermen og be om å lagre og deretter skrive til minnekortet.

Dette etterlot meg med en liten kodebit som fortsatt hadde problemet ovenfor - men det skjedde fortsatt tilfeldig! Som oftest fungerte alt bra, men av og til var det feil. Jeg fjernet nesten all spillkoden, men feilen var fortsatt i live. Dette var forvirrende: den gjenværende koden gjorde faktisk ingenting.

På et tidspunkt, sannsynligvis rundt tre om morgenen, kom en tanke opp hos meg. Lese- og skriveoperasjoner (input/output) involverer nøyaktige utførelsestider. Når du jobber med en harddisk, minnekort eller Bluetooth-modul, gjør lavnivåkoden som er ansvarlig for lesing og skriving det i samsvar med klokkepulser.

Ved hjelp av en klokke synkroniseres en enhet som ikke er direkte koblet til prosessoren med koden som kjøres på prosessoren. Klokken bestemmer overføringshastigheten – hastigheten som data overføres med. Hvis det er forvirring med timing, er enten maskinvaren eller programvaren, eller begge deler, også forvirret. Og dette er veldig dårlig, fordi dataene kan bli skadet.

Hva om noe i koden vår forvirrer tidspunktene? Jeg sjekket alt relatert til dette i testprogramkoden og la merke til at vi satte den programmerbare timeren i PS1 til 1 kHz (1000 ticks per sekund). Dette er ganske mye; som standard, når konsollen starter, kjører den på 100 Hz. Og de fleste spill bruker denne frekvensen.

Andy, spillutvikleren, satte timeren til 1 kHz slik at bevegelser ble beregnet mer nøyaktig. Andy har en tendens til å gå over bord, og hvis vi etterligner tyngdekraften, gjør vi det så nøyaktig som mulig!

Men hva om å øke hastigheten på timeren på en eller annen måte påvirket den generelle timingen av programmet, og dermed klokken som regulerer overføringshastigheten for minnekortet?

Jeg kommenterte timerkoden. Feilen skjedde ikke igjen. Men dette betyr ikke at vi fikset det, fordi feilen skjedde tilfeldig. Hva om jeg bare var heldig?

Noen dager senere eksperimenterte jeg igjen med testprogrammet. Feilen gjentok seg ikke. Jeg gikk tilbake til hele spillets kodebase og modifiserte lagrings- og lastkoden slik at den programmerbare timeren ville tilbakestilles til sin opprinnelige verdi (100Hz) før jeg fikk tilgang til minnekortet, og deretter tilbakestilles til 1kHz. Det var ingen flere krasj.

Men hvorfor skjedde dette?

Jeg gikk tilbake til testprogrammet igjen. Jeg prøvde å finne et mønster i forekomsten av en feil med en 1 kHz timer. Etter hvert la jeg merke til at feilen oppstår når noen spiller med en PS1-kontroller. Siden jeg sjelden ville gjort dette selv - hvorfor skulle jeg trenge en kontroller når jeg tester lagre og laste kode? - Jeg la ikke engang merke til denne avhengigheten. Men en dag ventet en av artistene våre på at jeg skulle bli ferdig med å teste – jeg bannet nok i det øyeblikket – og snurret nervøst på kontrolleren i hendene. Det har oppstått en feil. "Vent, hva?!" Vel, gjør det igjen!"

Da jeg innså at disse to hendelsene var sammenkoblet, klarte jeg enkelt å gjenskape feilen: Jeg begynte å ta opp til minnekortet, flyttet kontrolleren og ødela minnekortet. For meg så det ut som en maskinvarefeil.

Jeg kom til Connie og fortalte henne om oppdagelsen min. Hun videreformidlet informasjonen til en av ingeniørene som designet PS1. "Umulig," svarte han, "det kan ikke være et maskinvareproblem." Jeg ba Connie om å avtale en samtale for oss.

Ingeniøren ringte meg og vi kranglet på hans gebroke engelske og min (ekstremt) ødelagte japanske. Til slutt sa jeg: "La meg bare sende mitt 30-linjers testprogram der flytting av kontrolleren forårsaker en feil." Han var enig. Sa at det var bortkastet tid og at han var fryktelig opptatt med å jobbe med et nytt prosjekt, men ville gi etter fordi vi var en veldig viktig utvikler for Sony. Jeg ryddet opp i testprogrammet mitt og sendte det til ham.

Neste kveld (vi var i Los Angeles og han var i Tokyo) ringte han meg og ba om unnskyldning. Det var et maskinvareproblem.

Jeg vet ikke nøyaktig hva feilen var, men fra det jeg hørte på Sony-hovedkvarteret, hvis du satte timeren til en høy nok verdi, forstyrret den komponenter på hovedkortet i nærheten av timerkrystallen. En av dem var en overføringshastighetskontroller for minnekortet, som også satte overføringshastigheten for kontrollerene. Jeg er ikke ingeniør, så jeg kan ha rotet til noe.

Men poenget er at det var interferens mellom komponenter på hovedkortet. Og når du overfører data samtidig gjennom kontrollerporten og minnekortporten med en tidtaker som kjører på 1 kHz, gikk biter tapt, data gikk tapt og kortet ble skadet.

Dårlige kyr

På 1980-tallet skrev min mentor Sergei programvare for SM-1800, en sovjetisk klone av PDP-11. Denne mikrodatamaskinen har nettopp blitt installert på en jernbanestasjon nær Sverdlovsk, et viktig transportknutepunkt i USSR. Det nye systemet ble designet for å rute vogner og godstrafikk. Men den inneholdt en irriterende feil som førte til tilfeldige krasj og krasj. Fall skjedde alltid når noen gikk hjem om kvelden. Men til tross for en grundig undersøkelse dagen etter, fungerte datamaskinen korrekt i alle manuelle og automatiske tester. Dette indikerer vanligvis en rasetilstand eller en annen konkurransefeil som oppstår under visse forhold. Lei av samtaler sent på kvelden, bestemte Sergei seg for å komme til bunns i det, og først og fremst forstå hvilke forhold ved rangergården førte til databruddet.

Først samlet han statistikk over alle uforklarlige fall og laget en graf etter dato og klokkeslett. Mønsteret var tydelig. Etter å ha observert noen dager til, innså Sergei at han lett kunne forutsi tidspunktet for fremtidige systemfeil.

Han fikk snart vite at forstyrrelser bare skjedde når stasjonen sorterte toglaster med storfe fra Nord-Ukraina og vest-Russland på vei til et slakteri i nærheten. Dette i seg selv var merkelig, fordi slakteriet ble forsynt av gårder som ligger mye nærmere, i Kasakhstan.

Kjernekraftverket i Tsjernobyl eksploderte i 1986, og radioaktivt nedfall gjorde områdene rundt ubeboelige. Store områder i Nord-Ukraina, Hviterussland og Vest-Russland ble forurenset. Med mistanke om høye nivåer av stråling i de ankommende vognene utviklet Sergei en metode for å teste denne teorien. Befolkningen ble forbudt å ha dosimetre, så Sergei registrerte seg med flere militære menn på jernbanestasjonen. Etter flere drinker med vodka klarte han å overbevise en soldat om å måle strålingsnivået i en av de mistenkelige vognene. Det viste seg at nivået var flere ganger høyere enn normale verdier.

Ikke bare sendte storfeet ut mye stråling, nivået var så høyt at det førte til tilfeldig tap av biter i minnet til SM-1800, som var plassert i en bygning ved siden av stasjonen.

Det var matmangel i USSR, og myndighetene bestemte seg for å blande Tsjernobyl-kjøtt med kjøtt fra andre regioner i landet. Dette gjorde det mulig å redusere det totale nivået av radioaktivitet uten å miste verdifulle ressurser. Etter å ha lært om dette, fylte Sergei umiddelbart ut dokumenter for emigrasjon. Og datakrasj stoppet av seg selv da strålingsnivået sank over tid.

Gjennom rørene

Movietech Solutions laget en gang programvare for kinoer designet for billettregnskap, salg og generell administrasjon. DOS-versjonen av flaggskipapplikasjonen deres var ganske populær blant små og mellomstore kinokjeder i Nord-Amerika. Så det er ingen overraskelse at da versjonen ble annonsert, Windows 95, integrert med de nyeste berøringsskjermene og selvbetjeningskioskene, og utstyrt med alle slags rapporteringsverktøy, ble også raskt populært. Som oftest gikk oppgraderingen knirkefritt. IT-spesialister på stedet installerte det nye utstyret, migrerte dataene, og virksomheten fortsatte. Bortsett fra når det ikke skjedde. Da det skjedde, sendte selskapet James, med kallenavnet «Rengjøringspersonen», ut for å gjøre jobben.

Selv om kallenavnet antyder en ond type, er renseren bare en kombinasjon av instruktør, installatør og jack-of-all-trade. James ville tilbringe noen dager på kundens nettsted for å sette sammen alle komponentene, og deretter bruke ytterligere et par dager på å lære personalet hvordan de skulle bruke det nye systemet, løse eventuelle maskinvareproblemer som oppsto og i hovedsak hjelpe programvaren gjennom dens spede begynnelse.

Derfor er det ikke overraskende at James i disse hektiske tidene ankom kontoret om morgenen, og før han rakk pulten sin, ble han møtt av lederen, fylt med koffein utover det vanlige.

«Jeg er redd du må komme deg til Annapolis i Nova Scotia så fort som mulig. Hele systemet deres er nede, og etter en natt med samarbeid med ingeniørene deres, kan vi ikke finne ut hva som har skjedd. Det ser ut som ...» server Nettverket sviktet. Men først etter at systemet hadde kjørt i flere minutter.

— De kom ikke tilbake til det gamle systemet? – James svarte helt alvorlig, selv om han mentalt sperret opp øynene av overraskelse.

— Nøyaktig: IT-spesialisten deres «endret prioriteringer» og bestemte seg for å forlate med sin gamle server. James, de installerte systemet på seks steder og betalte nettopp for premium-støtte, og virksomheten deres drives nå som den var på 1950-tallet.

James rettet seg litt opp.

- Det er en annen sak. Ok, la oss komme i gang.

Da han ankom Annapolis, var det første han gjorde å finne kundens første teater som hadde et problem. På kartet tatt på flyplassen så alt greit ut, men området rundt ønsket adresse så mistenkelig ut. Ikke ghetto, men minner om film noir. Da James parkerte ved fortauskanten i sentrum, kom en prostituert bort til ham. Gitt størrelsen på Annapolis, var det mest sannsynlig den eneste i hele byen. Utseendet hennes førte umiddelbart tankene til den berømte karakteren som tilbød sex for penger på storskjerm. Nei, ikke om Julia Roberts, men om Jon Voight [hentydning til filmen "Midnight Cowboy" - ca. kjørefelt].

Etter å ha sendt den prostituerte på vei, gikk James på kino. Området rundt hadde blitt bedre, men det ga likevel inntrykk av å være nedkjørt. Ikke at James var for bekymret. Han har vært på elendige steder før. Og dette var Canada, hvor selv ranere er høflige nok til å si «takk» etter å ha tatt lommeboken.

Sideinngangen til kinoen var i en fuktig bakgate. James gikk til døren og banket på. Snart knirket det og åpnet seg litt.

-Er du renholder? – det kom en hes stemme innenfra.

– Ja, det er meg... Jeg kom for å fikse alt.

James gikk inn i kinolobbyen. Personalet hadde tilsynelatende ikke noe annet valg, og begynte å dele ut papirbilletter til besøkende. Dette gjorde finansiell rapportering vanskelig, enn si mer interessante detaljer. Men personalet hilste James med lettelse og tok ham umiddelbart med til serverrommet.

Ved første øyekast var alt bra. James logget på serveren og sjekket de vanlige mistenkelige stedene. Ikke noe problem. Av stor forsiktighet stengte James imidlertid serveren, byttet ut nettverkskortet og rullet tilbake systemet. Hun begynte umiddelbart å jobbe for fullt. Personalet begynte å selge billetter igjen.

James ringte Mark og informerte ham om situasjonen. Det er ikke vanskelig å forestille seg at James kanskje vil holde seg rundt og se om noe uventet skjer. Han gikk ned trappene og begynte å spørre de ansatte hva som skjedde. Tydeligvis har systemet sluttet å fungere. De skrudde den av og på, alt fungerte. Men etter 10 minutter falt systemet av.

Akkurat i dette øyeblikket skjedde noe lignende. Plutselig begynte billettsystemet å kaste feil. Personalet sukket og grep papirbillettene, og James skyndte seg til serverrommet. Alt så bra ut med serveren.

Så kom en av de ansatte inn.

— Systemet fungerer igjen.

James ble forvirret fordi han ikke hadde gjort noe. Mer presist, ingenting som ville få systemet til å fungere. Han logget ut, tok opp telefonen og ringte selskapets støttelinje. Snart kom den samme ansatte inn i serverrommet.

– Systemet er nede.

James kikket på serveren. Et interessant og kjent mønster av flerfargede former danset på skjermen - kaotisk vridende og sammenflettede rør. Vi har alle sett denne skjermspareren på et tidspunkt. Det var vakkert gjengitt og bokstavelig talt hypnotiserende.

James trykket på en knapp og mønsteret forsvant. Han skyndte seg til billettkontoret og møtte på veien en ansatt som kom tilbake til ham.

— Systemet fungerer igjen.

Hvis du kan gjøre en mental facepalm, er det akkurat det James gjorde. Skjermsparer. Den bruker OpenGL. Og derfor, under drift, bruker den alle ressursene til serverprosessoren. Som et resultat avsluttes hvert anrop til serveren med et tidsavbrudd.

James kom tilbake til serverrommet, logget på og erstattet skjermspareren med de vakre rørene med en blank skjerm. Det vil si at i stedet for en skjermsparer som bruker 100 % av prosessorressursene, installerte jeg en annen som ikke bruker ressurser. Så ventet jeg 10 minutter for å sjekke gjetningen min.

Da James ankom neste kino, lurte han på hvordan han skulle forklare manageren sin at han nettopp hadde fløyet 800 km for å slå av skjermspareren.

Krasj under en viss fase av månen

Sann historie. En dag oppsto det en programvarefeil som var avhengig av månens fase. Det var en liten rutine som ofte ble brukt i forskjellige MIT-programmer for å beregne tilnærmingen til månens sanne fase. GLS bygde denne rutinen inn i et LISP-program som, når du skriver en fil, ville sende ut en linje med et tidsstempel på nesten 80 tegn. Det var svært sjelden at den første linjen i en melding ville ende opp med å bli for lang og føre til neste linje. Og da programmet senere leste denne filen, forbannet den. Lengden på den første linjen var avhengig av nøyaktig dato og klokkeslett, samt lengden på fasespesifikasjonen på tidspunktet tidsstemplet ble skrevet ut. Det vil si at feilen bokstavelig talt var avhengig av månens fase!

Første papirutgave Sjargongfil (Steele-1983) inneholdt et eksempel på en slik linje som førte til den beskrevne feilen, men typesetteren "fikset" den. Dette har siden blitt beskrevet som en "månefasefeil".

Vær imidlertid forsiktig med antagelser. For noen år siden møtte ingeniører fra CERN (European Centre for Nuclear Research) feil i eksperimenter utført ved Large Electron-Positron Collider. Siden datamaskiner aktivt behandler den enorme mengden data som genereres av denne enheten før de viser resultatet til forskere, spekulerte mange i at programvaren på en eller annen måte var følsom for månefasen. Flere desperate ingeniører kom til bunns i sannheten. Feilen oppsto på grunn av en liten endring i geometrien til den 27 km lange ringen på grunn av deformasjonen av jorden under månens passasje! Denne historien har gått inn i fysikkfolklore som "Newtons hevn på partikkelfysikk" og et eksempel på sammenhengen mellom fysikkens enkleste og eldste lover og de mest avanserte vitenskapelige konseptene.

Å spyle toalettet stopper toget

Den beste maskinvarefeilen jeg noen gang har hørt om var på et høyhastighetstog i Frankrike. Feilen førte til nødbremsing av toget, men kun hvis det var passasjerer om bord. I hvert slikt tilfelle ble toget tatt ut av drift, kontrollert, men ingenting ble funnet. Så ble han sendt tilbake til linjen, og han stoppet umiddelbart.

Under en av kontrollene gikk en ingeniør som reiste på toget på toalettet. Han vasket snart bort, BOM! Nødstopp.

Ingeniøren tok kontakt med sjåføren og spurte:

– Hva gjorde du rett før bremsingen?

- Vel, jeg sakket ned på nedstigningen...

Dette var merkelig, for under normal drift bremser toget ned på nedkjøringer dusinvis av ganger. Toget gikk videre, og ved neste nedstigning advarte sjåføren:

– Jeg kommer til å senke farten.

Ingenting skjedde.

— Hva gjorde du under siste bremsing? - spurte sjåføren.

- Vel... jeg var på toalettet...

– Vel, så gå på toalettet og gjør det du gjorde når vi går ned igjen!

Ingeniøren gikk på toalettet, og da sjåføren advarte: «Jeg senker farten», spyla han vannet. Selvfølgelig stoppet toget umiddelbart.

Nå kunne de reprodusere problemet og måtte finne årsaken.

Etter to minutter la de merke til at motorbremsens fjernkontrollkabel (toget hadde en motor i hver ende) var koblet fra veggen på el-skapet og lå på reléet som styrte toalettpluggmagneten... Da reléet ble slått på, skapte det forstyrrelser i bremsekabelen, og systembeskyttelsen mot feil inkluderte rett og slett nødbremsing.

Porten som hatet FORTRAN

For noen måneder siden la vi merke til at nettverksforbindelsene på fastlandet [dette var på Hawaii] ble veldig, veldig trege. Dette kan vare i 10-15 minutter og så plutselig oppstå igjen. Etter en tid klaget min kollega til meg at nettverksforbindelsene på fastlandet generelt virker ikke. Han hadde en FORTRAN-kode som måtte kopieres til en maskin på fastlandet, men det kunne den ikke fordi "nettverket ikke holdt opp lenge nok til at FTP-opplastingen ble fullført."

Ja, det viste seg at nettverksfeil oppsto da en kollega forsøkte å FTP en fil med kildekode i FORTRAN til en maskin på fastlandet. Vi prøvde å arkivere filen: så ble den kopiert problemfritt (men målmaskinen hadde ikke en utpakker, så problemet ble ikke løst). Til slutt "delte" vi FORTRAN-koden i veldig små biter og sendte dem en om gangen. De fleste fragmentene ble kopiert uten problemer, men noen få stykker bestod ikke, eller passerte etter mange forsøk.

Da vi undersøkte de problematiske passasjene, oppdaget vi at de hadde noe til felles: de inneholdt alle kommentarblokker som begynte og sluttet med linjer bestående av stor C (som en kollega foretrakk å kommentere i FORTRAN). Vi sendte e-post til nettverkseksperter på fastlandet og ba om hjelp. Selvfølgelig ønsket de å se prøver av filene våre som ikke kunne overføres via FTP... men brevene våre nådde dem ikke. Til slutt kom vi opp med en enkel beskrivehvordan ikke-overførbare filer ser ut. Det fungerte :) [Tør jeg legge til et eksempel på en av de problematiske FORTRAN-kommentarene her? Sannsynligvis ikke verdt det!]

Til slutt klarte vi å finne ut av det. En ny gateway ble nylig installert mellom vår del av campus og fastlandsnettet. Den hadde ENORME problemer med å overføre pakker som inneholdt gjentatte biter med store bokstaver C! Bare noen få av disse pakkene kan ta opp alle gatewayressursene og forhindre de fleste andre pakker i å komme gjennom. Vi klaget til gatewayprodusenten... og de svarte: «Å, ja, du står overfor en feil med gjentatt C! Vi vet allerede om ham." Vi løste til slutt problemet ved å kjøpe en ny gateway fra en annen produsent (til førstnevntes forsvar kan manglende evne til å overføre FORTRAN-programmer være en fordel for noen!).

Harde tider

For noen år siden, mens jeg jobbet med å lage et ETL-system i Perl for å redusere kostnadene for fase 40 kliniske studier, trengte jeg å behandle rundt 000 1 datoer. To av dem besto ikke prøven. Dette plaget meg ikke så mye fordi disse datoene ble hentet fra klientleverte data som ofte, skal vi si, var overraskende. Men da jeg sjekket de originale dataene, viste det seg at disse datoene var 2011. januar 1 og 2007. januar 30. Jeg trodde at feilen var inneholdt i programmet jeg nettopp hadde skrevet, men det viste seg at det allerede var XNUMX år gammel. Dette kan høres mystisk ut for de som ikke er kjent med programvareøkosystemet. På grunn av et annet selskaps langvarige beslutning om å tjene penger, betalte min klient meg for å fikse en feil som det ene selskapet hadde introdusert ved et uhell og det andre med vilje. For at du skal forstå hva jeg snakker om, må jeg snakke om selskapet som la til funksjonen som endte opp med å bli en feil, samt noen andre interessante hendelser som bidro til den mystiske feilen jeg fikset.

I de gode gamle dager tilbakestilte Apple-datamaskiner noen ganger spontant datoen til 1. januar 1904. Årsaken var enkel: den brukte en batteridrevet "systemklokke" for å holde styr på dato og klokkeslett. Hva skjedde da batteriet døde? Datamaskiner begynte å spore datoen med antall sekunder siden begynnelsen av en epoke. Med epoke mente vi den opprinnelige referansedatoen, og for Macintosh-er var den 1. januar 1904. Og etter at batteriet døde, ble gjeldende dato tilbakestilt til den spesifiserte. Men hvorfor skjedde dette?

Tidligere brukte Apple 32 bits for å lagre antall sekunder siden den opprinnelige datoen. En bit kan lagre en av to verdier - 1 eller 0. To biter kan lagre en av fire verdier: 00, 01, 10, 11. Tre biter - en verdi av åtte: 000, 001, 010, 011, 100 , 101, 110, 111 osv. Og 32 kunne lagre en av 232 verdier, det vil si 4 sekunder. For Apple-datoer tilsvarte dette omtrent 294 år, så eldre Mac-er kan ikke håndtere datoer etter 967. Og hvis systembatteriet dør, tilbakestilles datoen til 296 sekunder siden begynnelsen av epoken, og du må stille inn datoen manuelt hver gang du slår på datamaskinen (eller til du kjøper et nytt batteri).

Apples beslutning om å lagre datoer som sekunder siden epoken gjorde imidlertid at vi ikke kunne håndtere datoer før epoken, noe som fikk vidtrekkende konsekvenser, som vi skal se. Apple introduserte en funksjon, ikke en feil. Dette betydde blant annet at Macintosh-operativsystemet var immun mot «millennium-feilen» (som ikke kunne sies om mange Mac-applikasjoner som hadde egne datosystemer for å omgå restriksjoner).

Gå videre. Vi brukte Lotus 1-2-3, IBMs «killer application» som var med på å lansere PC-revolusjonen, selv om Apple-datamaskiner hadde VisiCalc, som gjorde den personlige datamaskinen til en suksess. I rettferdighet, hvis 1-2-3 ikke hadde dukket opp, ville PC-er neppe tatt av, og historien til personlige datamaskiner kunne ha utviklet seg veldig annerledes. Lotus 1-2-3 behandlet feil 1900 som et skuddår. Da Microsoft ga ut sitt første regneark, Multiplan, tok det en liten andel av markedet. Og da de lanserte Excel-prosjektet, bestemte de seg for ikke bare å kopiere rad- og kolonnenavneskjemaet fra Lotus 1-2-3, men også å sikre feilkompatibilitet ved bevisst å behandle 1900 som et skuddår. Dette problemet eksisterer fortsatt i dag. Det vil si at i 1-2-3 var dette en feil, men i Excel var det en bevisst beslutning som sørget for at alle 1-2-3 brukere kunne importere tabellene sine til Excel uten å endre dataene, selv om de var feil.

Men det var et annet problem. Først ga Microsoft ut Excel for Macintosh, som ikke gjenkjente datoer før 1. januar 1904. Og i Excel ble 1. januar 1900 ansett som begynnelsen på epoken. Derfor gjorde utviklerne en endring slik at programmet deres gjenkjente typen epoke og lagret data i seg selv i samsvar med ønsket epoke. Microsoft skrev til og med en forklarende artikkel om dette. Og denne avgjørelsen førte til feilen min.

ETL-systemet mitt mottok Excel-tabeller fra kunder som ble opprettet for Windows, men de kunne også ha blitt opprettet på en Mac. Derfor kunne epoken i tabellen ha vært enten 1. januar 1900 eller 1. januar 1904. Hvordan kan jeg finne det ut? Excel-filformatet viser den nødvendige informasjonen, men parseren jeg brukte gjorde ikke det (det gjør den nå) og antok at du kjente epoken for en bestemt tabell. Jeg kunne sannsynligvis ha brukt mer tid på å forstå Excels binære format og sendt en patch til parseren som har laget den, men jeg hadde mye annet arbeid å gjøre for klienten, så jeg skrev raskt en heuristikk for å bestemme epoken. Det var enkelt.

I Excel kan datoen 5. juli 1998 representeres i formatet "07-05-98" (ubrukelig amerikansk system), "5. juli 98", "5. juli 1998", "5-jul-98" eller et annet format, et annet ubrukelig format (ironisk nok var et av formatene min versjon av Excel ikke tilbød ISO 8601). I tabellen ble imidlertid den uformaterte datoen lagret som enten "35981" for epoke-1900 eller "34519" for epoke-1904 (tallene representerer antall dager siden epoken). Jeg brukte ganske enkelt en enkel parser for å trekke ut året fra den formaterte datoen, og brukte deretter Excel-parseren for å trekke ut året fra den uformaterte datoen. Hvis begge verdiene var forskjellige med 4 år, visste jeg at jeg brukte et system med epoke-1904.

Hvorfor brukte jeg ikke bare formaterte datoer? Fordi 5. juli 1998 kan formateres som "juli 98" med månedsdagen tapt. Vi mottok tabeller fra så mange selskaper som laget dem på så mange forskjellige måter at det var opp til oss (i dette tilfellet, meg) å finne ut datoene. Dessuten, hvis Excel får det riktig, så burde vi det også!

Så kom jeg over 39082. La meg minne deg på at Lotus 1-2-3 anså 1900 som et skuddår, og Excel gjentok dette trofast. Og siden dette la til én dag til 1900, kunne mange datoberegningsfunksjoner være feil på akkurat den dagen. Det vil si at 39082 kunne ha vært 1. januar 2011 (på Mac-er) eller 31. desember 2006 (i WindowsHvis «årsparseren» min hentet ut året 2011 fra den formaterte verdien, var alt i orden. Men siden Excels parser ikke vet hvilken epoke som brukes, bruker den som standard epoke 1900, og returnerer 2006. Applikasjonen min så at forskjellen var 5 år, anså det som en feil, logget den og returnerte den uformaterte verdien.

For å komme rundt dette skrev jeg dette (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

Og så ble alle 40 000 datoene analysert riktig.

Midt i store utskriftsjobber

På begynnelsen av 1980-tallet jobbet min far i Storage Technology, en nå nedlagt avdeling som skapte båndstasjoner og pneumatiske systemer for høyhastighets båndmating.

De redesignet stasjonene slik at de kunne ha én sentral "A"-stasjon koblet til syv "B"-stasjoner, og det lille OS i RAM som kontrollerte "A"-stasjonen kunne delegere lese- og skriveoperasjoner til alle "B"-stasjonene.

Hver gang stasjon "A" ble startet, var det nødvendig å sette inn en diskett i den eksterne stasjonen koblet til "A" for å laste operativsystemet inn i minnet. Det var ekstremt primitivt: datakraft ble levert av en 8-bits mikrokontroller.

Målgruppen for slikt utstyr var selskaper med svært store datavarehus – banker, butikkjeder osv. – som trengte å skrive ut mange adresseetiketter eller kontoutskrifter.

En klient hadde et problem. Midt i en utskriftsjobb kan en bestemt stasjon "A" slutte å fungere, noe som fører til at hele jobben stopper opp. For å gjenopprette driften av stasjonen, måtte personalet starte alt på nytt. Og hvis dette skjedde midt i en seks timers oppgave, gikk en enorm mengde dyr datatid tapt og tidsplanen for hele operasjonen ble forstyrret.

Teknikere ble sendt fra Storage Technologies. Men til tross for deres beste innsats, klarte de ikke å reprodusere feilen under testforhold: det så ut til å skje midt i store utskriftsjobber. Problemet var ikke maskinvaren, de erstattet alt de kunne: RAM, mikrokontroller, diskettstasjon, alle tenkelige deler av båndstasjonen - problemet vedvarte.

Så ringte teknikerne hovedkvarteret og ringte eksperten.

Eksperten tok en stol og en kopp kaffe, satte seg i datarommet – på den tiden var det rom dedikert til datamaskiner – og så på mens personalet sto i kø for en stor utskriftsjobb. Eksperten ventet på at en svikt skulle oppstå – og det gjorde den. Alle så på eksperten, men han ante ikke hvorfor dette skjedde. Så han beordret at jobben skulle stå i kø igjen, og alle ansatte og teknikere kom tilbake på jobb.

Eksperten satte seg igjen i stolen og begynte å vente på feil. Det gikk rundt seks timer og feilen skjedde. Eksperten hadde igjen ingen ideer, bortsett fra at alt skjedde i et rom fylt med mennesker. Han beordret at oppdraget skulle startes på nytt, satte seg ned igjen og ventet.

Ved den tredje feilen la eksperten merke til noe. Feilen oppsto da personell byttet bånd i en utenlandsk stasjon. Dessuten oppsto feilen så snart en av de ansatte gikk gjennom en bestemt flis på gulvet.

Det hevede gulvet var laget av aluminiumsfliser lagt i en høyde på 6 til 8 tommer. Tallrike ledninger fra datamaskiner løp under det hevede gulvet for å forhindre at noen ved et uhell tråkket på en viktig kabel. Flisene ble lagt svært tett for å hindre at rusk kom inn under det hevede gulvet.

Eksperten innså at en av flisene var deformert. Når en ansatt tråkket på hjørnet, gnidd kantene på flisen mot de tilstøtende flisene. Plastdelene som koblet sammen flisene gned seg også med dem, noe som forårsaket statiske mikroutladninger som skapte radiofrekvensinterferens.

I dag er RAM mye bedre beskyttet mot radiofrekvensinterferens. Men i de årene var det ikke slik. Eksperten innså at denne forstyrrelsen forstyrret minnet, og med det driften av operativsystemet. Han ringte støttetjenesten, bestilte nye fliser, monterte dem selv, og problemet forsvant.

Det er høyvann!

Historien fant sted i et serverrom, i fjerde eller femte etasje på et kontor i Portsmouth (tror jeg), i havneområdet.

En dag krasjet Unix-serveren med hoveddatabasen. De startet ham på nytt, men han fortsatte lykkelig å falle om og om igjen. Vi bestemte oss for å ringe noen fra støttetjenesten.

Støttefyren... Jeg tror han het Mark, men det spiller ingen rolle... Jeg tror ikke jeg kjenner ham. Det spiller ingen rolle, egentlig. La oss holde oss til Mark, ok? Flott.

Så noen timer senere ankom Mark (det er ikke lang vei fra Leeds til Portsmouth, du vet), skrudde på serveren og alt fungerte uten problemer. Typisk jævla støtte, klienten blir veldig opprørt over det. Mark ser gjennom loggfilene og finner ingenting uheldig. Så Mark setter seg tilbake på toget (eller hvilken transportmåte han ankom med, det kunne ha vært en halt ku for alt jeg vet... uansett, det spiller ingen rolle, ok?) og drar tilbake til Leeds, etter å ha kastet bort dagen.

Samme kveld krasjer serveren igjen. Historien er den samme... serveren reiser seg ikke. Mark prøver å hjelpe eksternt, men klienten kan ikke starte serveren.

Nok et tog, buss, sitronmarengs eller noe annet dritt, og Mark er tilbake i Portsmouth. Se, serveren starter opp uten problemer! Mirakel. Mark bruker flere timer på å sjekke at alt er i orden med operativsystemet eller programvaren og drar til Leeds.

Rundt midt på dagen krasjer serveren (ta det med ro!). Denne gangen virker det rimelig å hente inn maskinvarestøttefolk for å erstatte serveren. Men nei, etter ca 10 timer faller den også.

Situasjonen gjentok seg i flere dager. Serveren fungerer, krasjer etter ca 10 timer og starter ikke de neste 2 timene. De sjekket kjøling, minnelekkasjer, de sjekket alt, men fant ingenting. Så stoppet krasjene.

Uken gikk bekymringsløst... alle var fornøyde. Glad til det hele starter igjen. Bildet er det samme. 10 timers arbeid, 2-3 timers nedetid...

Og så sa noen (jeg tror de fortalte meg at denne personen ikke hadde noe med IT å gjøre):

"Det er tidevannet!"

Utropet ble møtt med blanke blikk, og noens hånd nølte sannsynligvis ved sikkerhetsanropsknappen.

"Det slutter å fungere med tidevannet."

Dette ser ut til å være et helt fremmed konsept for IT-støttemedarbeidere, som neppe leser Tide Yearbook mens de setter seg ned for kaffe. De forklarte at dette ikke kunne relateres til tidevannet på noen måte, fordi serveren hadde fungert i en uke uten feil.

«Siste uke var tidevannet lavt, men denne uken er det høyt.»

Litt terminologi for de som ikke har yachtlisens. Tidevannet avhenger av månens syklus. Og mens jorden roterer, skaper gravitasjonskraften til solen og månen hver 12,5 time en flodbølge. I begynnelsen av den 12,5 timer lange syklusen er det høyvann, midt i syklusen er det flo, og på slutten er det høyvann igjen. Men etter hvert som månens bane endres, endres også forskjellen mellom lavvann og høyvann. Når Månen er mellom Sola og Jorden eller på motsatt side av Jorden (fullmåne eller ingen måne), får vi Syzygyn tidevann – det høyeste høyvannet og det laveste lavvannet. Ved halvmåne får vi kvadraturtidevann - det laveste tidevannet. Forskjellen mellom de to ytterpunktene avtar kraftig. Månesyklusen varer i 28 dager: syzygian - kvadratur - syzygian - kvadratur.

Da teknikerne fikk forklart essensen av tidevannskrefter, tenkte de umiddelbart at de måtte ringe politiet. Og ganske logisk. Men det viser seg at fyren hadde rett. To uker tidligere fortøyde en destroyer ikke langt fra kontoret. Hver gang tidevannet hevet den til en viss høyde, havnet skipets radarpost i nivå med serverromsgulvet. Og radaren (eller elektronisk krigføringsutstyr, eller et annet militært leketøy) skapte kaos i datamaskinene.

Flyoppdrag for raketten

Jeg fikk i oppgave å portere et stort (ca. 400 tusen linjer) rakettoppskytingskontroll- og overvåkingssystem til nye versjoner av operativsystemet, kompilatoren og språket. Mer presist, fra Solaris 2.5.1 til Solaris 7, og fra Verdix Ada Development System (VADS), skrevet i Ada 83, til Rational Apex Ada-systemet, skrevet i Ada 95. VADS ble kjøpt av Rational, og produktet ble foreldet, selv om Rational prøvde å implementere kompatible versjoner av VADS-spesifikke pakker for å lette overgangen til Apex-kompilatoren.

Tre personer hjalp meg med å få koden kompilert rent. Det tok to uker. Og så jobbet jeg på egenhånd for å få systemet til å fungere. Kort sagt, det var den verste arkitekturen og implementeringen av et programvaresystem jeg hadde møtt, så det tok ytterligere to måneder å fullføre porten. Systemet ble deretter sendt inn for testing, noe som tok flere måneder. Jeg korrigerte umiddelbart feilene som ble funnet under testing, men antallet ble raskt redusert (kildekoden var et produksjonssystem, så funksjonaliteten fungerte ganske pålitelig, jeg måtte bare fjerne feilene som oppsto under tilpasningen til den nye kompilatoren). Til slutt, da alt fungerte som det skulle, ble jeg overført til et annet prosjekt.

Og fredagen før Thanksgiving ringte telefonen.

Rakettoppskytningen skulle testes om omtrent tre uker, og under laboratorietester av nedtellingen ble kommandosekvensen blokkert. I det virkelige liv ville dette avbrutt testen, og hvis blokkeringen skjedde innen noen få sekunder etter start av motoren, ville det oppstå flere irreversible handlinger i hjelpesystemene, noe som ville kreve en lang – og kostbar – beredskap av raketten. Det ville ikke ha startet, men mange mennesker ville ha blitt veldig opprørt over tapet av tid og mye, mye penger. Ikke la noen fortelle deg at forsvarsdepartementet bruker penger hensynsløst – jeg har aldri møtt en kontraktssjef som ikke satte budsjettet først eller andre, etterfulgt av tidsplan.

I tidligere måneder hadde denne nedtellingsutfordringen blitt kjørt hundrevis av ganger i mange varianter, med bare noen få mindre hikke. Så sannsynligheten for at dette skulle skje var svært lav, men konsekvensene var svært betydelige. Multipliser begge disse faktorene, og du vil forstå at nyhetene spådde en ødelagt ferieuke for meg og dusinvis av ingeniører og ledere.

Og oppmerksomhet ble rettet mot meg som personen som porterte systemet.

Som med de fleste sikkerhetskritiske systemer ble mange parametere logget, så det var ganske enkelt å identifisere de få kodelinjene som ble utført før systemet krasjet. Og selvfølgelig var det absolutt ingenting uvanlig med dem; de samme uttrykkene hadde blitt henrettet tusenvis av ganger i løpet av samme løp.

Vi kalte folk fra Apex inn i Rational fordi det var de som utviklet kompilatoren og noen av rutinene de utviklet ble kalt inn i den mistenkelige koden. De (og alle andre) var imponert over at det var behov for å komme til roten av et problem av bokstavelig talt nasjonal betydning.

Siden det ikke var noe interessant i journalene, bestemte vi oss for å prøve å reprodusere problemet i et lokalt laboratorium. Dette var ikke en lett oppgave siden hendelsen skjedde omtrent en gang per 1000 løp. En mistenkt årsak var at et kall til en leverandørutviklet mutex-funksjon (del av VADS-migreringspakken) Unlock førte ikke til opplåsing. Behandlingstråden som kalte funksjonen behandlet hjerteslagmeldinger, som nominelt ankom hvert sekund. Vi hevet frekvensen til 10 Hz, det vil si 10 ganger i sekundet, og begynte å løpe. Omtrent en time senere låste systemet seg selv. I loggen så vi at sekvensen av innspilte meldinger var den samme som under den mislykkede testen. Vi kjørte flere løp, systemet ble konsekvent blokkert 45-90 minutter etter start, og hver gang inneholdt loggen samme rute. Selv om vi teknisk sett kjørte forskjellig kode - meldingsfrekvensen var forskjellig - var oppførselen til systemet den samme, så vi var sikre på at dette belastningsscenarioet forårsaket det samme problemet.

Nå trengte vi å finne ut hvor nøyaktig blokkeringen skjedde i sekvensen av uttrykk.

Denne implementeringen av systemet brukte Ada-oppgavesystemet, og brukte det utrolig dårlig. Oppgaver er en samtidig kjørbar konstruksjon på høyt nivå i Ada, noe sånt som utførelsestråder, bare innebygd i selve språket. Når to oppgaver må kommunisere, "sett et møte", utveksler de nødvendige data, og stopper deretter møtet og går tilbake til sine uavhengige henrettelser. Systemet ble imidlertid implementert annerledes. Etter at en måloppgave var rendezvous, møttes den måloppgaven med en annen oppgave, som deretter møttes med en tredje oppgave, og så videre til en viss behandling var fullført. Etter dette ble alle disse møtene fullført og hver oppgave måtte gå tilbake til utførelsen. Det vil si at vi hadde å gjøre med det dyreste funksjonsanropssystemet i verden, som stoppet hele "multitasking"-prosessen mens det behandlet deler av inndataene. Og før dette ikke førte til problemer bare fordi gjennomstrømningen var veldig lav.

Jeg beskrev denne oppgavemekanismen fordi når et møte ble bedt om eller forventet å fullføre, kunne en "oppgavebytte" oppstå. Det vil si at prosessoren kan begynne å behandle en annen oppgave som er klar til å utføres. Det viser seg at når en oppgave er klar til å møte med en annen oppgave, kan en helt annen oppgave begynne å utføre, og til slutt går kontrollen tilbake til det første møtet. Og andre hendelser kan oppstå som får oppgaven til å bytte; en slik hendelse er et kall til en systemfunksjon, for eksempel å skrive ut eller utføre en mutex.

For å forstå hvilken kodelinje som forårsaket problemet, trengte jeg å finne en måte å registrere fremdrift gjennom en sekvens av utsagn uten å utløse en oppgavebryter, noe som ville forhindre at en krasj oppsto. Så jeg kunne ikke utnytte det Put_Line()for å unngå å utføre I/O-operasjoner. Jeg kunne angi en tellervariabel eller noe lignende, men hvordan kan jeg se verdien hvis jeg ikke kan vise den på skjermen?

Også, når man undersøkte loggen, viste det seg at til tross for frysingen i behandlingen av hjerteslagmeldinger, som blokkerte alle I/O-operasjoner i prosessen og forhindret annen behandling fra å bli utført, fortsatte andre uavhengige oppgaver å bli utført. Det vil si at arbeidet ikke ble blokkert helt, kun en (kritisk) kjede av oppgaver.

Dette var ledetråden som trengs for å evaluere det blokkerende uttrykket.

Jeg laget en Ada-pakke som inneholdt en oppgave, en opplistet type og en global variabel av den typen. Tallrike bokstaver var bundet til spesifikke uttrykk for den problematiske sekvensen (f. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), og satte deretter inn tilordningsuttrykk som tilordnet den tilsvarende opptellingen til en global variabel. Siden objektkoden til alt dette ganske enkelt lagret en konstant i minnet, var oppgavebytte som et resultat av utførelsen ekstremt usannsynlig. Vi var først og fremst mistenksomme overfor uttrykk som kunne bytte oppgaven, siden blokkeringen skjedde ved utførelse i stedet for å returnere når oppgaven byttes tilbake (av flere grunner).

Sporingsoppgaven kjørte ganske enkelt i en sløyfe og sjekket med jevne mellomrom for å se om verdien til den globale variabelen hadde endret seg. Med hver endring ble verdien lagret i en fil. Så en kort ventetid og en ny sjekk. Jeg skrev variabelen til filen fordi oppgaven bare ble utført når systemet valgte den for kjøring når oppgaven byttes i problemområdet. Uansett hva som skjedde i denne oppgaven ville ikke påvirke andre, urelaterte blokkerte oppgaver.

Det var forventet at når systemet nådde punktet for å kjøre den problematiske koden, ville den globale variabelen bli tilbakestilt når man flytter til hvert neste uttrykk. Da vil det skje noe som får oppgaven til å bytte, og siden dens utførelsesfrekvens (10 Hz) er lavere enn overvåkingsoppgaven, kan monitoren fange opp verdien av den globale variabelen og skrive den. I en normal situasjon kunne jeg få en repeterende sekvens av en undergruppe av oppregninger: de siste verdiene av variabelen på tidspunktet for oppgavebyttet. Ved henging skal den globale variabelen ikke lenger endres, og den siste verdien som er skrevet vil indikere hvilket uttrykk som ikke fullførte.

Jeg kjørte koden med sporing. Han frøs. Og overvåkingen fungerte som smurt.

Loggen inneholdt den forventede sekvensen, som ble avbrutt av en verdi som indikerte at en mutex var blitt kalt Unlock, og oppgaven er ikke fullført - slik tilfellet er med tusenvis av tidligere samtaler.

Apex-ingeniører analyserte febrilsk koden deres på dette tidspunktet og fant et sted i mutexen hvor det teoretisk sett kunne oppstå en låsing. Men sannsynligheten var veldig lav, siden bare en viss sekvens av hendelser som skjedde på et bestemt tidspunkt kunne føre til blokkering. Murphys lov, folkens, det er Murphys lov.

For å beskytte koden jeg trengte, erstattet jeg mutex-funksjonskallene (bygget på toppen av OS-mutex-funksjonaliteten) med en liten innebygd Ada mutex-pakke for å kontrollere mutex-tilgangen til den delen.

Jeg satte den inn i koden og kjørte testen. Syv timer senere fungerte koden fortsatt.

Koden min ble sendt til Rational, hvor de kompilerte den, demonterte den og sjekket at den ikke brukte samme tilnærming som ble brukt i de problematiske mutex-funksjonene.

Dette var den mest overfylte kodegjennomgangen i karrieren min 🙂 Det var rundt ti ingeniører og ledere i rommet med meg, ytterligere ti personer var på en telefonkonferanse - og de undersøkte alle rundt 20 linjer med kode.

Koden ble gjennomgått, nye kjørbare filer ble satt sammen og sendt inn for formell regresjonstesting. Et par uker senere var nedtellingstesten vellykket og raketten lettet.

Ok, det er vel og bra, men hva er poenget med historien?

Det var et helt ekkelt problem. Hundretusenvis av linjer med kode, parallell kjøring, over et dusin samspillende prosesser, dårlig arkitektur og dårlig implementering, grensesnitt for innebygde systemer og millioner av dollar brukt. Ikke noe press, ikke sant.

Jeg var ikke den eneste som jobbet med dette problemet, selv om jeg var i søkelyset mens jeg gjorde porteringen. Men selv om jeg gjorde det, betyr ikke det at jeg forsto alle de hundretusenvis av kodelinjene, eller til og med skummet dem. Koden og loggene ble analysert av ingeniører over hele landet, men da de fortalte meg sine hypoteser om årsakene til feilen, tok det meg bare et halvt minutt å tilbakevise dem. Og når jeg ble bedt om å analysere teorier, ville jeg gi det videre til noen andre, fordi det var åpenbart for meg at disse ingeniørene gikk feil vei. Høres overmodig ut? Ja, dette er sant, men jeg avviste hypotesene og forespørslene av en annen grunn.

Jeg forsto problemets natur. Jeg visste ikke nøyaktig hvor det skjedde eller hvorfor, men jeg visste hva som skjedde.

Gjennom årene har jeg samlet mye kunnskap og erfaring. Jeg var en av pionerene med å bruke Ada og forsto fordelene og ulempene. Jeg vet hvordan Ada runtime-bibliotekene håndterer oppgaver og håndterer parallell kjøring. Og jeg forstår lavnivåprogrammering på nivå med minne, registre og assembler. Jeg har med andre ord dyp kunnskap innen mitt fagfelt. Og jeg brukte dem til å finne årsaken til problemet. Jeg jobbet ikke bare rundt feilen, jeg forsto hvordan jeg kunne finne den i et veldig sensitivt kjøretidsmiljø.

Slike historier om kamp med kode er ikke særlig interessante for de som ikke er kjent med funksjonene og betingelsene for en slik kamp. Men disse historiene hjelper oss å forstå hva som skal til for å løse virkelig vanskelige problemer.

For å løse virkelig vanskelige problemer, må du være mer enn bare en programmerer. Du må forstå "skjebnen" til koden, hvordan den samhandler med miljøet og hvordan miljøet i seg selv fungerer.

Og så får du din egen ødelagte ferieuke.

Skal videreføres.

Kilde: www.habr.com