¿Qué es un schrödinbug?

Esta página wiki dice:

Un schrödinbug es un error que se manifiesta solo después de que alguien que lee el código fuente o usa el programa de una manera inusual se da cuenta de que nunca debería haber funcionado, en ese momento el programa deja de funcionar rápidamente para todos hasta que se arregla. El archivo Jargon agrega: "Aunque ... esto suena imposible, sucede; algunos programas han albergado schrödinbugs latentes durante años".

De lo que se habla es muy vago.

¿Puede alguien dar un ejemplo de cómo es un schrödinbug (como en una situación ficticia / de la vida real)?

En mi experiencia, el patrón es este:

• El sistema funciona, a menudo durante años.
• Se informa un error
• El desarrollador investiga el error y encuentra un poco de código que parece estar completamente defectuoso y declara que "nunca podría haber funcionado"
• El error se soluciona y la leyenda del código que nunca podría haber funcionado (pero funcionó durante años) crece

Seamos lógicos aquí. Código que nunca podría haber funcionado ... nunca podría haber funcionado . Si se hizo el trabajo a continuación, la declaración es falsa.

Así que voy a decir que un error exactamente como se describe (es decir, observar que el código defectuoso deja de funcionar) no tiene sentido.

En realidad, lo que sucedió es una de dos cosas:

1) El desarrollador no ha entendido completamente el código . En este caso, el código generalmente es un desastre y en algún lugar tiene una sensibilidad importante pero no obvia a alguna condición externa (por ejemplo, una versión o configuración específica del sistema operativo que gobierna cómo funciona alguna función de alguna manera menor pero significativa). Esta condición externa se altera (por ejemplo, mediante una actualización o cambio del servidor que se cree que no está relacionado) y al hacerlo hace que el código se rompa.

Luego, el desarrollador mira el código y, sin comprender el contexto histórico o no tener tiempo para rastrear cada posible dependencia y escenario, declaró que nunca podría haber funcionado y lo reescribe.

En esta situación, lo que hay que entender aquí es que la idea de que "nunca podría haber funcionado" es probablemente falsa (porque lo hizo).

Eso no quiere decir que reescribirlo sea algo malo; a menudo no lo es, mientras que es bueno saber exactamente qué estaba mal, a menudo lleva mucho tiempo y reescribir la sección de código a menudo es más rápido y le permite estar seguro de que ha solucionado los problemas.

2) En realidad nunca funcionó, nadie lo ha notado . Esto es sorprendentemente común, particularmente en sistemas grandes. En este caso, alguien nuevo comienza y comienza a mirar las cosas de la forma en que nadie lo hacía antes, o un proceso de negocio cambia y trae un caso secundario previamente menor al proceso principal, y algo que nunca funcionó realmente (o funcionó algunos pero no todos el tiempo) se encuentra y se informa.

El desarrollador lo mira y declara "nunca podría haber funcionado", pero los usuarios dicen "tonterías, lo hemos estado usando durante años" y tienen razón, pero son algo que consideran irrelevante (y generalmente no mencionan hasta que desarrollador encuentra el estado exacto momento en el que se van "oh sí, nosotros hacemos que ahora y no lo hicieron antes") ha cambiado.

Aquí el desarrollador tiene razón: nunca podría haber funcionado y nunca funcionó.

Pero en cualquier caso, una de las dos cosas es cierta:

• La afirmación "nunca podría haber funcionado" es cierta y nunca ha funcionado: la gente pensaba que sí
• Funcionó y la afirmación "nunca podría haber funcionado" es falsa y se debe a una falta (generalmente razonable) de comprensión del código y sus dependencias

Como todos mencionan un código que nunca debería haber funcionado, les daré un ejemplo con el que me encontré hace unos 8 años en un proyecto VB3 que se estaba convirtiendo a .net. Desafortunadamente, el proyecto tuvo que mantenerse actualizado hasta que se completó la versión .net, y yo fui el único que incluso comprendió remotamente VB3.

Había una función muy importante que se llamaba cientos de veces para cada cálculo: calcular el interés mensual para los planes de pensiones a largo plazo. Reproduciré las partes interesantes.

Function CalculateMonthlyInterest([...], IsYearlyInterestMode As Boolean, [...]) As Double
    [about 30 lines of code]
    If IsYearlyInterestMode Then
        [about 30 lines of code]
        If Not IsYearlyInterestMode Then
            [about 30 lines of code (*)]
        End If
    End If
End Function

La parte marcada con una estrella tenía el código más importante; fue la única parte que realizó el cálculo real. Claramente esto nunca debería haber funcionado, ¿verdad?

Tomó mucha depuración, pero finalmente encontré la causa: IsYearlyInterestModeera Truey Not IsYearlyInterestModetambién era cierto. Esto se debe a que, en algún punto de la línea, alguien lo convierte en un número entero, luego, en una función que se supone que lo establece en verdadero, lo incrementa (si es 0 False, se establecería en 1, que es VB True, por lo que puedo ver la lógica allí), luego vuélvalo a un booleano. Y me quedé con una condición que nunca puede suceder y, sin embargo, sucede todo el tiempo.

No conozco un ejemplo del mundo real, pero para simplificarlo con una situación de ejemplo:

• Un error no se nota por un tiempo, porque la aplicación no ejecuta el código en condiciones que hacen que falle.
• Alguien lo nota haciendo algo fuera del uso normal (o inspeccionando la fuente).
• Ahora que se notó el error, la aplicación falla hasta condiciones normales también, hasta que se corrige el error.

Esto puede suceder porque el error corromperá algún estado de la aplicación que causará fallas en las condiciones normales anteriores.

Un ejemplo de la vida real. No puedo mostrar el código, pero la mayoría de la gente se relacionará con esto.

Tenemos una gran biblioteca interna de funciones de utilidad donde trabajo. Un día estoy buscando una función para hacer una cosa en particular, y Frobnicate()trato de usarla. Uh-oh: resulta que Frobnicate()siempre devuelve un código de error.

Al profundizar en la implementación, encuentro algunos errores lógicos básicos Frobnicate()que hacen que siempre falle. En el control de origen, puedo ver que la función no se ha modificado desde que se escribió, lo que significa que la función nunca ha funcionado como se esperaba. ¿Por qué nadie se ha dado cuenta de esto? Busco en el resto del alistamiento de fuentes y encuentro que todas las personas que llaman Frobnicate()están ignorando el valor de retorno (y por lo tanto contienen errores sutiles propios). Si cambio esas funciones para verificar el valor de retorno como deberían, entonces también comienzan a fallar.

Este es un caso común de la condición # 2 que Jon Hopkins mencionó en su respuesta, y es deprimentemente común en grandes bibliotecas internas.

Aquí hay un Schrödinbug real que vi en algún código del sistema. Un demonio raíz necesita comunicarse con un módulo del núcleo. Entonces el código del núcleo crea algunos descriptores de archivo:

int pipeFDs[1];

luego configura la comunicación a través de una tubería que se conectará a una tubería con nombre:

int pipeResult = pipe(pipeFDs);

Esto no debería funcionar. pipe()escribe dos descriptores de archivo en la matriz, pero solo hay espacio para uno. Pero durante unos siete años se hizo el trabajo; la matriz se encontraba antes de un espacio no utilizado en la memoria que se convirtió en un descriptor de archivo.

Entonces, un día, tuve que portar el código a una nueva arquitectura. Dejó de funcionar y se descubrió el error que nunca debería haber funcionado.

Un corolario del Schrödinbug es el Heisenbug , que describe un error que desaparece (u ocasionalmente aparece) cuando se intenta investigar y / o solucionarlo.

Los Heisenbugs son pequeños monstruos inteligentes y míticos que corren y se esconden cuando se carga un depurador, pero salen de la carpintería una vez que dejas de mirar.

En realidad, estos parecen ser causados ​​por uno u otro de los siguientes:

• El impacto de esa optimización, donde el código compilado -DDEBUGse optimiza a un nivel diferente de la versión de lanzamiento
• diferencias sutiles de tiempo debido a que los buses de comunicación del mundo real o las interrupciones son sutilmente diferentes de las cargas simuladas "perfectas" simuladas

Ambos destacan la importancia de probar el código de lanzamiento en el equipo de lanzamiento, así como la prueba de unidad / módulo / sistema utilizando emuladores.

He visto algunos Schödinbugs y siempre por la misma razón:

La política de la compañía requería que todos supusieran usar un programa.
Nadie realmente lo usó (principalmente porque no había entrenamiento para ello).
Pero no pudieron decirle a la gerencia esto. Así que todos tenían que decir "He estado usando este programa durante 2 años y nunca encontré este error hasta hoy".
El programa nunca funcionó realmente, excepto por una minoría de usuarios (incluidos los desarrolladores que lo escribieron).

En un caso, el programa había sido objeto de muchas pruebas, pero no en la base de datos real (que se consideró demasiado sensible, por lo que se utilizó una versión falsa).

Tengo un ejemplo de mi propia historia, esto fue hace unos 25 años. Yo era un niño haciendo programación gráfica rudimentaria en Turbo Pascal. TP tenía una biblioteca llamada BGI que incluía algunas funciones que le permitían copiar una región de la pantalla en un bloque de memoria basado en puntero y luego borrarlo en otra parte. Combinado con xor-blitting en una pantalla en blanco y negro, podría usarse para hacer una animación simple.

Quería ir un paso más allá y hacer sprites. Escribí un programa que dibujó grandes bloques y controles para colorearlos, como lo hizo, los reprodujo como píxeles, produciendo un programa de dibujo simple para crear sprites, que luego podría copiar en la memoria. Solo había un problema, para usar estos sprites borrados, tendrían que guardarse en un archivo para que otros programas pudieran leerlos. Pero TP no tenía forma de serializar la asignación de memoria basada en puntero. Los manuales indicaron que no podían escribirse para archivar.

Se me ocurrió una pieza de código que, con éxito, escribió en el archivo. Y comencé a escribir un programa de prueba que borró un sprite de mi programa de dibujo en un segundo plano, en mi camino a crear un juego. Y funcionó muy bien. Al día siguiente, sin embargo, dejó de funcionar. No mostraba nada más que un desastre confuso. Nunca funcionó de nuevo. Creé un nuevo sprite, y funcionó perfectamente, hasta que no lo hizo, y fue un desastre confuso nuevamente.

Me llevó mucho tiempo, pero finalmente descubrí lo que estaba sucediendo. El programa de dibujo no estaba, como pensaba, guardando los datos de píxeles copiados en el archivo, estaba guardando el puntero en sí. Cuando el siguiente programa leyó el archivo, terminó con un puntero al mismo bloque de memoria, que todavía contenía lo que el último programa había escrito allí (esto estaba en MS-DOS, la administración de memoria era inexistente). Pero funcionó ... justo hasta que reiniciaste, o ejecutaste cualquier cosa que había reutilizado esa misma área de memoria, y luego tuviste un lío confuso porque estabas bloqueando un montón de datos completamente no relacionados con el bloque de memoria de video.

Nunca debería haber funcionado, ni siquiera debería haber funcionado (y en cualquier sistema operativo real no lo habría hecho), pero aún así funcionó, y una vez que se rompió, se mantuvo roto.

Esto sucede todo el tiempo cuando las personas usan depuradores.

El entorno de depuración es diferente del entorno de producción real, sin depurador.

Ejecutar con un depurador puede enmascarar cosas como desbordamientos de pila porque los marcos de pila del depurador enmascaran el error.

Nunca he visto un verdadero schrodinbug y no creo que puedan existir; encontrarlo no romperá las cosas.

Más bien, algo cambió que expuso un error que ha estado al acecho durante años. Lo que haya cambiado sigue cambiando y, por lo tanto, el error sigue apareciendo mientras que al mismo tiempo alguien lo encuentra.