EDICIóN GENERAL
497 meneos
 

El fallo informático mas difícil 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. El foro en inglés: stackoverflow.com/questions/169713/whats-the-toughest-bug-you-ever-fou

| etiquetas: fallo , informático , difícil , bug
262 235 0 K 571 mnm
262 235 0 K 571 mnm
El más raro de que me han hablado se refería a coches. El propietario del nuevo vehículo podía conducir todo el día sin problemas, pero cuando se dirigía a casa, se le paraba. Los técnicos se volvieron locos, fueron incapaces de reproducirlo... hasta que lo intentaron con el cabreado propietario a bordo y el coche se paró en la calle habitual, una y otra vez (no hacía falta que condujera) ¡Pero si se bajaba no pasaba nada! Por lo visto se trataba de unir:

-Cierto teléfono móvil obsoleto en…   » ver todo el comentario
me perdonareis, pero el segundo es muy bueno. Cada vez que entra el CEO se cuelga el software de la cámara...
el error más difícil que me tocó sufrir fue el de un complejo programa que devolvía una matriz de resultados de, supongamos, 10x20. Una vez que lo terminé, hice una pequeña función que mostraba por pantalla todos los valores. Salían todos mal, ninguno era el resultado esperado. Estuve 3 días recorriendo miles de líneas de código de complicadas ecuaciones y cálculos, chequeando que todo funcionara correctamente para al final de esos 3 días y muy enojado y agotado, descubrir que lo que estaba…   » ver todo el comentario
Wow, esa es buena ! :-)

Otro también muy bueno:

Cuando yo vendía ordenadores en una tienda, vino un cliente a comentarnos que en su ordenador recien comprado, el ratón funcionaba bien por las mañanas y por las tardes / noches, pero a mediodía dejaba de funcionarle :-|
Imaginaos la cara de pasmo. Al final resultó que el puesto de trabajo estaba debajo de una ventana que al mediodía recibía el sol de pleno. El plástico del ratón era demasiado fino, y la luz lo traspasaba ligeramente, anulando el mecanismo optomecánico del ratón :-)
#18
“Bueno, no habíamos recopilado suficientes datos como para estar seguros de lo
que estaba ocurriendo hasta ahora.” Lógico, estoy hablando con el jefe del
departamento de estadística

me parece mejor ese que el de el meneo. Por cierto el del meneo al principio pense que era ese que no se si sera leyenda urbana del servidor que se descectaba una vez a la semana a una determinada hora, se pusieron a revisar mil logs, pruebas y mas pruebas y no sabian que fallaba, y un dia que estaba el administrador en la sala de los servidores en la hora fatidica, ve como entra la señora de la limpieza, desconecta el cable de alimentacion, enchufa la aspiradora y se pone a pasarla, y el otro al lado perplejo xD
NO ES UN BUG, ES UN FEATURE :-D
Siempre recordaré un problema que tuvo mi hermano con una pareja de colegas: cuando ella encendía el ordenador, todo iba bien, pero cuando lo encendía él, tenía que darle al reset porque se colgaba nada más empezar a arrancar.

Tras echar un vistazo y pedirles a cada uno que lo encendieran, descubrió que era por el monitor (uno de 17 pulgadas, muy viejo). Ella encendía primero el monitor y luego la CPU, pero el lo hacía al revés. Cuando el monitor se encendía daba un tirón tan fuerte de corriente que, si la CPU ya estaba encendida, se colgaba.
¿Nadie conoce el del Coche de Chocolate? Pues lo cuento:

Un hombre que acababa de comprar un coche nuevo (no recuerdo de qué casa) se quejó al servicio técnico de que cuando salía de cierta tienda de comprar helado el coche no arrancaba... pero sólo si el helado era de chocolate. Si el helado era de cualquier otro sabor el coche funcionaba sin problemas. Como es lógico, en el taller se lo tomaron a cachondeo, hasta que después de muuuchas quejas la casa de coches le envió a un técnico. El…   » ver todo el comentario
#13 #14 "Yo... he visto cosas que vosotros no creeríais... atacar naves en llamas más allá de Orión, he visto rayos C brillar en la oscuridad cerca de la puerta Tannhäuser.

Todos esos momentos se perderán en el tiempo como lágrimas en la lluvia.

Es hora de morir."
Un error que nos costó bastante encontrar:
Una aplicación de reserva de coches online. Al seleccionar ciertas fechas de inicio y fin el programa no calculaba bien los días de reserva y cascaba... Al final era porque la función encargada de contar los días transcurridos entre dos fechas lo calculaba contabilizando los segundos de diferencia entre ambas fechas. Pues bien, cuando entre la fecha de inicio y fin estaba el día donde se adelantaba una hora el reloj o se atrasaba una hora, el calculo salía con decimales y se iba todo al carajo... ¡Alucinábamos con el error hasta que caímos en el tema horario! ^_^
No es un bug, pero a mi me hace bastante gracia cuando ves a gente que empieza a picar C#. Como algunos sabreis, y si no os lo digo yo, la declaracion y acceso a arrays multidimensionales se hace con comas, pej: "int[,] matriz" nos serviría para un array de 2 dimensiones de enteros, en lugar del típico "int[][] matriz" que usaríamos en C/C++ o Java.

El caso es que es un error bastante fácil de solucionar: Un vistacito a la msdn o a google y rápidamente lo arreglas, pero te encuentras gente en la facultad que llega a echarse horas intentando hacer compilar los corchetitos de marras xD
Maldita economía de bytes que nos inculcaron... con lo fácil que es definir variables o campos gigantescos para no tener estos problemas [esto... ¿se nota que es irónico?]

Manda huevos también guardar una fecha en texto, aunque a saber de qué sistema estamos hablando
... no es el más dificil que he resuelto, pero sí el último; trabajando con una aplicación que genera órdenes contables me doy cuenta de que sólo funciona correctamente si la ejecuto en debug, aún sin tocar ninguna variable; si se ejecuta en background no funcionaba bien... después de 1 día entero al borde del suicidio (la aplicación es muy compleja), encuentro el error en un commit transaccional al que le "faltaba" añadir un tiempo de espera....
Dichoso commit work sin wait!!!!…   » ver todo el comentario
#14 Yo he visto fallos en aplicaciones que ocurrian SOLO con el tema por defecto de windows vista -un bug de windows, claro, pero unas risas encontrar el pq....- y otros que pasaban solo con WS a los que se accedia a traves de no recuerdo que tipo de proxy por ssl teniendo mcafee...

Y #11 lo que ha hecho daño a los programadores es que programe tanta gente a la que no le gusta programar y la subcontratacion... pero paso de ponerme serio :-P

Lo que de verdad ha hecho un daño HORRIBLE a la programacion es el ctrl+c, ctrl+v.

Programar es un arte, el que lo dude miserable! </mode ansar>
#14 En realidad no se trata de que el bug sea complicado, sino que sea complicado encontrar el fallo, sobre todo, vistos los síntomas.

Tú te encuentras con que un programa falla 3 días al año y funciona bien el resto del tiempo y alucinas pepinillos (aunque admito que lo primero que podría ocurrísele a uno sería mirar que pasa con las fechas).

Pero miremos el segundo caso: una cámara falla cuando el jefe entra en plano. Ahora dime lo que hay que mirar, sin mirar la solución :-)
#39 No hace falta que esperes a un JIT para usar Python en casi todo: puedes reescribir fácilmente las partes críticas en C, con Cython.

Secundo lo de D. Te votaría positivo si pudiera. Desde el ban day no he podido votar nada.
Yo antes era de los que pensaba que C++ era lo mejor. Ahora me da pánico. Espero que se generalicen alternativas mejores como D (que es básicamente lo que C++ debería haber sido desde el principio: más claro, bien definido, con GC opcional Y con punteros si los quieres, compilado, etc.) o cualquier otro lenguaje con GC.
De lejos lo más agradable para programar, por la claridad, facilidad de uso y por la sintaxis que evita que tú mismo metas la pata sin querer, es Python (probé también Ada,…   » ver todo el comentario
Pues no sé... a mi me parece que con un depurador los fallos de ese tipo se encuentran en 0 segundos...
Bah! se pone en el manual y ya está :-D
La dificultad de depurar es inversamente proporcional a la posibilidad de reproducir. Las relacionadas con fechas suelen ser complicadas. Pero las peores son los bugs en hilos.
Pues yo el peor fallo que me he encontrado es un día que quería imprimir y no podía. Quise ver el código fuente de los drivers y... NO ESTABA!

</rms>
El fallo informático mas difícil del mundo es el que se aproxima por los jueces.
Yo la cosa más rara que he visto fue con mi primer AMD K6II-350mhz, creo recordar. Lo pido al distribuidor, que era además el primer AMD que montaban.

Ya en casa, instalo windows, instalo photoshop y trabajando se apagaba el ordenador.

Total, lo mando al distribuidor, y me lo devuelven diciendo que a ellos les funcionaba perfectamente.

Sigo con él, y lo mismo, peta.

Consigo sacar un procedimiento que siempre lo colgaba: abrir photosop y crear un documento nuevo de nosecuantos megas.…   » ver todo el comentario
Yo antes era de los que pensaba que C++ era lo mejor. Ahora me da pánico. Espero que se generalicen alternativas mejores como D (que es básicamente lo que C++ debería haber sido desde el principio) o cualquier otro lenguaje con GC.
De lejos lo más agradable para programar, por la claridad, facilidad de uso y por la sintaxis que evita que tú mismo metas la pata sin querer, es Python. Dicen por ahí que Ruby es aun mejor, pero aun no lo he probado.
#28 Esas averías no son nada raras hoy día, en el opel corsa C si pones el móvil en el bolsillo de la puerta izquierda te salta avería de airbag. Por no contar las veces que se descodifican llaves y mandos de cierre por este tema.
y que tal este fallo meneame.net/story/la-nueva-web-del-pp-hackeada
"El error técnico está en los controles de sesión; es un defecto de programación de base. Mezclan autentificación por sesiones, cookies y variables, una auténtica chapuza de programación."
#3 Es cierto, y alguien lo dice en un comentario del blog, pero es más un fallo de traducción que de concepto.
La verdad es que es un error de principiante. Cuando alguien elige un formato para representar algún valor, inmediatamente debe buscar la combinación más larga posible para indicar la longitud de la cadena. Está claro que lo difícil es buscarlo, pero creo que aquí, pensar en cualquier otra posibilidad como causa del error, sería una tontería.
#20 Discúlpame colega, pero eso no es un bug, es un error lógico :-P
Sé que suena a que es lo mismo, pero NO lo es.
No os engañéis. El fallo informático más difícil del mundo está entre la silla y el teclado, y no es informático.

HACKERZ STOLE MAH WALLET!
#22 El segundo me parece cojonudo, aparte de lo que es el problema es el descojone que casque cada vez que entra en escena el super sheriff de la empresa xD.

Lo primero que hay que hacer -he visto la solucion, es lo primero que yo haria- es un mail que pasara por todos tus compañeros comentando como la fealdad de el CEO ha destruido un maravilloso software.

Ese error si mola, es hasta gracioso, pero el que ha ganado parece 'facil' de sacar -vamos, que es muy curioso, pero no me parece…   » ver todo el comentario
Pues yo una vez estuve horas intentando ver qué fallo tenía un script embebido en un SVG, después de darle mil vueltas resulta que *el fallo estaba en un comentario* (WTF?!)

Resulta que por alguna razón los scripts de ese tipo no admitían acentos en los comentarios (esto fue hace varios años ya), los cuales deberían ser ignorados por el parser en cualquier caso. Manda huevos.
El caso de abajo es mucho más retorcido que un simple buffer overflow del que hablamos.
en.wikipedia.org/wiki/Deadlock

Sin duda, el problema más difícil de solucionar, sobre todo cuando las "race conditions" no están bien definidas o no son óptimas.
Hace poco se descubrio en linux un fallo en el código que se encargaba de insertar un segundo a final de año a petición de ntp. Me parece aun más raro que esto...
Pues no me parece tan retorcido el fallito. A mí eso mismo ya me ha producido bugs al imprimir facturas con esa fecha (no necesariamente en esa fecha).
Wow xD Que retorcido el cabrón.
#3 FAIL week :-D
La verdad que no me ha parecido algo muy dificil de detectar. Ya me gustaría ver a esta peña intentando realizar detecciones de colisión a nivel de pixels.
#2, ¿de verdad has peleado con muchos bugs y este te ha parecido acojonante? 0.o
Vaya mierda de bug... Eso es lo mas extraño que tienen? yo he visto maravillas de java y de microsoft que le dan mil vueltas....
#58 A mí me pasó con un Pentium 120 algo parecido. En mi caso era por una toma de tierra: al encender el equipo, si el protector de pantalla no estaba atado a una toma de tierra el ordenador se colgaba.

Igual tiene que ver con la toma de tierra de tu enchufe.
Yo sufrí un bug en una fotocopiadora durante dos días seguidos en la Escuela en la que estudiaba. Mis compañeros de curso siguen descojonándose cada vez que me ven. El bug consistía simple y llánamente en que la fotocopiadora dejaba de funcionar en mi presencia. Era una fotocopiadora de monedas qu estaba en un pasillo. Hacías cola hasta que te tocaba y justo en ese momento la fotocopiadora pasaba olimpicamente de hacer copias y lo mejor es que hasta que no me iba no volvía a funcionar. No es…   » ver todo el comentario
Creo que el peor bug que he escrito en mi vida, era un puntero que bajo ciertas circunstancias, podia terminar apuntando a puntero que apuntaba a su vez al primer puntero, imaginaos el lio....
#31 Para eso se inventaron las pruebas unitarias :-)
#46 ¿no será que usas el mismo SimpleDateFormat en distintos hilos? Porque esa clase no es estática ni ninguna de sus fuciones lo son. Un simple new SimpleDateFormat ("...") y el objeto obtenido no puede ser modificable fuera del alcance de su definición...

No es lo mismo "thread safe" que tenga elementos estáticos. Obviamente si modificas el mismo objeto desde distintos hilos y no controlas las condiciones de concurrencia te pasarán cosas raras, para eso lo mejor es crear un objeto nuevo por cada hilo (o sincronizar el objeto).
Me parece un atropello guardar la fecha como una cadena de texto, así, de esta manera, pero bueno xD

Desde luego es un bug en el que tienes que caer en el motivo del problema, aunque creo que yo he tenido bugs más complicados.

Ahora que se me pase por la cabeza, me acuerdo que un bot mio para salas Jabber se colgaba estrepitosamente en algún momento, sin saber exactamente en cual. Sin pistas ni nada, al final descubrí que, el sistema de logs guarda todo lo que se escribe en la sala con…   » ver todo el comentario
El meneo esta cojonudo :-D Aunque de esa página prefiero el (ya meneado) topic sobre chistes informáticos :-D
#45 El de las 500 millas es muy divertido pero tiene pinta de ser falso. Solo hay que saber como funcionan las redes para darse cuenta que no tiene nada que ver la distancia con el tiempo de respuesta, y que un timeout de 3 ms no lo he visto configurado en ningún sendmail en mi vida.
#63, xD cuanta ira junta, jajaja. No te piques que vas a generar un segfault, solo te hacía un comentario. Y no, mi nivel no es casi cero, es solo cero.
Venga, una tilita y a seguir peleando :-)

PD: con respecto a la pregunta que me haces: "Si, estoy haciéndolo ahora mismo con este mensaje ;)"
#47 Precisamente eso es lo que digo, el mismo objeto SimpleDateFormat en varios hilos. Una clase no necesita ser necesariamente estática para que sea "thread safe". Simplemente en su momento supuse que el objeto SimpleDateFormat simplemente guardaba el patrón y que el método parse utilizaba sólo variables locales (¡al menos yo lo habría programado así!). Obviamente pasé ampliamente de la documentación de la clase hasta que llevaba un rato con el problema y lo había acotado.

Como dice #48, los problemas relacionados con condiciones de carrera suelen ser los que producen resultados más desconcertantes y difíciles de depurar.
#3 Si, fue lo primero que vi al entrar en el blog...
#18 Simplemente genial.
¿y donde queda el error que dio nacimiento a Fenomenoide (freakazoid)?
#58 - A mi me pasó algo parecido pero era que de repente el ratón y el teclado dejaban de responder... aunque el equipo seguía funcionando sin problemas. En mi casa ocurría pero no en el taller... medimos corriente, etc... me instalé un SAI... le cambiamos pieza por pieza el equipo entero... y nada... seguía igual... Cambiamos enchufe... todo. Lo único que solucionó el problema fué cambiar el ordenador 1 metro más a la izquierda... Ahora que lo estoy pensando es posible que fuese debido a…   » ver todo el comentario
Yo siempre que quiero guardar una fecha de esa forma, busco precísamente la fecha más larga, que es un miércoles de septiembre a partir del día 10.
voto igual por ese #18 muy bueno
Ya ves que que cosa; pues yo tengo varios fallos cada semana lo suficientemente chungos como para plantearme seguir con esta mierda.
Pues yo lo he visto a la legua :-D
El error más cachondo que he tenido yo fue con la clase SimpleDateFormat de la librería de java. Esos son los errores más graciosos, tiendes a pensar que el código de las librerías de java es infalible. Pero si usas el mismo objeto SimpleDateFormat en varios hilos formateando varias fechas y si no sabes que la maldita clase tiene internamente variables static que modifica al hacer un "parse" (menuda chapuza) y no es "thread safe", los resultados obtenidos son inquietantes xD porque no tienes ni puta idea de cómo puedes estar obteniendolos tan mal... Estuve varios días con este tema.
Para fallos el del Zune, jaja, menudo ridículo hizo microsoft.
#18, yo iba a poner también el de las 500 millas. Es fabuloso.

www.microsiervos.com/archivo/ordenadores/email-500-millas.html
¿esto en portada?
Eso explica el porqué del concepto que la gente tiene de los informáticos...
comentarios cerrados

menéame