El fallo informatico mas dificil del mundo

En un foro de una importante página de programadores informáticos, se debatía sobre cuál era el fallo de programación (bug) más difícil de encontrar que uno se había encontrado a lo largo de su vida.

El sistema permitía la votación de las respuestas, con lo que al mismo tiempo tenía un valor de encuesta. El error que ocupaba el primer puesto era el siguiente:

Esto no me ocurrió a mi personalmente, me lo contó un amigo:

Estaba tratando de corregir un error en un programa que ocurría sólo excepcionalmente. Acabaron acotándolo: El fallo sólo ocurría en miércoles (Wednesday), sólo en septiembre (September) y a partir del día 9. Es decir, 362 días al año, el programa funcionaba correctamente, pero había tres en que se producía un error muy grave que lo terminaba de inmediato.

La causa del error era puramente alfabética. La definición de las fechas era en la forma “Lunes, 4 Mayo 2009”. Esto funcionaba en todo los casos salvo para esos fatídicos Miércoles de Septiembre.

El motivo del error era la funesta combinación: September es el mes con más letras de todo el año, en inglés. Wednesday es el día de la semana con más letras de todo el año. Justo la combinación de ellos y las dos cifras del día del mes tenían el tamaño máximo posible en el idioma inglés y la persona que lo había diseñado había usado justo un carácter menos de los necesarios: Wednesday, September 22 2008, tiene 28 caracteres, algo que sólo ocurre en los últimos miércoles de Septiembre.

17 comentarios en «El fallo informatico mas dificil del mundo»

  1. Voy a quedar como un flipado, pero para una vez que me pasa no lo voy a desaprovechar. Te aseguro que según he leído los síntomas del error (sin haber leído sobre el tema nunca) he tenido clarísimo el diagnóstico de lo que estaba pasando.

  2. Hugo, yo te creo: has leído el enunciado y has supuesto la solución.

    En mi experiencia, cuando se busca la solución a un problema informático, se gasta mucho más tiempo en acotarlo que en encontrar la solución una vez acotado. No sé si en este caso era muy obvio que la cosa sucedía en los 3 últimos miércoles de septiembre : a lo mejor era un proceso diario, a lo mejor tenían datos de varios años en los que ese patrón se repetía.

    Pero me da que lo más complicado de todo fue deducir que aquello sucedía en los 3 últimos miércoles del mes de septiembre … exclusivamente :)

    Anyway, buen ojo

  3. A mí me pasó algo tambien extraño que hasta que dí con el problema estaba medio loco.

    El ordenador se reseteaba de vez en cuando hasta que descubrí que lo hacia cuando mostraba imagenes grandes que cubrian la pantalla. Lo que ocurria es que algunas imagenes hacian que se resetease y otras no.

    Cogí el paint y me puse a pintar y resulta que cuando pintaba algo en rojo y era relativamente grande (un cuadrado o circulo), zás… se reseteaba!!! sólo ocurria con ese color!!!

    Resultó ser la tarjeta gráfica, el chip que se encarga de generar los colores y era la parte del rojo la que cascaba….

    Al menos fué curioso

  4. Hombre, no dudo que encontrar el bug le costara trabajo…

    Pero no comprobar el tamaño de un buffer con respecto al tamaño máximo de la posible entrada, eso es lo que tiene delito.

    De todas maneras, a veces la dificultad no está tanto en la complejidad del error como en la capacidad de percepción humana. Recuerdo una vez que una compañera llevaba un buen rato intentando comprender qué le fallaba en la siguiente línea:

    fprintf(stdin, “%s\n”, buffer);

    Me dijo: ¡Míralo porfa, porque me estoy volviendo loca!

    Cuando se lo dije, se puso hasta colorada… estas cosas pasan!!

  5. A mí me parece más difícil este otro:

    En un proceso dado, había algunas variables:

    int a, b, *c;

    y en un momento dado…

    b = a/*c;

    c había sido instanciada con malloc, por lo que no era problema de memoria… no recuerdo siquiera si compilaba. El tema es que el fallo al final era que en la línea “b=a/*c;”, la parte “/*” la tomaba como comienzo de comentario… y de aquella, los editores no coloreaban los comentarios como ahora (eran terminales vt320 de fósforo verde :oP)

    Ese error sí que molaba xDDD. Te sientes bastante idiota cuando te enteras.

  6. Le gano lejos a este tonto que no calculó el tamaño máximo de la posible fecha:
    Un punto extra en medio de una sentencia Cobol provocó -ayudado por otro fallo en el compilador, que no reportó el error- que cada vez que el programa llegaba a ese punto se desviaba a una dirección de memoria no especificada (parecía aleatoria: en realidad “basura” dejada por algún programa anterior). Indescifrable para todos. Por suerte teníamos un experto capaz de leer el código máquina, pues era un Cobol muy deficiente que no ofrecía soporte extra, que localizó la zona del programa y permitió que llegáramos al fatídico punto.

  7. Otro más, en la misma GE400 (por suerte fallecida):
    Un sistema de sueldos que funcionaba correctamente un día pone en cero parte del recibo de algunos empleados. Llamamos a la empresa proveedora por ayuda -los datos se “perdían” dentro del utilitario de clasificación (Sort), y nos dijeron que era imposible, que ese error existió pero fue corregido hacía mucho. Luego reconocieron que como estábamos en la Patagonia se habían “olvidado” de nosotros. La cinta llegó por avión al día siguiente y los sueldos salieron tarde. El error dependía de alguna extraña combinación en los datos.

  8. Hugo, la descripción del problema hace que sea posible entenderlo, pero en el mundo real, antes de descubrir la causa, jamás se describiría así.

    Es como en una historia de detectives, cuando se detalla mucho cómo iba vestido un personaje, eso es porque tiene que ver en la solución del crimen, pues aquí el detalle de la fecha es lo que hace pensar “va a ser por algo de la fecha”.

    Para mi que los errores más complicados son los que jamás se resuelven. Me he topado con uno del que, tras 4 años de aparecer esporádicamente, nunca fui capaz de conocer la causa.

    Me marché de la empresa y de tiempo en tiempo preguntaba por los antiguos compañeros y por ese error. Pero al final me moriré sin saber qué era lo que ocurría.

    A veces no hay errores de programación sino bugs (errores) del propio sistema de programación que se mezclan con el código. En una versión de un lenguaje de cuyo nombre no quiero acordarme había un error al convertir en mayúsculas todas las letras de una palabra (no era capaz de hacerlo con la k, que quedaba en minúsculas). Estos errores provocan averías en los programas realmente creativas y difíciles de detectar.

  9. El fallo mas raro que dio mi pc, en nero se colgo al principio de una grabacion, lo ignore, nimimize el nero el cual estaba como cargando el cd de forma continua y abri un juego y me puse a jugar, en unos 3 min mas o menos el cd exploto dento del lector y lo digo literalmente despue del plasdfsd se escuchaban los plastiquitos dentro del lector apage el pc rapidamente quite el lector y para cuando consigui abrirlo (ya que habia quedado trabado) no encontre pedazos mas grandes que el tamaño de una uña (del pie xD) y el lector para la vasura quedo.

  10. Yo uso una base de datos access, las tablas están vinculadas de mysql a través de odbc. Cuando en un formulario de acces relleno un campo text y contiene exactamente 12 caracteres numéricos, no importa en que órden o pòsición ni cuantos alfabéticos haya da un ‘buffer underflow’ y se cierra el access. Por ejemplo “Calle de la cerca 131, teléfono 944-55-66-21” fallaría, pero “Calle de la cerca 13, telefono 944-55-66-21” no o tampoco “Calle de la cerca 131 cp:36345 telefono 944-55-66-21”. He detectado el problema y lo tengo aislado y localizado pero jamás supe la causa.

  11. Me parece ridículo, ya que es muy fácil al depurar, ver donde se produce la excepción y por qué. Esta noticia lo único que tiene es la curiosidad de que sea un fallo que solo se produce tres días al año, y de ahí la dificultad de detectar el error no por ser difícil ver por que se produce, sino porque se produce en muy raras ocasiones. Hay cientos de fallos mucho más difíciles de detectar que no producen excepciones (por eso es más difícil detectarlos) ni fallos aparentes, pero que hacen que un software se comporte de una manera no esperada. Por ejemplo, me pasó con una base de datos (Oracle) alguien desarrollo una aplicación que después de años le tocó mantener a un compañero mío. La base de datos que utilizaba contenía triggers y uno de ellos se disparaba cuando un valor llegaba a cierto número y ejecutaba unas funciones no esperadas. En una base de datos de casi tres mil tablas, a veces esto se convierte en un quebradero de cabeza, y no una ridícula excepción de tipo “out o frange”.

Los comentarios están cerrados.