Aquesta és una selecció d'històries d'Internet sobre com els errors de vegades tenen manifestacions completament increïbles. Potser també tens alguna cosa a explicar.
Al·lèrgia del cotxe al gelat de vainilla
Una història per a enginyers que entenen que l'obvi no sempre és la resposta, i que per molt descabellats que semblin els fets, segueixen sent els fets. La Divisió Pontiac de General Motors Corporation va rebre una queixa:
És la segona vegada que t'escric, i no et culpo per no contestar, perquè sona una bogeria. La nostra família té la tradició de menjar gelat cada nit després de sopar. Els tipus de gelats canvien cada cop i, després de sopar, tota la família tria quin gelat comprar i després vaig a la botiga. Fa poc vaig comprar un Pontiac nou i des de llavors els meus viatges per aconseguir gelats s'han convertit en un problema. Ja veus, cada vegada que compro un gelat de vainilla i torno de la botiga, el cotxe no arrenca. Si porto algun altre gelat, el cotxe arrenca sense cap problema. Vull fer una pregunta seriosa, per molt estúpid que sembli: "Què hi ha del Pontiac que fa que no arrenqui quan porto gelat de vainilla, sinó que arrenqui fàcilment quan porto un altre sabor de gelat?"
Com us podeu imaginar, el president de la divisió es mostrava escèptic sobre la carta. Tanmateix, per si de cas, vaig enviar un enginyer per comprovar-ho. Es va sorprendre que el trobés un home ric i ben educat que vivia en una zona preciosa. Van acordar reunir-se immediatament després de sopar perquè tots dos poguessin anar a la botiga a prendre un gelat. Aquell vespre era vainilla, i quan van tornar al cotxe, no va començar.
L'enginyer va venir tres vespres més. La primera vegada el gelat va ser de xocolata. El cotxe va arrencar. La segona vegada hi havia gelat de maduixa. El cotxe va arrencar. El tercer vespre va demanar que prengués vainilla. El cotxe no va arrencar.
Raonant racionalment, l'enginyer es va negar a creure que el cotxe fos al·lèrgic al gelat de vainilla. Per tant, vaig acordar amb el propietari del cotxe que continuaria amb les seves visites fins que trobés una solució al problema. I pel camí va començar a prendre notes: va anotar tota la informació, hora del dia, tipus de gasolina, hora d'arribada i tornada de la botiga, etc.
L'enginyer aviat es va adonar que el propietari del cotxe passava menys temps comprant gelat de vainilla. El motiu era la disposició de la mercaderia a la botiga. El gelat de vainilla era el més popular i es guardava en un congelador separat a la part davantera de la botiga per facilitar-ne la cerca. I totes les altres varietats estaven a la part posterior de la botiga, i va trigar molt més temps a trobar la varietat adequada i pagar.
Ara la pregunta era per a l'enginyer: per què no va arrencar el cotxe si havia passat menys temps des del moment en què es va apagar el motor? Com que el problema era el temps i no el gelat de vainilla, l'enginyer va trobar ràpidament la resposta: era un pany de gas. Va passar cada vespre, però quan el propietari del cotxe va dedicar més temps a buscar un gelat, el motor va aconseguir refredar prou i engegar fàcilment. I quan l'home va comprar un gelat de vainilla, el motor encara estava massa calent i el tancament de gas no va tenir temps de dissoldre's.
Moral: Fins i tot els problemes completament bojos de vegades són reals.
Crash Bandicoot
És dolorós experimentar això. Com a programador, t'acostumes a culpar el teu codi primer, segon, tercer... i en algun lloc del deu milè lloc culpes al compilador. I més avall de la llista ja culpes l'equip.
Aquí teniu la meva història sobre l'error de maquinari.
Per al joc Crash Bandicoot, vaig escriure codi per carregar i guardar en una targeta de memòria. Per a un desenvolupador de jocs tan engreixat, va ser com un passeig pel parc: vaig pensar que el treball trigaria diversos dies. Tanmateix, vaig acabar depurant el codi durant sis setmanes. Durant el camí, vaig resoldre altres problemes, però cada pocs dies tornava a aquest codi durant unes hores. Va ser agonia.
El símptoma semblava així: quan deseu la jugada actual del joc i accediu a la targeta de memòria, gairebé sempre tot va bé... Però de vegades el temps d'espera de l'operació de lectura o escriptura s'espera sense cap motiu evident. Una gravació curta sovint fa malbé la targeta de memòria. Quan un jugador intenta salvar, no només no aconsegueix salvar, sinó que també destrueix el mapa. Merda.
Després d'un temps, la nostra productora de Sony, Connie Bus, va començar a entrar en pànic. No vam poder enviar el joc amb aquest error, i sis setmanes després no vaig entendre què estava causant el problema. A través de Connie, vam contactar amb altres desenvolupadors de PS1: algú s'ha trobat amb alguna cosa semblant? No. Ningú va tenir problemes amb la targeta de memòria.
Quan no teniu idees per depurar, l'únic enfocament que queda és "dividir i conquerir": traieu cada cop més codi del programa defectuós fins que quedi un fragment relativament petit que encara causa el problema. És a dir, talleu el programa peça per peça fins que quedi la part que conté l'error.
Però el cas és que és molt difícil tallar trossos d'un videojoc. Com executar-lo si heu eliminat el codi que emula la gravetat? O dibuixant personatges?
Per tant, hem de substituir mòduls sencers per talons que pretenguin fer alguna cosa útil, però de fet fer alguna cosa molt senzilla que no pugui contenir errors. Hem d'escriure aquestes crosses perquè el joc almenys funcioni. Aquest és un procés lent i dolorós.
En resum, ho vaig fer. Vaig eliminar cada cop més fragments de codi fins que em vaig quedar amb el codi inicial que configura el sistema per executar el joc, inicialitza el maquinari de renderització, etc. Per descomptat, en aquesta fase no he pogut crear un menú de desar i carregar, perquè hauria de crear un taló per a tot el codi gràfic. Però podria fingir ser un usuari utilitzant la pantalla de desar i carregar (invisible) i demanar que es desi i després escrigui a la targeta de memòria.
Això em va deixar amb un petit fragment de codi que encara tenia el problema anterior, però encara passava a l'atzar! Molt sovint tot funcionava bé, però de tant en tant hi havia problemes. Vaig eliminar gairebé tot el codi del joc, però l'error encara era viu. Això va ser desconcertant: el codi restant no va fer res.
En algun moment, probablement cap a les tres de la matinada, se'm va ocórrer un pensament. Les operacions de lectura i escriptura (entrada/sortida) impliquen temps d'execució precisos. Quan treballeu amb un disc dur, una targeta de memòria o un mòdul Bluetooth, el codi de baix nivell responsable de la lectura i l'escriptura ho fa d'acord amb els polsos del rellotge.
Amb l'ajuda d'un rellotge, un dispositiu que no està connectat directament al processador es sincronitza amb el codi que s'executa al processador. El rellotge determina la velocitat en baudis, la velocitat a la qual es transmeten les dades. Si hi ha confusió amb els temps, també es confonen el maquinari o el programari, o tots dos. I això és molt dolent, perquè les dades es poden malmetre.
Què passa si alguna cosa del nostre codi confon els temps? Vaig comprovar tot el relacionat amb això al codi del programa de prova i em vaig adonar que vam establir el temporitzador programable a PS1 a 1 kHz (1000 ticks per segon). Això és bastant; per defecte, quan s'inicia la consola, funciona a 100 Hz. I la majoria de jocs utilitzen aquesta freqüència.
Andy, el desenvolupador del joc, va configurar el temporitzador a 1 kHz perquè els moviments es calculessin amb més precisió. Andy acostuma a exagerar, i si emulem la gravetat, ho fem amb la màxima precisió possible!
Però, què passa si l'acceleració del temporitzador afectés d'alguna manera el temps general del programa i, per tant, el rellotge que regula la velocitat en baudis de la targeta de memòria?
Vaig comentar el codi del temporitzador. L'error no va tornar a passar. Però això no vol dir que ho hem solucionat, perquè la fallada es va produir de manera aleatòria. I si només tingués sort?
Uns dies després vaig tornar a experimentar amb el programa de proves. L'error no es va repetir. Vaig tornar a la base de codis del joc completa i vaig modificar el codi de desar i carregar perquè el temporitzador programable es reiniciés al seu valor original (100 Hz) abans d'accedir a la targeta de memòria i, a continuació, es reiniciés a 1 kHz. No hi va haver més accidents.
Però per què va passar això?
Vaig tornar al programa de proves de nou. Vaig intentar trobar algun patró en l'aparició d'un error amb un temporitzador d'1 kHz. Finalment em vaig adonar que l'error es produeix quan algú juga amb un controlador PS1. Com que poques vegades ho faria jo mateix, per què necessitaria un controlador per provar desar i carregar el codi? - Ni tan sols em vaig adonar d'aquesta dependència. Però un dia un dels nostres artistes estava esperant que acabés de fer les proves -probablement estava maleint en aquell moment- i va fer girar nerviosament el controlador a les seves mans. S'ha produït un error. "Espera Què?!" Bé, torna a fer-ho!"
Quan em vaig adonar que aquests dos esdeveniments estaven interconnectats, vaig poder reproduir l'error fàcilment: vaig començar a gravar a la targeta de memòria, vaig moure el controlador i vaig arruïnar la targeta de memòria. A mi em va semblar un error de maquinari.
Vaig venir a la Connie i li vaig explicar el meu descobriment. Va transmetre la informació a un dels enginyers que va dissenyar la PS1. "Impossible", va respondre, "No pot ser un problema de maquinari". Vaig demanar a la Connie que ens organitzés una conversa.
L'enginyer em va trucar i vam discutir amb el seu anglès trencat i el meu japonès (extremament) trencat. Finalment vaig dir: "Permeteu-me enviar el meu programa de prova de 30 línies on moure el controlador provoca un error". Va estar d'acord. Va dir que era una pèrdua de temps i que estava molt ocupat treballant en un nou projecte, però que cediria perquè érem un desenvolupador molt important per a Sony. Vaig netejar el meu programa de proves i li vaig enviar.
L'endemà al vespre (estàvem a Los Angeles i ell a Tòquio) em va trucar i em va demanar disculpes tímidament. Va ser un problema de maquinari.
No sé quin era exactament l'error, però pel que vaig sentir a la seu de Sony, si configureu el temporitzador a un valor prou alt, interferia amb els components de la placa base als voltants del cristall del temporitzador. Un d'ells era un controlador de velocitat en baudis per a la targeta de memòria, que també establia la velocitat en baudis per als controladors. No sóc enginyer, així que potser he equivocat alguna cosa.
Però la conclusió és que hi va haver interferències entre els components de la placa base. I en transmetre dades simultàniament a través del port del controlador i el port de la targeta de memòria amb un temporitzador que funcionava a 1 kHz, es van perdre bits, les dades es van perdre i la targeta es va danyar.
Males vaques
A la dècada de 1980, el meu mentor Sergei va escriure programari per a l'SM-1800, un clon soviètic del PDP-11. Aquest microordinador s'acaba d'instal·lar en una estació de ferrocarril prop de Sverdlovsk, un important centre de transport a l'URSS. El nou sistema va ser dissenyat per encaminar els vagons i el trànsit de mercaderies. Però contenia un error molest que provocava bloquejos i bloquejos aleatoris. Les caigudes sempre es produïen quan algú anava a casa al vespre. Però malgrat una investigació exhaustiva l'endemà, l'ordinador va funcionar correctament en totes les proves manuals i automàtiques. Això normalment indica una condició de carrera o algun altre error competitiu que es produeix en determinades condicions. Cansat de trucades a la nit, en Sergei va decidir arribar al fons i, en primer lloc, entendre quines condicions al pati de classificació van provocar l'avaria de l'ordinador.
Primer, va recopilar estadístiques de totes les caigudes inexplicables i va crear un gràfic per data i hora. El patró era evident. Després d'observar durant uns quants dies més, Sergei es va adonar que podia predir fàcilment el moment dels futurs errors del sistema.
Aviat es va assabentar que les interrupcions només es van produir quan l'estació ordenava els trens carregats de bestiar del nord d'Ucraïna i l'oest de Rússia que es dirigien a un escorxador proper. Això en si mateix era estrany, perquè l'escorxador era subministrat per granges situades molt més a prop, al Kazakhstan.
La central nuclear de Txernòbil va explotar el 1986 i les precipitacions radioactives van fer que les zones circumdants fossin inhabitables. Àmplies zones del nord d'Ucraïna, Bielorússia i l'oest de Rússia van ser contaminades. Sospitant alts nivells de radiació als vagons que arribaven, Sergei va desenvolupar un mètode per provar aquesta teoria. A la població se li prohibia tenir dosímetres, així que Sergei es va registrar amb diversos militars a l'estació de ferrocarril. Després de prendre diverses copes de vodka, va aconseguir convèncer un soldat per mesurar el nivell de radiació en un dels vagons sospitosos. Va resultar que el nivell era diverses vegades més alt que els valors normals.
El bestiar no només emetia molta radiació, sinó que el seu nivell era tan alt que va provocar la pèrdua aleatòria de bits a la memòria de l'SM-1800, que es trobava en un edifici al costat de l'estació.
Hi va haver una escassetat d'aliments a l'URSS i les autoritats van decidir barrejar carn de Txernòbil amb carn d'altres regions del país. Això va permetre reduir el nivell global de radioactivitat sense perdre recursos valuosos. Després d'haver après això, Sergei immediatament va omplir els documents per a l'emigració. I els accidents de l'ordinador es van aturar per si mateixos quan el nivell de radiació va disminuir amb el temps.
A través de les canonades
Hi havia una vegada, Movietech Solutions va crear un programari per a cinemes, pensat per a la comptabilitat, la venda d'entrades i la gestió general. La versió DOS de l'aplicació insígnia va ser força popular entre les cadenes de cinema petites i mitjanes d'Amèrica del Nord. Per tant, no és d'estranyar que quan es va anunciar una versió de Windows 95, integrada amb les últimes pantalles tàctils i quioscos d'autoservei, i equipada amb tot tipus d'eines d'informes, també es va fer popular ràpidament. Molt sovint, l'actualització va anar sense problemes. El personal informàtic local va instal·lar nous equips, va migrar les dades i el negoci va continuar. Excepte quan no va durar. Quan això passava, l'empresa enviava a James, sobrenomenat "The Cleaner".
Tot i que el sobrenom suggereix un tipus nefast, el netejador és només una combinació d'instructor, instal·lador i tot. James passava uns dies al lloc del client reunint tots els components, i després passava un parell de dies més ensenyant al personal com utilitzar el nou sistema, solucionant els problemes de maquinari que sorgissin i ajudant essencialment el programari durant la seva infància.
Per tant, no és estrany que durant aquests moments agitats, James arribés a l'oficina al matí, i abans que pogués arribar al seu escriptori, fos rebut pel gerent, ple de cafeïna més enllà de l'habitual.
"Em temo que necessiteu anar a Annapolis, Nova Escòcia, tan aviat com sigui possible". Tot el seu sistema va fallar i després d'una nit treballant amb els seus enginyers, no podem esbrinar què va passar. Sembla que la xarxa ha fallat al servidor. Però només després que el sistema hagués estat en funcionament durant uns quants minuts.
— No van tornar al sistema antic? - va respondre en James completament seriós, encara que mentalment va obrir els ulls sorprès.
— Exactament: el seu especialista en informàtica "va canviar les prioritats" i va decidir marxar amb el seu servidor antic. James, van instal·lar el sistema en sis llocs i només van pagar per l'assistència premium, i el seu negoci ara s'executa com a la dècada de 1950.
James es va aixecar lleugerament.
- Això és un altre tema. D'acord, comencem.
Quan va arribar a Annapolis, el primer que va fer va ser trobar el primer teatre del client que tenia un problema. Al mapa fet a l'aeroport, tot semblava decent, però la zona al voltant de l'adreça desitjada semblava sospitosa. No és un gueto, però recorda el cinema negre. Mentre James aparcava a la vorera del centre, una prostituta se li va acostar. Donada la mida d'Annapolis, probablement era l'única de tota la ciutat. La seva aparició immediatament va recordar el famós personatge que oferia sexe per diners a la pantalla gran. No, no de Julia Roberts, sinó de Jon Voight [al·lusió a la pel·lícula "Midnight Cowboy" - aprox. carril].
Després d'haver enviat la prostituta al seu camí, James va anar al cinema. L'entorn havia millorat, però encara donava la impressió d'estar atropellat. No és que James estigués massa preocupat. Ha estat en llocs miserables abans. I això va ser el Canadà, on fins i tot els atracadors són prou educats com per dir "gràcies" després de prendre la cartera.
L'entrada lateral del cinema era en un carreró humit. En James va anar a la porta i va trucar. Aviat va cruixir i es va obrir una mica.
-Ets netejador? - va sortir una veu ronca des de dins.
- Sí, sóc jo... he vingut a arreglar-ho tot.
James va entrar al vestíbul del cinema. Pel que sembla, no tenint més remei, el personal va començar a repartir bitllets de paper als visitants. Això va dificultar els informes financers, i molt menys detalls més interessants. Però el personal va saludar en James amb alleujament i immediatament el va portar a la sala de servidors.
A primera vista, tot estava bé. James va iniciar sessió al servidor i va comprovar els llocs habituals sospitosos. Cap problema. Tanmateix, per precaució, James va tancar el servidor, va substituir la targeta de xarxa i va tornar el sistema. De seguida va començar a treballar plenament. El personal va començar a vendre entrades de nou.
James va trucar a Mark i li va informar de la situació. No és difícil imaginar que en James es vol quedar-se i veure si passa alguna cosa inesperada. Va baixar les escales i va començar a preguntar als empleats què va passar. Evidentment el sistema ha deixat de funcionar. El van apagar i encendre, tot va funcionar. Però al cap de 10 minuts el sistema es va desfer.
Just en aquest moment va passar una cosa semblant. De sobte, el sistema d'entrades va començar a llançar errors. El personal va sospirar i va agafar els bitllets de paper, i en James es va afanyar a la sala de servidors. Tot semblava bé amb el servidor.
Llavors va entrar un dels empleats.
— El sistema torna a funcionar.
James estava desconcertat perquè no havia fet res. Més precisament, res que faci funcionar el sistema. Va tancar la sessió, va agafar el telèfon i va trucar a la línia d'assistència de la seva empresa. Aviat el mateix empleat va entrar a la sala de servidors.
- El sistema està caigut.
James va mirar el servidor. Un patró interessant i familiar de formes multicolors ballava a la pantalla: canonades que es retorcen i s'entrellacen caòticament. Tots hem vist aquest salvapantalles en algun moment. Va ser molt ben representat i literalment hipnotitzant.
James va prémer un botó i el patró va desaparèixer. Es va afanyar a la taquilla i de camí es va trobar amb un empleat que tornava a ell.
— El sistema torna a funcionar.
Si pots fer un facepalm mental, això és exactament el que va fer James. Salvapantalles. Utilitza OpenGL. I per tant, durant el funcionament, consumeix tots els recursos del processador del servidor. Com a resultat, cada trucada al servidor acaba amb un temps d'espera.
James va tornar a la sala de servidors, va iniciar sessió i va substituir l'estalvi de pantalla amb les belles canonades amb una pantalla en blanc. És a dir, en lloc d'un salvapantalles que consumeix el 100% dels recursos del processador, n'he instal·lat un altre que no consumeix recursos. Llavors vaig esperar 10 minuts per comprovar la meva suposició.
Quan James va arribar al següent cinema, es preguntava com explicar al seu gerent que acabava de volar 800 km per apagar l'estalvi de pantalla.
Accident durant una determinada fase de la lluna
Història real. Un dia va sorgir un error de programari que depenia de la fase de la lluna. Hi havia una petita rutina que s'utilitzava habitualment en diversos programes del MIT per calcular l'aproximació a la fase real de la Lluna. GLS va incorporar aquesta rutina en un programa LISP que, en escriure un fitxer, generaria una línia amb una marca de temps de gairebé 80 caràcters. Era molt estrany que la primera línia d'un missatge acabés sent massa llarga i conduís a la següent línia. I quan més tard el programa va llegir aquest fitxer, va maleir. La longitud de la primera línia depenia de la data i l'hora exactes, així com de la durada de l'especificació de la fase en el moment en què es va imprimir la marca de temps. És a dir, l'error depenia literalment de la fase de la lluna!
Primera edició en paper (Steele-1983) incloïa un exemple d'aquesta línia que va conduir a l'error descrit, però la tipografia el va "arreglar". Des de llavors, això s'ha descrit com un "error de fase lunar".
Tanmateix, aneu amb compte amb les suposicions. Fa uns anys, enginyers del CERN (Centre Europeu d'Investigació Nuclear) van trobar errors en experiments realitzats al Gran Col·lisionador Electron-Positron. Com que els ordinadors processen activament l'enorme quantitat de dades generades per aquest dispositiu abans de mostrar el resultat als científics, molts van especular que el programari era d'alguna manera sensible a la fase de la lluna. Diversos enginyers desesperats van arribar al fons de la veritat. L'error va sorgir a causa d'un lleuger canvi en la geometria de l'anell de 27 km de llarg a causa de la deformació de la Terra durant el pas de la Lluna! Aquesta història ha entrat al folklore de la física com "La venjança de Newton sobre la física de partícules" i un exemple de la connexió entre les lleis més simples i antigues de la física i els conceptes científics més avançats.
L'arrencada del vàter atura el tren
El millor error de maquinari del que he sentit mai va ser en un tren d'alta velocitat a França. L'error va provocar una frenada d'emergència del tren, però només si hi havia passatgers a bord. En cada cas, el tren va ser deixat de servei, revisat, però no es va trobar res. Llavors el van enviar de nou a la línia i immediatament es va aturar.
Durant una de les comprovacions, un enginyer que viatjava al tren va anar al lavabo. Aviat es va rentar, BOOM! Parada d'emergència.
L'enginyer es va posar en contacte amb el conductor i li va preguntar:
— Què feies just abans de frenar?
- Bé, he baixat la velocitat en la baixada...
Això era estrany, perquè durant el funcionament normal el tren frena en baixades desenes de vegades. El tren va avançar, i en la següent baixada el conductor va advertir:
- Vaig a reduir la velocitat.
No ha passat res.
— Què vas fer durant l'última frenada? - va preguntar el conductor.
- Bé... estava al lavabo...
- Bé, doncs vés al lavabo i fes el que has fet quan tornem a baixar!
L'enginyer va anar al lavabo i, quan el conductor va avisar: "Estic alentint", va rentar l'aigua. Per descomptat, el tren es va aturar immediatament.
Ara podien reproduir el problema i necessitaven trobar-ne la causa.
Al cap de dos minuts, es van adonar que el cable de comandament a distància del fre del motor (el tren tenia un motor a cada extrem) estava desconnectat de la paret de l'armari elèctric i estava estirat sobre el relé que controlava el solenoide de l'endoll del vàter... Quan el relé estava activat, va crear interferències en el cable del fre i la protecció del sistema contra fallades simplement incloïa la frenada d'emergència.
La porta d'entrada que odiava FORTRAN
Fa uns mesos ens vam adonar que les connexions de xarxa al continent [això era a Hawaii] s'estaven fent molt, molt lentes. Això podria durar entre 10 i 15 minuts i de sobte tornar a passar. Després d'un temps, el meu company es va queixar que les connexions de xarxa al continent en general no funciona. Tenia algun codi FORTRAN que s'havia de copiar a una màquina del continent, però no va poder perquè "la xarxa no va aguantar prou per completar la càrrega FTP".
Sí, va resultar que es van produir errors de xarxa quan un company va intentar fer FTP un fitxer amb codi font a FORTRAN a una màquina del continent. Vam intentar arxivar el fitxer: després es va copiar sense problemes (però la màquina de destinació no tenia un descomprimidor, de manera que el problema no es va resoldre). Finalment, vam "dividir" el codi FORTRAN en trossos molt petits i els vam enviar d'un en un. La majoria dels fragments es van copiar sense problemes, però algunes peces no van passar, o van passar després nombrosos intents.
Quan vam examinar els passatges problemàtics, vam descobrir que tenien alguna cosa en comú: tots contenien blocs de comentaris que començaven i acabaven amb línies formades per C majúscula (com va preferir comentar un company a FORTRAN). Vam enviar un correu electrònic a experts en xarxes del continent i vam demanar ajuda. Per descomptat, volien veure mostres dels nostres fitxers que no es podien transferir per FTP... però les nostres cartes no els van arribar. Finalment ens va ocórrer un senzill descriurecom són els fitxers intransferibles. Va funcionar :) [M'atreveixo a afegir un exemple d'un dels comentaris problemàtics de FORTRAN aquí? Probablement no val la pena!]
Al final vam aconseguir esbrinar-ho. Recentment s'ha instal·lat una nova passarel·la entre la nostra part del campus i la xarxa continental. Va tenir ENORMES dificultats per transmetre paquets que contenien fragments repetits de C majúscula! Només alguns d'aquests paquets podrien ocupar tots els recursos de la passarel·la i evitar que la majoria dels altres paquets passin. Ens vam queixar al fabricant de la passarel·la... i ens van respondre: "Oh, sí, t'enfrontes a un error de C repetit! Ja sabem d'ell". Finalment vam resoldre el problema comprant una nova passarel·la d'un altre fabricant (en defensa del primer, la incapacitat de transferir programes FORTRAN pot ser un avantatge per a alguns!).
Temps difícils
Fa uns anys, mentre treballava en la creació d'un sistema ETL en Perl per reduir els costos dels assaigs clínics de fase 40, vaig necessitar processar unes 000 dates. Dos d'ells no van superar la prova. Això no em va molestar massa perquè aquestes dates s'han extret de dades proporcionades pel client que sovint, diguem-ne, sorprèn. Però quan vaig comprovar les dades originals, va resultar que aquestes dates eren l'1 de gener de 2011 i l'1 de gener de 2007. Vaig pensar que l'error estava contingut al programa que acabo d'escriure, però va resultar que ja feia 30 anys. vell. Això pot semblar misteriós per a aquells que no estiguin familiaritzats amb l'ecosistema del programari. A causa de la decisió de llarga durada d'una altra empresa de guanyar diners, el meu client em va pagar per corregir un error que una empresa havia introduït per accident i l'altra a propòsit. Perquè entengueu de què parlo, he de parlar de l'empresa que va afegir la funció que va acabar convertint-se en un error, així com d'altres esdeveniments interessants que van contribuir al misteriós error que vaig solucionar.
En els bons vells temps, els ordinadors d'Apple de vegades es reiniciaven espontàniament la seva data a l'1 de gener de 1904. El motiu era senzill: utilitzava un "rellotge del sistema" alimentat per bateria per fer un seguiment de la data i l'hora. Què va passar quan es va acabar la bateria? Els ordinadors van començar a rastrejar la data pel nombre de segons des del començament d'una època. Per època ens referim a la data original de referència, i per als Macintoshs era l'1 de gener de 1904. I després de la mort de la bateria, la data actual es va restablir a la especificada. Però per què va passar això?
Anteriorment, Apple utilitzava 32 bits per emmagatzemar el nombre de segons des de la data original. Un bit pot emmagatzemar un dels dos valors: 1 o 0. Dos bits poden emmagatzemar un dels quatre valors: 00, 01, 10, 11. Tres bits: un valor de vuit: 000, 001, 010, 011, 100 , 101, 110, 111, etc. I 32 podria emmagatzemar un dels 232 valors, és a dir, 4 segons. Per a les dates d'Apple, això equival a uns 294 anys, de manera que els Mac més antics no poden gestionar les dates posteriors al 967. I si la bateria del sistema s'esgota, la data es restableix a 296 segons des de l'inici de l'època, i cal configurar-la manualment cada vegada que engegueu l'ordinador (o fins que compreu una bateria nova).
Tanmateix, la decisió d'Apple d'emmagatzemar les dates com a segons des de l'època va fer que no poguéssim gestionar les dates anteriors a l'època, la qual cosa va tenir conseqüències de gran abast, com veurem. Apple va introduir una característica, no un error. Entre altres coses, això significava que el sistema operatiu Macintosh era immune a l'"error del mil·lenni" (que no es podia dir de moltes aplicacions de Mac que tenien els seus propis sistemes de data per eludir les restriccions).
Endavant. Vam utilitzar Lotus 1-2-3, l'"aplicació assassina" d'IBM que va ajudar a llançar la revolució dels ordinadors, tot i que els ordinadors d'Apple tenien VisiCalc, que va fer que l'ordinador personal fos un èxit. Per ser justos, si no hagués aparegut l'1-2-3, els ordinadors difícilment haurien enlairat i la història dels ordinadors personals podria haver-se desenvolupat de manera molt diferent. Lotus 1-2-3 va tractar incorrectament l'any 1900 com a any de traspàs. Quan Microsoft va llançar el seu primer full de càlcul, Multiplan, va capturar una petita part del mercat. I quan van llançar el projecte Excel, van decidir no només copiar l'esquema de noms de files i columnes del Lotus 1-2-3, sinó també garantir la compatibilitat d'errors tractant deliberadament el 1900 com un any de traspàs. Aquest problema encara existeix avui dia. Per tant, a l'1-2-3 va ser un error, però a Excel va ser una decisió conscient assegurar-se que tots els usuaris de l'1-2-3 poguessin importar les seves taules a Excel sense canviar les dades, encara que fos incorrecte.
Però hi havia un altre problema. En primer lloc, Microsoft va llançar Excel per a Macintosh, que no reconeixia dates abans de l'1 de gener de 1904. I a Excel, l'1 de gener de 1900 es va considerar l'inici de l'era. Per tant, els desenvolupadors van fer un canvi perquè el seu programa reconegués el tipus d'època i emmagatzemés les dades en si mateix d'acord amb l'època desitjada. Microsoft fins i tot va escriure un article explicatiu sobre això. I aquesta decisió va provocar el meu error.
El meu sistema ETL va rebre fulls de càlcul Excel de clients que es van crear a Windows, però també es van poder crear en un Mac. Per tant, l'inici de l'era a la taula podria ser l'1 de gener de 1900 o l'1 de gener de 1904. Com esbrinar? El format de fitxer d'Excel mostra la informació necessària, però l'analitzador que vaig utilitzar no la mostrava (ara sí) i suposava que coneixeu l'època d'una taula específica. Probablement hauria pogut passar més temps entenent el format binari d'Excel i enviant un pedaç a l'autor de l'analitzador, però tenia molt més a fer pel client, així que ràpidament vaig escriure una heurística per determinar l'època. Era senzilla.
A Excel, la data del 5 de juliol de 1998 es pot representar en el format "07-05-98" (sistema americà inútil), "5 de juliol de 98", "5 de juliol de 1998", "5-jul-98" o algun altre format, un altre format inútil (irònicament, un dels formats que no oferia la meva versió d'Excel era ISO 8601). Tanmateix, dins de la taula, la data sense format es va emmagatzemar com a "35981" per a l'època-1900 o "34519" per a l'època-1904 (els números representen el nombre de dies des de l'època). Simplement vaig utilitzar un analitzador senzill per extreure l'any de la data amb format i després vaig utilitzar l'analitzador d'Excel per extreure l'any de la data sense format. Si els dos valors difereixen en 4 anys, llavors sabia que estava utilitzant un sistema amb l'època-1904.
Per què no he fet servir només dates amb format? Perquè el 5 de juliol de 1998 es pot formatar com a "juliol 98" amb el dia del mes perdut. Vam rebre taules de tantes empreses que les van crear de tantes maneres diferents que va ser a nosaltres (en aquest cas, a mi) esbrinar les dates. A més, si Excel ho fa bé, nosaltres també ho hauríem de fer!
Al mateix temps, em vaig trobar amb 39082. Permeteu-me recordar que el Lotus 1-2-3 considerava el 1900 un any de traspàs, i això es va repetir fidelment a Excel. I com que això va afegir un dia a l'any 1900, moltes funcions de càlcul de dates podrien estar equivocades per a aquell mateix dia. És a dir, 39082 podria haver estat l'1 de gener de 2011 (en Mac) o el 31 de desembre de 2006 (en Windows). Si el meu "analitzador d'anys" va extreure l'any 2011 del valor format, aleshores tot està bé. Però com que l'analitzador d'Excel no sap quina època s'utilitza, per defecte és època-1900, tornant l'any 2006. La meva aplicació va veure que la diferència era de 5 anys, ho va considerar un error, la va registrar i va retornar un valor sense format.
Per evitar-ho, vaig escriure això (pseudocodi):
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
I llavors les 40 dates es van analitzar correctament.
Enmig de treballs d'impressió gran
A principis dels anys vuitanta, el meu pare va treballar a Storage Technology, una divisió desapareguda que va crear unitats de cinta i sistemes pneumàtics per a l'alimentació de cintes d'alta velocitat.
Van redissenyar les unitats perquè poguessin tenir una unitat central "A" connectada a set unitats "B", i el petit sistema operatiu de la memòria RAM que controlava la unitat "A" podia delegar les operacions de lectura i escriptura a totes les unitats "B".
Cada vegada que s'iniciava la unitat “A”, calia inserir un disquet a la unitat perifèrica connectada a “A” per carregar el sistema operatiu a la seva memòria. Era extremadament primitiu: la potència de càlcul la proporcionava un microcontrolador de 8 bits.
El públic objectiu d'aquests equips eren empreses amb magatzems de dades molt grans -bancs, cadenes de comerços, etc.- que necessitaven imprimir moltes etiquetes d'adreces o extractes bancaris.
Un client va tenir un problema. Enmig d'un treball d'impressió, una unitat en particular "A" podria deixar de funcionar, fent que tot el treball s'atura. Per restaurar el funcionament de la unitat, el personal va haver de reiniciar-ho tot. I si això passava enmig d'una tasca de sis hores, es va perdre una gran quantitat de temps d'ordinador car i es va interrompre el calendari de tota l'operació.
Es van enviar tècnics de Storage Technologies. Però malgrat els seus millors esforços, no van poder reproduir l'error en condicions de prova: semblava que es produïa enmig de treballs d'impressió gran. El problema no era el maquinari, van substituir tot el que podien: RAM, microcontrolador, disquetera, totes les parts imaginables de la unitat de cinta; el problema va persistir.
Aleshores els tècnics van trucar a la seu i van trucar al Perit.
L'expert va agafar una cadira i una tassa de cafè, es va asseure a l'aula d'informàtica —en aquells dies hi havia sales dedicades als ordinadors— i va veure com el personal feia cua un treball d'impressió gran. L'expert estava esperant que es produís una fallada, i ho va fer. Tothom va mirar l'expert, però no tenia ni idea de per què va passar això. Així que va ordenar que la feina tornés a fer cua, i tot el personal i tècnics van tornar a treballar.
L'expert es va tornar a asseure a la cadira i va començar a esperar un fracàs. Van passar unes sis hores i es va produir el fracàs. L'Expert de nou no tenia idees, excepte que tot passava en una sala plena de gent. Va ordenar que es reiniciés la missió, va tornar a seure i va esperar.
A la tercera fallada, l'expert es va adonar d'alguna cosa. La fallada es va produir quan el personal va canviar les cintes d'una unitat externa. A més, la fallada es va produir tan bon punt un dels empleats va passar per una determinada rajola del terra.
El terra elevat estava fet de rajoles d'alumini col·locades a una alçada de 6 a 8 polzades. Nombrosos cables dels ordinadors passaven sota el terra elevat per evitar que algú trepitgés accidentalment un cable important. Les rajoles es van col·locar molt ajustades per evitar que els residus entrin sota el terra elevat.
L'expert es va adonar que una de les rajoles estava deformada. Quan un empleat trepitjava la seva cantonada, les vores de la rajola es fregaven contra les rajoles adjacents. Les peces de plàstic que connectaven les rajoles també es fregaven amb elles, cosa que provocava microdescàrregues estàtiques que creaven interferències de radiofreqüència.
Avui dia, la memòria RAM està molt millor protegida de les interferències de radiofreqüència. Però en aquells anys això no era així. L'expert es va adonar que aquesta interferència alterava la memòria i, amb ella, el funcionament del sistema operatiu. Va trucar al servei d'assistència, va demanar rajoles noves, les va instal·lar ell mateix i el problema va desaparèixer.
És la marea alta!
La història va tenir lloc en una sala de servidors, al quart o cinquè pis d'una oficina de Portsmouth (crec), a la zona dels molls.
Un dia es va estavellar el servidor Unix amb la base de dades principal. El van reiniciar, però feliçment va continuar caient una i altra vegada. Vam decidir trucar a algú del servei d'assistència.
El tipus de suport... Crec que es deia Mark, però això no importa... No crec que el conegui. No importa, realment. Quedem-nos amb Mark, d'acord? Genial.
Així, unes hores més tard va arribar en Mark (no hi ha gaire camí de Leeds a Portsmouth, ja ho saps), va encendre el servidor i tot va funcionar sense problemes. Maleït suport típic, el client s'enfada molt. En Mark mira els fitxers de registre i no troba res inconvenient. Així que Mark torna a pujar al tren (o sigui quin sigui el mitjà de transport en què hagi arribat, podria haver estat una vaca coixa pel que sé... de totes maneres, no importa, d'acord?) i torna a Leeds, després d'haver perdut. el dia.
Aquell mateix vespre el servidor torna a fallar. La història és la mateixa... el servidor no s'aixeca. Mark intenta ajudar de manera remota, però el client no pot iniciar el servidor.
Un altre tren, autobús, merenga de llimona o alguna altra merda, i Mark torna a Portsmouth. Mira, el servidor arrenca sense cap problema! Miracle. Mark passa diverses hores comprovant que tot està en ordre amb el sistema operatiu o el programari i marxa cap a Leeds.
Al voltant de la meitat del dia, el servidor es bloqueja (preneu-ho amb calma!). Aquesta vegada sembla raonable portar a gent de suport de maquinari per substituir el servidor. Però no, després d'unes 10 hores també cau.
La situació es va repetir durant diversos dies. El servidor funciona, es bloqueja després d'unes 10 hores i no s'inicia durant les properes 2 hores. Van comprovar la refrigeració, les fuites de memòria, ho van comprovar tot, però no van trobar res. Llavors es van aturar els xocs.
La setmana va passar despreocupada... tothom estava content. Feliç fins que tot torni a començar. La imatge és la mateixa. 10 hores de treball, 2-3 hores d'inactivitat...
I llavors algú (crec que em van dir que aquesta persona no tenia res a veure amb IT) va dir:
"És la marea!"
L'exclamació es va rebre amb mirades en blanc i la mà d'algú probablement va dubtar al botó de trucada de seguretat.
"Deixa de funcionar amb la marea".
Sembla ser un concepte completament aliè per als treballadors de suport informàtic, que és poc probable que llegiu l'Anuari Tide mentre s'asseuen a prendre un cafè. Explicaven que això no es podia relacionar de cap manera amb la marea, perquè el servidor portava una setmana treballant sense fallades.
"La setmana passada la marea va ser baixa, però aquesta setmana és alta".
Una mica de terminologia per a aquells que no tenen llicència de iot. Les marees depenen del cicle lunar. I a mesura que la Terra gira, cada 12,5 hores l'atracció gravitatòria del Sol i la Lluna crea una marejada. A l'inici del cicle de 12,5 hores hi ha la marea alta, a la meitat del cicle hi ha un reflux, i al final torna a tornar a estar alta. Però a mesura que l'òrbita de la lluna canvia, també ho fa la diferència entre la marea baixa i la marea alta. Quan la Lluna es troba entre el Sol i la Terra o al costat oposat de la Terra (lluna plena o sense lluna), obtenim les marees Syzygyn: les marees altes més altes i les marees baixes més baixes. A mitja lluna obtenim marees en quadratura, les marees més baixes. La diferència entre els dos extrems disminueix molt. El cicle lunar dura 28 dies: sizigi - quadratura - sizigi - quadratura.
Quan els tècnics van explicar l'essència de les forces de marea, de seguida van pensar que calia trucar a la policia. I força lògic. Però resulta que el noi tenia raó. Dues setmanes abans, un destructor va amarrar no gaire lluny de l'oficina. Cada vegada que la marea l'elevava a una certa alçada, el pal de radar de la nau acabava al nivell del pis de la sala de servidors. I el radar (o equip de guerra electrònica, o alguna altra joguina militar) va crear un caos als ordinadors.
Missió de vol per al coet
Vaig tenir l'encàrrec de portar un sistema de control i supervisió de llançament de coets gran (unes 400 mil línies) a noves versions del sistema operatiu, compilador i llenguatge. Més precisament, des de Solaris 2.5.1 fins a Solaris 7, i des del Verdix Ada Development System (VADS), escrit en Ada 83, fins al sistema Rational Apex Ada, escrit en Ada 95. VADS va ser comprat per Rational i el seu producte va ser obsolet, tot i que Rational va intentar implementar versions compatibles de paquets específics de VADS per facilitar la transició al compilador Apex.
Tres persones em van ajudar a compilar el codi de manera neta. Va trigar dues setmanes. I després vaig treballar pel meu compte perquè el sistema funcionés. En resum, va ser la pitjor arquitectura i implementació d'un sistema de programari que m'havia trobat, així que vaig trigar dos mesos més a completar el port. Aleshores, el sistema es va presentar a prova, que va trigar uns quants mesos més. Immediatament vaig corregir els errors que es van trobar durant les proves, però el seu nombre va disminuir ràpidament (el codi font era un sistema de producció, de manera que la seva funcionalitat funcionava de manera bastant fiable, només vaig haver d'eliminar els errors que van sorgir durant l'adaptació al nou compilador). Finalment, quan tot funcionava com calia, em van traslladar a un altre projecte.
I el divendres abans de l'Acció de Gràcies, va sonar el telèfon.
El llançament del coet s'havia de provar en unes tres setmanes i durant les proves de laboratori del compte enrere, la seqüència d'ordres es va bloquejar. A la vida real, això avortaria la prova, i si el bloqueig es produïa als pocs segons d'engegar el motor, es produirien diverses accions irreversibles en els sistemes auxiliars, que requeririen una llarga -i costosa - preparació del coet. No hauria començat, però molta gent hauria estat molt molesta per la pèrdua de temps i molts, molts diners. No deixeu que ningú us digui que el Departament de Defensa gasta diners de manera temerària: mai he conegut cap director de contractació que no hagi posat el pressupost en primer lloc o en segon lloc, seguit d'un calendari.
Els mesos anteriors, aquest repte de compte enrere s'havia executat centenars de vegades en moltes variacions, amb només uns quants singlots menors. Així doncs, la probabilitat que això succeís era molt baixa, però les seves conseqüències eren molt importants. Multipliqui aquests dos factors i entendrà que la notícia va predir una setmana de vacances arruïnada per a mi i desenes d'enginyers i directius.
I es va prestar atenció a mi com a persona que portava el sistema.
Com passa amb la majoria de sistemes crítics per a la seguretat, es van registrar molts paràmetres, de manera que va ser bastant fàcil identificar les poques línies de codi que s'executaven abans que el sistema s'estavellés. I, per descomptat, no hi havia absolutament res inusual en ells; les mateixes expressions s'havien executat amb èxit literalment milers de vegades durant la mateixa execució.
Vam cridar a la gent d'Apex a Rational perquè van ser ells els que van desenvolupar el compilador i algunes de les rutines que van desenvolupar es van anomenar al codi sospitós. Ells (i tots els altres) estaven impressionats que hi havia la necessitat d'arribar a l'arrel d'un problema d'importància literalment nacional.
Com que no hi havia res interessant a les revistes, vam decidir intentar reproduir el problema en un laboratori local. No va ser una tasca fàcil, ja que l'esdeveniment es va produir aproximadament una vegada per cada 1000 carreres. Un motiu sospitós era que una trucada a una funció mutex desenvolupada pel proveïdor (part del paquet de migració VADS) Unlock no va portar al desbloqueig. El fil de processament que va anomenar la funció processava missatges de batecs, que nominalment arribaven cada segon. Vam augmentar la freqüència a 10 Hz, és a dir, 10 vegades per segon, i vam començar a córrer. Aproximadament una hora més tard, el sistema es va bloquejar. Al registre, vam veure que la seqüència de missatges gravats era la mateixa que durant la prova fallida. Vam fer diverses tirades més, el sistema es va bloquejar constantment 45-90 minuts després de l'inici i cada vegada el registre contenia la mateixa ruta. Tot i que tècnicament estàvem executant un codi diferent (la freqüència del missatge era diferent), el comportament del sistema era el mateix, així que estàvem segurs que aquest escenari de càrrega estava causant el mateix problema.
Ara calia esbrinar on es va produir exactament el bloqueig en la seqüència d'expressions.
Aquesta implementació del sistema utilitzava el sistema de tasques Ada i el feia servir increïblement malament. Les tasques són una construcció executable simultàniament d'alt nivell a Ada, una cosa semblant a fils d'execució, només incorporada al llenguatge mateix. Quan s'han de comunicar dues tasques, "estableixen una cita", intercanvien les dades necessàries i després aturen la cita i tornen a les seves execucions independents. Tanmateix, el sistema es va implementar de manera diferent. Després que una tasca objectiu es trobava, aquesta tasca objectiu es trobava amb una altra tasca, que després es trobava amb una tercera tasca, i així successivament fins que es va completar algun processament. Després d'això, totes aquestes trobades es van completar i cada tasca havia de tornar a la seva execució. És a dir, estàvem tractant amb el sistema de trucades de funcions més car del món, que va aturar tot el procés de "multitasking" mentre processava part de les dades d'entrada. I abans això no comportava problemes només perquè el rendiment era molt baix.
Vaig descriure aquest mecanisme de tasca perquè quan es demanava o s'esperava que es completés una cita, es podia produir un "canvi de tasca". És a dir, el processador podria començar a processar una altra tasca que estigui llesta per ser executada. Resulta que quan una tasca està preparada per trobar-se amb una altra, es pot començar a executar una tasca completament diferent i, finalment, el control torna a la primera cita. I es poden produir altres esdeveniments que fan que la tasca canviï; un d'aquests esdeveniments és una trucada a una funció del sistema, com ara imprimir o executar un mutex.
Per entendre quina línia de codi causava el problema, necessitava trobar una manera d'enregistrar el progrés a través d'una seqüència d'instruccions sense activar un canvi de tasca, que evitaria que es produís un error. Així que no vaig poder aprofitar Put_Line()per evitar realitzar operacions d'E/S. Podria establir una variable de comptador o alguna cosa semblant, però com puc veure el seu valor si no el puc mostrar a la pantalla?
A més, en examinar el registre, va resultar que, malgrat el processament dels missatges de batecs penjats, que bloquejava totes les operacions d'E/S del procés i impedia que es realissin altres processaments, es continuaven executant altres tasques independents. És a dir, el treball no estava totalment bloquejat, només una cadena (crítica) de tasques.
Aquesta va ser la pista necessària per avaluar l'expressió de bloqueig.
Vaig fer un paquet Ada que contenia una tasca, un tipus enumerat i una variable global d'aquest tipus. Nombres literals estaven lligats a expressions específiques de la seqüència problemàtica (p. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), i després hi va inserir expressions d'assignació que assignaven l'enumeració corresponent a una variable global. Com que el codi objecte de tot això simplement emmagatzemava una constant a la memòria, el canvi de tasca com a resultat de la seva execució era extremadament poc probable. Sospitàvem principalment de les expressions que podien canviar la tasca, ja que el bloqueig es va produir en l'execució en lloc de tornar quan es tornava a canviar la tasca (per diversos motius).
La tasca de seguiment simplement es va executar en bucle i es va comprovar periòdicament si el valor de la variable global havia canviat. Amb cada canvi, el valor es desava en un fitxer. Després una breu espera i un nou control. Vaig escriure la variable al fitxer perquè la tasca només es va executar quan el sistema la va seleccionar per a l'execució en canviar la tasca a l'àrea del problema. El que passés en aquesta tasca no afectaria altres tasques bloquejades no relacionades.
S'esperava que quan el sistema arribés al punt d'executar el codi problemàtic, la variable global es restabliria en passar a cada expressió següent. Aleshores passarà alguna cosa que farà que la tasca canviï, i com que la seva freqüència d'execució (10 Hz) és inferior a la de la tasca de monitorització, el monitor podria capturar el valor de la variable global i escriure'l. En una situació normal, podria obtenir una seqüència repetida d'un subconjunt d'enumeracions: els últims valors de la variable en el moment del canvi de tasca. Quan es penja, la variable global ja no hauria de canviar i l'últim valor escrit indicarà quina expressió no s'ha completat.
Vaig executar el codi amb seguiment. Es va congelar. I el seguiment funcionava com un rellotge.
El registre contenia la seqüència esperada, que es va interrompre per un valor que indicava que s'havia cridat un mutex Unlock, i la tasca no s'ha completat, com és el cas de milers de trucades anteriors.
Els enginyers d'Apex estaven analitzant febrilment el seu codi en aquest moment i van trobar un lloc al mutex on, teòricament, es podria produir un bloqueig. Però la seva probabilitat era molt baixa, ja que només una determinada seqüència d'esdeveniments ocorreguts en un moment determinat podia provocar un bloqueig. La llei de Murphy, nois, és la llei de Murphy.
Per protegir la peça de codi que necessitava, vaig substituir les trucades a la funció mutex (creades a la part superior de la funcionalitat mutex del sistema operatiu) per un petit paquet nadiu d'Ada mutex per controlar l'accés mutex a aquesta peça.
El vaig inserir al codi i vaig fer la prova. Set hores més tard, el codi encara funcionava.
El meu codi es va enviar a Rational, on el van compilar, el van desmuntar i van comprovar que no utilitzava el mateix enfocament que s'utilitzava a les funcions mutex problemàtiques.
Aquesta va ser la revisió de codi més concorreguda de la meva carrera 🙂 Hi havia uns deu enginyers i gestors a la sala amb mi, altres deu persones estaven en una conferència telefònica i tots van examinar unes 20 línies de codi.
Es va revisar el codi, es van reunir nous fitxers executables i es van enviar per a proves de regressió formals. Un parell de setmanes després, la prova del compte enrere va tenir èxit i el coet va enlairar.
D'acord, tot està bé, però quin sentit té la història?
Va ser un problema absolutament repugnant. Centenars de milers de línies de codi, execució paral·lela, més d'una dotzena de processos interactius, arquitectura deficient i implementació deficient, interfícies per a sistemes encastats i milions de dòlars gastats. Sense pressió, oi.
No era l'únic que treballava en aquest problema, tot i que estava en el punt de mira mentre feia la portabilitat. Però tot i que ho vaig fer, això no vol dir que hagués entès tots els centenars de milers de línies de codi, ni tan sols les vaig descremar. El codi i els registres van ser analitzats per enginyers de tot el país, però quan em van explicar les seves hipòtesis sobre les causes de la fallada, només vaig trigar mig minut a refutar-les. I quan em demanaven que analitzés teories, ho passava a algú més, perquè era obvi per a mi que aquests enginyers anaven pel camí equivocat. Sona presumptuós? Sí, això és cert, però vaig rebutjar les hipòtesis i peticions per un altre motiu.
Vaig entendre la naturalesa del problema. No sabia exactament on passava ni per què, però sabia què estava passant.
Al llarg dels anys, he acumulat molts coneixements i experiència. Vaig ser un dels pioners a utilitzar Ada i vaig entendre els seus avantatges i inconvenients. Sé com les biblioteques d'execució d'Ada gestionen les tasques i s'ocupen de l'execució paral·lela. I entenc la programació de baix nivell a nivell de memòria, registres i assemblador. En altres paraules, tinc un coneixement profund en el meu camp. I els vaig utilitzar per trobar la causa del problema. No només vaig solucionar l'error, sinó que vaig entendre com trobar-lo en un entorn d'execució molt sensible.
Aquestes històries de lluita amb el codi no són gaire interessants per a aquells que no estan familiaritzats amb les característiques i condicions d'aquesta lluita. Però aquestes històries ens ajuden a entendre què cal per resoldre problemes realment difícils.
Per resoldre problemes realment difícils, cal ser més que un programador. Heu d'entendre el "destí" del codi, com interactua amb el seu entorn i com funciona el propi entorn.
I llavors tindreu la vostra pròpia setmana de vacances en ruïnes.
Continuar.
Font: www.habr.com