El nivel 256 de Pacman (o cómo morir irradiado por una línea de código)
Hace meses tenía una de nuestras profundas conversaciones con mi compañera Alba. No recuerdo bien el tema, pero recuerdo que me contestó a una pregunta con: Error 405 (código que describe un error informático catalogado como «método no permitido»). Me hizo gracia por aquello de que a veces los humanos cometemos errores informáticos. Hoy he vuelto a rememorar esta historia mientras leía una de las muertes más estúpidas por irradiación con rayos X de la historia… también debida a un error informático.
La informática, aunque no nos guste admitirlo, domina nuestras vidas. Estamos controlados por algoritmos. Sin ellos no sabríamos qué película elegir en Netflix, ni cuándo cambiar el aceite al coche, ni cómo llegar a casa sin atascos. Sin embargo, eso significa también que los errores informáticos tienen consecuencias directas en el mundo real. A veces son leves, otras no.
Uno de los ejemplos leves es el Pacman (comecocos para los más viejunos). Si sois lo suficientemente buenos en este juego, podríais llegar hasta el nivel 256, pero os resultaría difícil pasar de él. ¿Por qué? Porque hay un fallo informático en el código. Es un fallo muy común que ocurre porque ciertas variables se almacenan en una memoria de 8 bits (1 byte), es decir, con un máximo de 28=256 registros¹. De hecho, lo que falla en el caso del Pacman es la fruta. Cuando llega al nivel 256 se piensa que es el nivel 0 (al que le corresponden 0 frutas), lo que causa un fallo en cadena que descoloca toda la pantalla. Sorprendentemente, el nivel empieza como si no hubiera pasado nada.
Sucede que, además de los videojuegos, los códigos controlan aviones, trenes, semáforos, redes de electricidad, cuentas bancarias, centrales nucleares, robots, telecomunicaciones, inversiones en bolsa… Así que los fallos de software pueden acabar costando mucho dinero (suponen un gasto del 0.6% del producto interior bruto en Estados Unidos) y, a veces, también vidas.
Uno de los ejemplos más claros de esto es el fallo ocurrido en la unidad de radioterapia del Hospital Yakima Valley de Washington. La máquina que se usaba era una Therac-25, un acelerador de electrones de hasta 25 MeV. Esta máquina permitía dos modos de funcionamiento: irradiar directamente con electrones (corrientes pequeñas de alta potencia) o con rayos X (corrientes altas utilizando los electrones contra un blanco). Por supuesto, como todos los aceleradores de partículas, el Therac-25 tenía distintas medidas de seguridad para evitar que se encendiera el haz de electrones por error.
En particular, el Therac-25 tenía una variable de control llamada Class3, que sólo debía ponerse a cero cuando todos los sistemas funcionaban correctamente. Para obligar a que se revisara el colimador y el blanco antes de la irradiación, había una rutina que se ejecutaba siempre que Class3 era diferente de 0. Y para garantizar que eso pasaba a la variable Class3 se le sumaba 1 al principio de cada bucle. El problema es que Class3, al igual que la fruta del Pacman, ¡se almacenaba en 8 bits! Cada 256 veces la variable completaba el ciclo y, de repente, marcaba cero.
El 17 de enero de 1987, el paciente que llegó al hospital debía recibir una dosis de 86 rad (rad es una unidad de dosis absorbida equivalente a 0.01 Gy y el máximo que un ser humano puede soportar es de unos 1000 rad). Cuando el paciente esperaba su tratamiento y se activaban los sistemas, Class3 completó uno de esos ciclos: «Beam ready» fue el mensaje en la consola. El operador procedió con el tratamiento, pero el paciente se quejó y dijo que había notado una quemadura. La pantalla mostraba sólo 7 rad de radiación, pero el paciente empeoró a las pocas horas. Las exposiciones con placas demostraron que en realidad estuvo expuesto a una dosis entre 8000 y 10000 rad. Murió en abril de ese mismo año².
Recuerdo a menudo en mis clases sobre radiaciones ionizantes que «un gran poder conlleva una gran responsabilidad». A partir de ahora recordaré también que ese poder puede esconderse en una mísera línea de código.
@DayInLab
¹ A este tipo de errores se les llama de desbordamiento (byte overflow, integer overflow, etc.).
² Aunque existe mucha documentación al respecto de esta historia, yo la he conocido gracias al libro Humble Pi que me regaló mi amigo David.
No hay mas que ver los accidentes de Airbus Max 737, el codigo que toma control del avion de forma erronea, sin que los pilotos puedan hacer nada por anularlo, literalmente los estrella.
Otro caso en el que el software ha jugado un papel importante, sí.
Integer overflow es cuando se sobrecarga un integer que, dependiendo del procesador será de 65536 o mayor. El caso que cuentas será un byte overflow o character overflow (que son 8 bits).
Dicho así, a lo cuñao.
Cierto. Lo he incluido en la entrada. Gracias por la corrección.
Ains, qué recuerdos, una vez tuve un problema con un desbordamiento en un array. No sé quejaba pero al de una hora o más probando la aplicación, se cerraba. Una vez encontrado el problema, después de muchas horas, nunca más me ha pasado y no por casualidad. Los tipos de datos y los arrays, suelo tener especial cuidado.
Paco,es BOEING Max 737, no Airbus.
No es Airbus. La aeronave a la que te refieres es el BOEING 737 Max
Gracias por el comentario.