¿Cuáles son algunos de los errores de software más divertidos que has visto?

Durante mis primeros días de carrera, formé parte del equipo del proyecto, que tuvo que lidiar con un error muy interesante (divertido). Nuestro equipo entregó una solución de aplicación de cumplimiento financiero a una de las instituciones financieras más grandes del mundo.

El proyecto se entregó con algunos retrasos, y finalmente el cliente comenzó a usarlo. Todo iba bien y una tarde recibimos un ticket de “atención al cliente” del cliente. Uno de los usuarios comerciales ha encontrado y emitido y enviado un correo electrónico con el contenido similar a continuación:

Estimado equipo de soporte de productos,

La aplicación fallaba cada vez que bebo coca cola. Y cuando sucede, reinicio el navegador e ingreso todos los detalles desde el principio. Mire el problema y resuelva lo antes posible.

Gracias,

Cliente.

Nota: si lo leyó bien, el cliente ha informado que su aplicación falla cuando bebe coca cola.

Inicialmente pensamos que era una broma y enviamos un correo electrónico de cortesía diciendo que el problema está asignado a un ingeniero y lo actualizaremos pronto. Pensamos que había terminado y lo olvidamos.

Una semana más tarde, el cliente respondió con un correo duro, diciendo que no hemos respondido al problema correctamente. De repente, todos hablaban sobre el tema.

“La aplicación se bloqueaba cuando bebimos coca cola”

Lo que hizo el equipo de control de calidad, para una lata de coca cola, se sentó frente al sistema y comenzó a beber coca cola, para ver si la aplicación fallaba (solo estoy bromeando aquí). El equipo de control de calidad no puede creerlo, ni el equipo de desarrollo. Finalmente, establecimos una llamada con el cliente, y la llamada fue algo como esto

Cliente C, Equipo de proyecto P.

C: hola

P: Hola, ¿podemos obtener más detalles sobre el tema?

C: completar estos formularios de cumplimiento lleva mucho tiempo. Entonces, en el medio, tomo una coca cola y sigo llenando el formulario. Cuando hago esto, la aplicación se bloquea.

P: ¿Estás seguro? No podemos creer esto.

C: Yaaa … Lo sé. Pero intenté tomar café y funcionó absolutamente bien.

No podemos creerlo. No hemos codificado nada de eso, no podemos codificar así. Entonces hicimos una pregunta aleatoria para mantener el diálogo activo. Finalmente le dijimos que “tendremos una discusión técnica y lo contactaremos”.

Desconectamos la llamada y nos sentamos incrédulos.

El equipo continuó discutiendo todo el asunto. Era un joven y solo lo estaba escuchando (No, no es bollywood. No resolví el problema. Ni siquiera los ayudé a resolver el problema. Solo era un espectador).

Pasaron las horas, varias discusiones acaloradas, argumentos.

Finalmente alguien (un tipo de desarrollo) obtuvo la pista.

Alguna suposición …

… ..

… ..

El desarrollador hizo una llamada con el cliente y le hizo la siguiente pregunta

C: Cliente, D: Tipo de desarrollo

C: hola

D: Hola (tono audaz y emocionado)

D: ¿Puedo preguntarte dónde te sientas? Me refiero a qué piso

C: 4to piso.

D: ¿De dónde sacas el café?

C: Tenemos despensa en cada piso. Así que está a solo 5 cubículos de distancia.

D: ¿ Y de dónde sacas la coca? (Con un tono excitado, que ya ha resuelto el problema)

C: piso 11. Ahí es donde está la máquina expendedora.

D: Por lo tanto, puede tomar algún tiempo obtener eso, digamos 15 minutos,

C: Sí, incluso más que eso, la cafetería está muy llena.

Eso es. El lo logró. El problema se solucionó y no el cliente puede beber cocaína felizmente mientras trabaja.

Aún preguntándose….

Hubo un procedimiento de tiempo de espera de solicitud en nuestra solicitud. Cuando no utiliza la aplicación durante más de 15 minutos, se cierra automáticamente. Nunca fue probado y hubo error.

Cuando se agota el tiempo de espera de la sesión, intenta guardar el formulario, pero como algunos de los campos obligatorios no se completaron, se produce una excepción y esto bloquea el navegador.

Por lo tanto, nunca deje nada sin probar, incluso si es menos utilizado.

Gracias por leer.

Hace años, asistía a una pequeña conferencia en IBM donde demostraban nuevas capacidades en WebSphere (estaba haciendo software empresarial en ese momento). Una de las demostraciones involucraba mostrar la integración de Eclipse que se suponía que facilitaría mucho el desarrollo de WebSphere. Durante la demostración, el presentador se lanzó y pasó por un asistente que incluía muchos pasos. Media hora después, finalmente llegó al último paso en el mago. Desafortunadamente, el botón Finalizar en el último paso estaba deshabilitado, sin indicación visual de por qué. El desafortunado presentador comenzó a retroceder en el asistente, buscando alguna entrada faltante. Después de otra media hora, retrocedió hasta el comienzo del asistente, pero no pudo encontrar el problema. Y así, la sesión terminó con una nota baja. Oh bueno, estas cosas pasan …

Hace mucho tiempo había una computadora que usaba números de 18 bits para realizar un seguimiento de los recuentos de acceso a archivos. Esto ahorró como 100 nanosegundos, lo cual fue un gran negocio en una computadora de $ 7 millones de dólares.

Esto interactuó mal con un esquema de almacenamiento en caché de archivos que se configuró con nuestro programador más oloroso. Su programa analizaría los recuentos de acceso a archivos y movería los programas usados ​​con frecuencia a los discos más rápidos, y los que se usan con poca frecuencia a los discos más lentos, y los que se usan con poca frecuencia a la cinta magnética.

Pero debido a las circunstancias, los estudiantes estaban usando mucho el compilador FORTRAN. (Irónicamente, el maloliente programador había escrito la mayor parte del mismo compilador FORTRAN). Después de aproximadamente tres meses, el recuento de acceso para el ejecutable del compilador superó los 131.071, por lo que en la notación firmada de 18 bits se convirtió en un número negativo. El programa de movimiento de archivos decidió que el compilador se había usado muy raramente, como un número negativo de veces, por lo que debería moverse a la cinta. Mediante varios trucos difíciles, su programa puso un mensaje en la consola para que el operador monte una cinta de archivo para la operación de escritura. Esto tomó bastante tiempo, ya que las cintas de archivo estaban a una considerable distancia de la sala de computadoras. Después de montar y enhebrar la cinta, el programa escribiría el compilador en cinta, eliminaría el archivo del disco y colocaría un mensaje de operador para desmontar y colocar la cinta. Pero el compilador tenía un uso tan alto que probablemente ya era necesario que el compilador se ejecutara, por lo que se puso en cola otro mensaje solicitando que se montara la cinta. Desafortunadamente, los operadores simplemente hicieron su trabajo y no pensaron demasiado en lo que estaba sucediendo. Simplemente trabajaron cada vez más y comenzaron a dejar de fumar de izquierda a derecha. Solo entonces la gerencia pensó en preguntar por qué estaban renunciando, y solo más tarde le pidieron a la gente del sistema que descubriera por qué se solicitaban tantas cintas.

Entonces, horas y horas y millas y millas de operadores caminando, debido a una pequeña supervisión de codificación.

Alrededor del 30/01/2012, comencé a tener un error en el que la partición raíz de mi estación de trabajo desaparecería, haciendo que la máquina sea inútil. Reiniciar la máquina siempre solucionó el problema. Comencé a ejecutar todo tipo de diagnósticos, buscando resultados de depuración para el sistema de archivos, etc. No pude resolverlo. Con una pérdida completa, eventualmente realicé una actualización de BIOS con la esperanza de que mágicamente solucionara el problema, pero sin dados. Comencé a buscar en la web cosas como “SSD Crucial desapareció”. y encontré esto: ¿Por qué mi SSD “desapareció” de mi sistema? Básicamente decían que esto podría ocurrir después de una pérdida de energía, pero no hubo pérdida de energía y sucedió repetidamente después de que la máquina funcionó por un tiempo. Entonces, tomé el consejo de su último punto, que era actualizar el firmware de la unidad. Al leer su registro de cambios de firmware, encontré esto:

“Corregir una condición donde una respuesta incorrecta a un contador SMART
hará que la unidad m4 deje de responder después de 5184 horas de
Tiempo de encendido. Sin embargo, la unidad se recuperará después de un ciclo de encendido.
Esta falla se repetirá una vez por hora después de llegar a este punto. los
la condición permitirá al usuario final actualizar con éxito el firmware y
no representa ningún riesgo para los datos del usuario o del sistema almacenados en la unidad “.

Entonces, 5184 horas / 24 horas son 216 días. 216 días antes de empezar a ver este error fue el 6/27/2011. Miré hacia atrás a través de mis correos electrónicos de Newegg y descubrí que compré la unidad el 21/06/2011. ¿Coincidencia? Yo creo que no.

De hecho, la actualización del firmware solucionó el problema y, por supuesto, las matemáticas solo funcionaron porque casi nunca apago mi máquina.

Así que este error (error de novato, aún divertido de atrapar) ocurrió recientemente durante nuestro proyecto universitario. El proyecto trata sobre el sistema de posicionamiento en interiores basado en huellas digitales de señal inalámbrica. Estábamos obligados a escanear y recolectar huellas digitales wifi de los enrutadores inalámbricos presentes en nuestro entorno de prueba. Para facilitar el proceso, se desarrolló una aplicación prototipo en Android para facilitar la recolección fácil de señales wifi. Para que la aplicación funcione en cualquier nuevo entorno de prueba, el SSID (nombre) de los puntos de acceso wifi no estaba codificado. Por lo tanto, la persona que tomaba las huellas digitales debía ingresar los SSID manualmente en un campo de texto que luego se almacenaba en una estructura de datos Hash Set para una fácil comparación con los resultados del escaneo wifi en el dispositivo móvil. Ahora, para acelerar el proceso de recopilación de datos, cada uno de nosotros instaló esta aplicación en nuestros teléfonos y comenzamos a recopilarla para diferentes ubicaciones en nuestro entorno de prueba. El siguiente proceso fue fusionar estos datos de diferentes teléfonos y usarlos en nuestro algoritmo de aprendizaje. Después de alcanzar una precisión respetable en estos datos, correríamos esto en una señal de prueba en vivo para evaluar nuestra posición dentro del entorno. Entonces, ahora que llegamos al problema, nuestro sistema pudo lograr una precisión de aproximadamente el 90% en los datos de entrenamiento, pero no pudo predecir correctamente correctamente la señal de prueba en vivo. Intentamos cambiar la posición del enrutador, los parámetros de aprendizaje, pero no pasó nada. Aún obtendríamos predicciones incorrectas para muchos lugares. Después de 6 horas frustrantes de entrenamiento y pruebas, nos sentamos para entrenar el sistema por última vez. Estaba copiando los datos de entrenamiento en la computadora desde diferentes teléfonos cuando me hizo clic. Entonces, cuando ingresamos manualmente los SSID de los puntos de acceso en nuestros teléfonos, el orden en que se insertaron en el respectivo conjunto de hash fue diferente en diferentes teléfonos debido al simple hecho de que primero se convirtió en un hash que estaba resultando ser diferente en diferentes teléfonos. Por lo tanto, los archivos de datos de entrenamiento tenían un orden diferente para las intensidades de señal de los puntos de acceso y fusionarlos sin coincidir con el orden daría como resultado datos de entrenamiento que no tenían sentido. Entonces, incluso después de entrenar contra él, estábamos obligados a obtener resultados incorrectos. El error fue un error de novato al hacer la aplicación, pero fue divertido debido a su impacto en los resultados de la prueba. ¡Así que finalmente lo arreglamos y probamos con éxito el proyecto y funcionó !

Imágenes aleatorias de carne

Tenemos un caso de imágenes aleatorias de carne cruda que aparecen en una plataforma de tienda web de terceros que mantenemos. Las imágenes estaban tomando los lugares de la imagen real del producto. Entonces el comprador quisiera listados como:

Zapato, zapato, zapato, filete. Vestido, vestido, rebeca, salchicha …

Resulta que en este software, si una imagen falta del servidor, la plataforma reemplazaría la imagen real del producto con una imagen de la máscara de demostración de la tienda, que en este caso era una carnicería de demostración en línea.

No es realmente un error, pero está cerca.

Yo era un programador que usaba una computadora SDS Sigma-7. Uno de nuestros usuarios quería usar un paquete de software, escrito en Fortran, que enumerara el procesamiento (creo que podría haber sido uno de los sistemas de William Waite). Lo compiló y luego trató de obtener un ejecutable ejecutándolo a través del cargador. El cargador funcionó durante mucho tiempo (horas) sin completar su tarea. Esto parecía muy extraño porque el programa no era tan grande.

Me pidieron que mirara el problema.

Lo primero que noté fue que el programa estaba en un círculo muy cerrado. Miré el código de ensamblaje para el cargador y descubrí que estaba atascado en el código de “reparación” que se ocupaba de parchear las referencias hacia adelante. El compilador Fortran fue un compilador de una pasada. Entonces generó código objeto cuyas instrucciones a menudo se referían a variables que aún no se habían asignado en la memoria. El cargador manejó esto creando una imagen ejecutable en la que los campos de dirección de estas instrucciones no contenían la dirección de la variable, sino la dirección de la siguiente instrucción en la lista vinculada de instrucciones que necesitaría “parchearse” con la dirección correcta una vez que fue conocido por el cargador. La tabla de símbolos del cargador está vinculada a la primera instrucción para cada símbolo, de modo que cuando el símbolo se define, la lista se puede recorrer y las direcciones se actualizan en las instrucciones a los valores correctos.

Esto funcionó bastante bien la mayor parte del tiempo. Pero para este programa en particular, resultó que había una matriz muy grande declarada (“L”) que fue utilizada por casi todas las declaraciones (como “L (I) = L (K) * L (J)”). Eso significaba que había una gran cantidad de instrucciones en la lista de arreglos para “L”. Esto era un problema porque quienquiera que hubiera escrito el código obviamente no había esperado que las listas se alargaran demasiado, y como decían los comentarios en el código fuente, había tratado las listas como una cola. Eso significa que cada vez que se agrega una nueva instrucción a la lista, el cargador recorre la lista completa para llegar al final donde adjuntó la nueva instrucción. Esto significaba que el cargador era un algoritmo O (n ^ 2).

Todo esto fue exacerbado por nuestro uso de memoria virtual. Cada vez que se agregaba una solución, se recorría todo el conjunto de páginas para el código ejecutable, lo que significaba que una vez que el programa era más grande que la memoria física, el cargador experimentaba fallas masivas en la página que lo ralentizaban desde las velocidades de memoria a las velocidades de disco, un ejemplo clásico uso deficiente de memoria virtual.

Una vez que me di cuenta de esto, fue fácil cambiar de una cola a una pila (el orden de las reparaciones obviamente no importaba), lo que significaba que era un tiempo constante para agregar una solución a la lista y O (n) para recorrer la lista solo una vez cuando se procesaron todas las reparaciones.

El “error” fue que el programador había pensado que solo porque las nuevas reparaciones estaban lógicamente al final de la lista, una cola era la estructura de datos apropiada, cuando en realidad cualquier lista vinculada (incluida una pila) era todo lo que se necesitaba, por lo que ¿Por qué no elegir el más eficiente?

No es un error, sino un problema de red.

Un amigo mío trabajaba en el personal de TI de un campus universitario local. Hace años instalaron un enlace inalámbrico entre el campus y un hospital que estaba a unos 10 km de distancia (aproximadamente 6 millas). Todo estuvo bien hasta que un día el enlace comenzó a producir errores. Al principio, nadie se dio cuenta, ya que se sabe que los enlaces inalámbricos son defectuosos de vez en cuando, si hay una fuerte lluvia o condiciones similares, tienden a comportarse mal. La mejor política es mantener la calma e ignorar hasta que mejore. Por cierto, el enlace inalámbrico de larga distancia requiere una línea de visión clara. Un árbol o cualquier obstrucción de algún tipo realmente no ayuda. Para distancias realmente largas, incluso la curvatura de la Tierra entra en juego, por lo que se necesita un mástil un poco más alto para poner la antena. Los ingenieros saben todo esto y es cuestión de cálculos de fuerza bruta para que la instalación se realice correctamente.

Pero volviendo a la historia, esta vez los errores comenzaron a aparecer con una persistencia sorprendente con períodos de apagones completos hasta el nivel de mucha molestia.
Un tipo tomó todo el coraje y subió al techo donde se instaló la antena y aquí estaba: ¡un nuevo edificio de gran altura se alzaba directamente en el camino del rayo inalámbrico! Las obras de construcción se llevaron a cabo durante aproximadamente medio año, mientras que la grúa giraba causando algunos errores, a veces más, a veces menos, pero una vez que terminaron los pisos superiores estaba obstruyendo completamente la línea de visión, por lo tanto, el enlace de red se fue abajo finalmente y para siempre.

En comparación con los errores de programación (excepto algunos relacionados con el hardware) donde toda la potencia está en el cerebro de un programador o un usuario ingenuo, las redes son sospechosas de todo tipo de impacto ambiental que podría ser algo que realmente no espera a pesar de todo su diseño entrenamiento 😉

Estaba trabajando en mi primer videojuego, que iba a ser un remake de Joust para plataformas de PS2. Habíamos agregado un arma de ballesta, pero por alguna razón las flechas siempre apuntaban apuntando directamente a la cámara. No importa lo que hice, no pude hacer que giraran.

Alguien finalmente sugirió que tal vez el modelo de flecha estaba corrupto de alguna manera … resultó que este era un activo que había sido prestado de otro proyecto. Así que busqué un activo de juego para usar como reemplazo de depuración. La vaca parecía lo suficientemente diferente y lo suficientemente grande como para determinar obviamente hacia dónde se enfrentaba.

Pronto las vacas volaban por todas partes, lo que demuestra que era el activo de la flecha el problema. Sin embargo, cuando mi productor lo vio, pensó que era lo mejor que había visto; si hubiéramos enviado, la pistola de vaca habría llegado como un huevo de pascua seguro.

Pensé que esto era apropiado teniendo en cuenta el aniversario del lanzamiento de Apple] [. Uno de los primeros programas que escribí fue en Applesoft BASIC (por supuesto). Nuestro maestro (estábamos en octavo grado) sugirió que escribiéramos un programa para imprimir todos los factores de un número (excepto él y 1). Finalmente pensamos que lo teníamos funcionando y elegimos algunos números cada vez más grandes para probarlo. Mi amigo puso el número de teléfono de su casa (no había teléfonos celulares a finales de los 70) y obtuvo todos sus factores. Puse el número de teléfono de mi casa y no pasó nada, solo volví al aviso después de un corto tiempo. Nos llevó años descubrir que no era un error en nuestro programa; resulta que mi número de teléfono era un número primo.

Este es el error más glorioso que he visto, o es el mejor ejemplo de gestión de expectativas por carta en la historia del hombre.

Hace casi un millón de años, a fines de la década de 1990, un miembro habitual de nuestro Grupo de Usuarios de Linux trajo su nuevo y brillante BeBox para hacer un show-and-tell rápido. Esto era, en ese momento, lo último y lo mejor de todo, en la medida en que era una computadora personal multiprocesador bastante accesible.

Una de las características más interesantes de BeOS es que, si se desea, se puede desactivar una CPU a través de la aplicación de monitor de la CPU. Supongo que esto fue para situaciones en las que uno simplemente quería consultar el correo electrónico o lo que tiene, ahorrando algo de energía en el camino.

Como sucede en situaciones de demostración, este habitual demostró que podía apagar una de las CPU, y todos vimos que la carga aumentaba inmediatamente en la CPU restante. En una alondra, decidió que vería lo que sucedía si también intentaba deshabilitar la CPU restante …

Y así, la demostración de BeBox se interrumpió abruptamente.

En 1991, me encontré con el virus del domingo. Infectaría un ejecutable y luego, si su computadora funcionaba un domingo, limpiaría la unidad … en teoría, excepto que nunca pareció hacer nada afortunadamente. Escribí un ejecutable de 24 bytes y lo infecté con el virus Sunday para examinarlo. Desmonté el programa infectado y descubrí que los desarrolladores del Sunday Virus habían estipulado que debería ejecutarse si DOW (día de la semana) = 7; excepto que dow va de 0 a 6, por lo que nunca se ejecutó. No estoy seguro si lo hicieron a propósito o si fue un error, de cualquier manera fue un gran alivio.

No es un error, pero …

Hace mucho tiempo, un amigo tenía un trabajo trabajando en una nueva “mini computadora” y se quejaba de que el compilador era increíblemente lento. La gente que trabajaba allí solo dijo que estaba mimado por haber trabajado durante tanto tiempo en los mainframes gigantes, y que solo tendría que acostumbrarse a las máquinas más pequeñas que tardaban más.

Bueno, era MUY lento, así que investigó un poco y descubrió que cuando el compilador había sido portado al mini, la persona que depuraba el puerto había establecido los tamaños de búfer de lectura y escritura del disco en un carácter. Básicamente, por cada carácter que el compilador quería leer o escribir, tenía que esperar una rotación completa del disco.

Mi historia de depuración favorita.

Hace unos treinta años, un amigo mío estaba escribiendo un juego para el Atari 800. En aquellos días, se hacía en lenguaje ensamblador y la secuencia de escritura, compilación y prueba no era un proceso simple.

Una mañana, hizo un par de cambios, compiló el código y procedió a probar el juego solo para descubrir que el joystick ya no funcionaba. Lo apagó, volvió a cargar el código fuente y comenzó a buscar el error. Encontró y arregló algo, luego se volvió a compilar y comenzó a probar nuevamente. Desafortunadamente, el joystick todavía no funcionaba, así que tuvo que volver al código fuente.

La memoria siempre estaba escasa en esas máquinas de 8 bits, por lo que no podía mantener el código fuente, el ensamblador y el programa de destino en la memoria al mismo tiempo. La computadora tuvo que reiniciarse y todo volvió a cargarse desde disquetes de 5,25 “.

Esto ayuda a explicar por qué, después de varias repeticiones de pensar que había encontrado y solucionado el problema, finalmente se sintió tan frustrado que levantó el joystick y lo arrojó al otro lado de la habitación.

¡Solo después de ver el extremo del cable del joystick volando por el aire se dio cuenta de que nunca estaba enchufado!

El bicho más divertido o el bicho más hack …

Lideraba un proyecto de C ++ de código abierto de aproximadamente 15 personas con 400 mil líneas de código, y estábamos pirateando nuestra base de código bastante duro sin hacer suficientes pruebas. Entonces, efectivamente, comenzamos a ver una tonelada de misteriosos errores de ejecución y segfaults.

No hubo una solución inmediata, así que tuve la brillante idea de agregar un controlador de errores simple al main (), algo como:

estático vacío catch_function (int señal) {
pone (“Algo malo sucedió”);
ir a reiniciar;
}

int main (nulo) {
pone (“Helloworld”);
señal (SIGINT, catch_function);

REINICIAR:
acceptSomeConnectionsAndDoSomeStuffForever ();

pone (“Saliendo”);
devuelve 0;
}

¡Problema resuelto!

Excepto ahora, en lugar de bloquear la aplicación cada 15 minutos, bloqueaba toda la máquina varias veces al día .

80% de soluciones …

Hace mucho tiempo, había un cambiador de fondo de pantalla llamado Panorama32, que tenía un error que creaba archivos llamados PRAMA $$. BMP en ubicaciones aleatorias en la computadora. Mi padre tenía esta aplicación instalada en una de sus máquinas y se vio afectada por este error.

Y no solo desplegó este archivo en lugares como carpetas, o en su escritorio o barra de tareas. Lo insertó en cosas como las listas de reproducción de Winamp, donde eventualmente causaría que Winamp arrojara un error, o el nombre del archivo aparecería en un bloque en una hoja de cálculo en Excel, haciendo que Excel se bloquee si intentas guardar la hoja de cálculo.

Pero si eso fuera todo, sería solo un extraño error molesto.

Sin embargo, en la máquina de mi padre, estos archivos eran de hecho fotos que él había borrado de su máquina … fotos principalmente de su ex esposa, mi abuela muerta y mi hermano muerto.

Creo que esto puede haber sido un factor contribuyente que lo llevó a darme esa máquina aparentemente embrujada. (“¡Aquí, quédatelo … TÚ lidias con sus fantasmas!”)

———————————-

Acabo de experimentar este interesante fenómeno de viaje en el tiempo del Explorador de Windows.

En Windows 7 (tal vez también en otras versiones), cuando abre una carpeta en una ventana del Explorador y la configura para agrupar por fecha de modificación, luego comienza a llenar la carpeta con archivos, si deja la ventana abierta después de la medianoche, el grupo superior pasar de ser etiquetado “Hoy” a ser etiquetado “Mañana”.

No estoy seguro de si son realmente divertidos o simplemente extraños en su contexto.
Un trazador de ADN, supuestamente de alto rendimiento, codificado en C.
Una estructura de 2496 bytes.
Varias funciones, digamos siete, pasan esa estructura como un argumento por valor.

Para puntos de bonificación, el siguiente fragmento:
(Es posible que haya cambiado el nombre de la función, porque no quería volver a buscarlo, pero el cuerpo es exactamente como aparece, no puedo olvidarlo nunca)
// devuelve un número aleatorio entre a y b.
long random_long (long a, long b)
{
int r = rand ();
// Devuelve un número aleatorio entre 0 y 32700
// NOTA: este comentario está allí en el código, no es algo que simplemente ignoraron; escribe el límite superior exacto, que no recuerdo, así que redondeé al orden que recuerdo.
si (a + r> b)
devolver a;
más
devuelve a + r;
}

Ahora, supongamos que desea un número entero aleatorio en cualquier rango que contenga 100 elementos. Digamos que es de 0 a 99, solo porque. Suponiendo que rand () devuelve números con una distribución uniforme (cuanto más cerca, mejor como generador de números aleatorios), entonces tenemos la misma posibilidad de que aparezcan todos los números en el intervalo 0-32700. Observe que solo 100 de ellos son menores o iguales que 99, que es el requisito para no solo devolver 0. Entonces, tenemos 100/32700 == 1/327 posibilidades de no obtener 0. Tenemos un generador de números aleatorios que devuelve prácticamente siempre 0 para esta entrada. En general, cuanto más lejos esté, a cualquiera de ambas direcciones, de 32700 elementos en el rango, menos aleatoriamente se comportará.

Como es una práctica común burlarse de Microsoft por su mala arquitectura tecnológica, este es uno de los mejores.
Algunos de los productos de Microsoft son tan inestables que si se bloquean, significa “La operación se completó con éxito” 🙂

La razón de tales mensajes es que la API de Windows no informa errores en un método consistente. Algunas veces usa el valor de retorno, como un código de error, y otras veces necesita llamar a una función API específica (GetLastError) para obtener una descripción del error. Si se informa un error en un mecanismo y usted le pregunta al otro, el resultado es: “No tengo ningún error que darle”, que es lo que dice el mensaje anterior.

Esta historia no es tanto un error gracioso, sino una respuesta extraña a un error. Y lamentablemente, no es tan raro como debería ser.

Como nuevo empleado, me pusieron a cargo del mantenimiento de un producto establecido.
Leyendo las guías de instalación y las secciones de solución de problemas de nuestra documentación para el cliente, encontré instrucciones detalladas sobre cómo el instalador / solucionador de problemas debe ir a la sección de recursos de la computadora y aumentar la cantidad de archivos que un programa puede tener abiertos a la vez a un tamaño ridículamente grande. número.

Como mi primer acto como programador de mantenimiento, solo me tomó 5 minutos desde la primera vez que vi el código para tomar nota de todas las veces que el programa abría archivos, todas las veces que cerraba archivos y la ruta muy obvia a través del software donde se abrió un archivo y nunca se cerró, y el lugar correcto para insertar una nueva declaración de archivo cerrado.

Debe haber llevado al programador original mucho, muchas veces más trabajo documentar una solución al error que simplemente solucionarlo.