Esta es una pregunta inteligente que exige una respuesta más completa. La respuesta simple es NO porque, como dice Amir, “surgen nuevos errores a medida que continúa la innovación”.
Sin embargo, esto no significa que no pueda enumerar (e incluso detectar automáticamente en muchos casos) categorías de errores comunes. Se puede utilizar un “simulador de conjunto de instrucciones” o hipervisor (si está disponible) para imitar el funcionamiento de un procesador central (o componentes principales del mismo). Básicamente utiliza la CPU real para realizar las instrucciones de código de máquina equivalentes, pero realiza verificaciones previas de ejecución adicionales de antemano. Por lo general, utiliza un conjunto completo de pseudo registros y contador de programas (en su propia memoria), ya que los registros reales son utilizados por el software de monitoreo en sí. Las instrucciones utilizadas por el programa de monitoreo pueden no ser las mismas que habría usado la CPU (por ejemplo: una operación de registro a registro podría implicar copiar un pseudo registro a otro pseudo registro en la memoria. El programa de monitoreo también “recuerda “la pista a través del programa (a cualquier profundidad que se requiera, por ejemplo, memoria alterada, registros alterados y otras variables de estado). Esta información se retiene para la ocasión en que puede ocurrir un error. Tal simulador de conjunto de instrucciones fue el” motor de ejecución “en mis propios sistemas de depuración interactiva conocidos como” OLIVER “(Wikipedia” IBM OLIVER – Prueba / depuración interactiva CICS) y “SIMON” para programas por lotes.
Seis ejemplos simples para comenzar:
Bucles “infinitos”
Hay cuatro mecanismos que se pueden usar no solo para “detectar” un bucle infinito, sino para descubrir por qué el programa ingresó al bucle.
Errores: –
1. Umbral de recuento de instrucciones alcanzado (límite preestablecido)
2, fuera de tiempo (límite preestablecido)
3. Umbral de E / S alcanzado (límite predeterminado por dispositivo)
4. El uso excesivo de recursos puede llevar a “falta de memoria” (límite preestablecido) o similar para otros tipos de recursos.
- ¿Es la desigualdad de género en tecnología realmente un problema? Si es así, ¿alguien puede proporcionar ejemplos?
- Cómo mejorar la calidad del producto desde el punto de vista del control de calidad
- ¿Cuáles son las empresas de desarrollo de software más innovadoras?
- ¿Cuáles son las ventajas y desventajas de UML?
- Cómo obtener inversión para mi software
“Rama salvaje
En un entorno de programa particular, generalmente hay un número reconocido de ubicaciones que son “válidas”
1. de una ubicación en un programa a otra dentro del mismo procedimiento
2. al punto de entrada de un nuevo procedimiento
3. al punto de retorno de ese procedimiento
4. a una lista “fija” de puntos de entrada reconocidos del sistema operativo
5. al punto de retorno de esa llamada al sistema
Por lo tanto, una rama a CUALQUIER ubicación no reconocida en la memoria constituye una “rama salvaje” y potencialmente un error que conduce a consecuencias imprevistas.
El seguimiento del programa se puede utilizar para determinar por qué se intentó la rama y el estado inmediatamente anterior al intento fallido.
Llamada ilegal del sistema operativo (o API)
Si un programa monitoreado intenta iniciar una llamada al sistema operativo (o alguna API) con parámetros incorrectos, el programa de monitoreo a menudo puede detectar esto antes de realizar la llamada.
Errores: –
1. Intente leer en ubicaciones de memoria “no propias”
2. Intente llamar a una función del sistema operativo sin autorización o en el modo incorrecto
Cheques más complejos
Para proporcionar protección de memoria, el sistema de monitoreo debe mantener una lista clara de ubicaciones de memoria válidas y “propias” a medida que continúa la ejecución del programa.
A medida que se obtiene cada nuevo segmento de memoria asignada, la lista debe actualizarse. Luego, antes de permitir la ejecución, el programa de monitoreo debe verificar si la memoria que está por modificarse está en esa lista. Tampoco debe estar en una lista de memoria específicamente excluida (que puede variar según el estado del programa y la autorización actual).
Errores: –
1. Intente alterar la memoria fuera de la lista “propiedad”
2. Intente alterar la memoria en una lista de acceso restringido
Errores lógicos
Si un programa monitoreado produce una salida incorrecta, un sistema interactivo de prueba / depuración debe permitir que se solicite una “pausa” (/ punto de interrupción) en cualquier punto durante la ejecución para examinar el contenido del registro o la memoria y posiblemente corregirlos.
Características requeridas: –
1. Pausa incondicional en alguna ubicación predefinida
2. Pausa condicionalmente (por ejemplo, cuando la memoria cambió de 0 a 1)
3. Cambie el registro o la memoria y continúe
4. Ejecute una declaración (o instrucción única) y observe el resultado
5. Rastreo desde el punto A en el programa hasta el punto B en el programa
En este caso, el programa de monitoreo proporciona el mecanismo para que el programador detecte el error lógico manualmente en el menor tiempo.
Problemas de rendimiento
Al mantener un recuento de instrucciones y otras medidas de uso de recursos, un programa de monitoreo puede mostrar “puntos críticos” (recuentos altos de ejecución) y resaltar secciones lentas involuntarias de código o E / S excesivas.
Espero que esta respuesta ilustre que, aunque de hecho hay una gran lista de posibles errores de programa, esa lista puede reducirse a algunas categorías bien definidas que pueden detectarse automáticamente o detectarse con un poco de ayuda de un hipervisor diseñado adecuadamente.