Una entrada del registro de la computadora del Mark II, con una polilla pegada en la página
El término bug , en el sentido de defecto, se remonta al menos a 1878 cuando Thomas Edison escribió "pequeños fallos y dificultades" en sus inventos como "Bugs".
Una historia popular de la década de 1940 es la de la almirante Grace Hopper . [1] Mientras trabajaba en una computadora Mark II en la Universidad de Harvard, sus asociados descubrieron una polilla atrapada en un relé que impedía el funcionamiento y escribieron en un libro de registro "Primer caso real de un error encontrado". Aunque probablemente se trate de una broma , que combina los dos significados de error (biológico y defecto), la historia indica que el término se usaba en el campo de la informática en ese momento.
De manera similar, el término depuración se utilizó en aeronáutica antes de entrar en el mundo de las computadoras. Una carta de J. Robert Oppenheimer , director del Proyecto Manhattan de la bomba atómica de la Segunda Guerra Mundial en Los Alamos, utilizó el término en una carta al Dr. Ernest Lawrence en UC Berkeley, fechada el 27 de octubre de 1944, [2] con respecto al reclutamiento de personal técnico adicional. La entrada del Oxford English Dictionary para depurar utiliza el término depuración en referencia a las pruebas de motores de aviones en un artículo de 1945 en el Journal of the Royal Aeronautical Society. Un artículo en "Airforce" (junio de 1945, p. 50) se refiere a la depuración de cámaras de aviones.
El artículo fundamental de Gill [3] en 1951 es la primera discusión en profundidad sobre errores de programación, pero no utiliza el término error o depuración .
En la biblioteca digital de la ACM , el término depuración se utiliza por primera vez en tres artículos de las Reuniones Nacionales de la ACM de 1952. [4] [5] [6] Dos de los tres utilizan el término entre comillas.
En 1963, la depuración era un término lo suficientemente común como para ser mencionado de pasada sin explicación en la página 1 del manual del CTSS . [7]
Alcance
A medida que el software y los sistemas electrónicos se han vuelto más complejos, las diversas técnicas de depuración comunes se han ampliado con más métodos para detectar anomalías, evaluar el impacto y programar parches de software o actualizaciones completas para un sistema. Las palabras "anomalía" y "discrepancia" se pueden utilizar, como términos más neutrales , para evitar las palabras "error" y "defecto" o "bug" donde podría haber una implicación de que todos los llamados errores , defectos o bugs deben corregirse (a toda costa). En cambio, se puede realizar una evaluación de impacto para determinar si los cambios para eliminar una anomalía (o discrepancia ) serían rentables para el sistema, o tal vez una nueva versión programada podría hacer que el cambio o los cambios fueran innecesarios. No todos los problemas son críticos para la seguridad o la misión en un sistema. Además, es importante evitar la situación en la que un cambio podría ser más molesto para los usuarios, a largo plazo, que vivir con el problema o los problemas conocidos (donde la "cura sería peor que la enfermedad"). Basar las decisiones en la aceptabilidad de algunas anomalías puede evitar una cultura de mandato de "cero defectos", donde las personas podrían verse tentadas a negar la existencia de problemas para que el resultado parezca cero defectos . Si se consideran los problemas colaterales, como la evaluación del impacto de costo versus beneficio, se ampliarán las técnicas de depuración para determinar la frecuencia de las anomalías (con qué frecuencia ocurren los mismos "errores") para ayudar a evaluar su impacto en el sistema en general.
Herramientas
La depuración en consolas de videojuegos generalmente se realiza con hardware especial como esta unidad de depuración de Xbox destinada a desarrolladores.
La depuración varía en complejidad, desde la reparación de errores simples hasta la realización de tareas largas y tediosas de recopilación de datos, análisis y programación de actualizaciones. La habilidad de depuración del programador puede ser un factor importante en la capacidad de depurar un problema, pero la dificultad de la depuración de software varía en gran medida con la complejidad del sistema y también depende, en cierta medida, del lenguaje de programación utilizado y de las herramientas disponibles, como los depuradores . Los depuradores son herramientas de software que permiten al programador supervisar la ejecución de un programa, detenerlo, reiniciarlo, establecer puntos de interrupción y cambiar valores en la memoria. El término depurador también puede referirse a la persona que realiza la depuración.
En determinadas situaciones, las herramientas de software de propósito general que son específicas del lenguaje por naturaleza pueden ser muy útiles. Estas toman la forma de herramientas de análisis de código estático . Estas herramientas buscan un conjunto muy específico de problemas conocidos, algunos comunes y otros poco comunes, dentro del código fuente, concentrándose más en la semántica (por ejemplo, el flujo de datos) en lugar de la sintaxis, como lo hacen los compiladores e intérpretes.
Existen herramientas comerciales y gratuitas para varios lenguajes; algunas afirman ser capaces de detectar cientos de problemas diferentes. Estas herramientas pueden ser extremadamente útiles cuando se comprueban árboles de código fuente muy grandes, donde no es práctico hacer recorridos de código. Un ejemplo típico de un problema detectado sería una desreferencia de variable que ocurre antes de que se le asigne un valor a la variable. Como otro ejemplo, algunas de estas herramientas realizan una verificación de tipos estricta cuando el lenguaje no lo requiere. Por lo tanto, son mejores para localizar posibles errores en código que es sintácticamente correcto. Pero estas herramientas tienen una reputación de falsos positivos, donde el código correcto se marca como dudoso. El antiguo programa lint de Unix es un ejemplo temprano.
El proceso de depuración normalmente comienza con la identificación de los pasos para reproducir el problema. Esta puede ser una tarea nada trivial, en particular con procesos paralelos y algunos Heisenbugs , por ejemplo. El entorno específico del usuario y el historial de uso también pueden dificultar la reproducción del problema.
Una vez que se reproduce el error, es posible que sea necesario simplificar la entrada del programa para facilitar su depuración. Por ejemplo, un error en un compilador puede hacer que se bloquee al analizar un archivo fuente grande. Sin embargo, después de la simplificación del caso de prueba, solo unas pocas líneas del archivo fuente original pueden ser suficientes para reproducir el mismo error. La simplificación se puede realizar de forma manual utilizando un enfoque de divide y vencerás , en el que el programador intenta eliminar algunas partes del caso de prueba original y luego verifica si el problema aún ocurre. Al depurar en una GUI , el programador puede intentar omitir alguna interacción del usuario de la descripción del problema original para verificar si las acciones restantes son suficientes para provocar que se produzca el error.
Una vez que el caso de prueba se ha simplificado lo suficiente, un programador puede utilizar una herramienta de depuración para examinar los estados del programa (valores de las variables, más la pila de llamadas ) y rastrear el origen de los problemas. Como alternativa, se puede utilizar el rastreo . En casos simples, el rastreo consiste simplemente en unas pocas sentencias de impresión que muestran los valores de las variables en puntos específicos durante la ejecución del programa. [ cita requerida ]
Técnicas
La depuración interactiva utiliza herramientas de depuración que permiten que la ejecución de un programa se procese paso a paso y se pause para inspeccionar o modificar su estado. Las subrutinas o llamadas de función normalmente se pueden ejecutar a toda velocidad y pausarse nuevamente al regresar a su llamador, o pueden ejecutarse paso a paso, o cualquier combinación de estas opciones. Se pueden instalar puntos de ajuste que permitan la ejecución a toda velocidad de código que no se sospecha que tenga fallas y luego detenerse en un punto que sí las tenga. Colocar un punto de ajuste inmediatamente después del final de un bucle de programa es una forma conveniente de evaluar el código que se repite. Los puntos de vigilancia están comúnmente disponibles, donde la ejecución puede continuar hasta que cambie una variable particular, y los puntos de captura que hacen que el depurador se detenga para ciertos tipos de eventos del programa, como excepciones o la carga de una biblioteca compartida.
La depuración o el seguimiento de la impresión es el acto de observar (en vivo o grabado) las declaraciones de seguimiento o las declaraciones de impresión que indican el flujo de ejecución de un proceso y la progresión de los datos. El seguimiento se puede realizar con herramientas especializadas (como con el seguimiento de GDB) o mediante la inserción de declaraciones de seguimiento en el código fuente. Esto último a veces se denominaDepuración de printf , debido al uso de laprintfen C. Este tipo de depuración se activaba con el comando TRON en las versiones originales delBASIC. TRON significaba "Trace On" (Trazar activado). TRON hacía que los números de línea de cada línea de comando BASIC se imprimieran a medida que se ejecutaba el programa.
El seguimiento de la actividad es similar al seguimiento (arriba), pero en lugar de seguir la ejecución del programa una instrucción o función a la vez, sigue la actividad del programa en función de la cantidad total de tiempo empleado por el procesador/CPU en ejecutar segmentos particulares de código. Esto se presenta típicamente como una fracción del tiempo de ejecución del programa empleado en procesar instrucciones dentro de direcciones de memoria definidas (programas de código de máquina) o ciertos módulos de programa (lenguaje de alto nivel o programas compilados). Si se demuestra que el programa que se está depurando está gastando una fracción excesiva de su tiempo de ejecución dentro de las áreas rastreadas, esto podría indicar una asignación incorrecta del tiempo del procesador causada por una lógica de programa defectuosa, o al menos una asignación ineficiente del tiempo del procesador que podría beneficiarse de esfuerzos de optimización.
La depuración remota es el proceso de depuración de un programa que se ejecuta en un sistema diferente al del depurador. Para iniciar la depuración remota, un depurador se conecta a un sistema remoto a través de un enlace de comunicaciones, como una red de área local. El depurador puede entonces controlar la ejecución del programa en el sistema remoto y recuperar información sobre su estado.
La depuración post-mortem es la depuración del programa después de que ya se ha bloqueado . Las técnicas relacionadas a menudo incluyen varias técnicas de seguimiento como examinar archivos de registro, generar una pila de llamadas en el momento del bloqueo, [8] y analizar el volcado de memoria (o volcado de núcleo ) del proceso bloqueado. El volcado del proceso podría obtenerse automáticamente por el sistema (por ejemplo, cuando el proceso ha terminado debido a una excepción no controlada), o por una instrucción insertada por el programador, o manualmente por el usuario interactivo.
Algoritmo de la "valla del lobo": Edward Gauss describió este algoritmo simple pero muy útil y ahora famoso en un artículo de 1982 para Communications of the ACM de la siguiente manera: "Hay un lobo en Alaska; ¿cómo lo encuentras? Primero construye una valla en el medio del estado, espera a que el lobo aúlle, determina de qué lado de la valla está. Repite el proceso solo en ese lado, hasta que llegues al punto donde puedas ver al lobo". [9] Esto se implementa, por ejemplo, en el sistema de control de versiones Git como el comando git bisect , que usa el algoritmo anterior para determinar qué confirmación introdujo un error en particular.
La depuración mediante grabación y reproducción es una técnica que permite crear una grabación de la ejecución de un programa (por ejemplo, utilizando la herramienta de depuración gratuita rr de Mozilla , que permite la depuración/ejecución reversible), que se puede reproducir y depurar de forma interactiva. Resulta útil para la depuración remota y la depuración de defectos intermitentes, no deterministas y otros defectos difíciles de reproducir.
La depuración de viajes en el tiempo es el proceso de retroceder en el tiempo a través del código fuente (por ejemplo, utilizando Undo LiveRecorder ) para comprender lo que sucede durante la ejecución de un programa de computadora; para permitir que los usuarios interactúen con el programa; para cambiar el historial si se desea y para observar cómo responde el programa.
Depuración delta : una técnica para automatizar la simplificación de casos de prueba. [10] : p.123
Saff Squeeze : una técnica para aislar fallas dentro de la prueba mediante la inserción progresiva de partes de la prueba que fallan. [11] [12]
Seguimiento de causalidad : existen técnicas para rastrear las cadenas de causa y efecto en el cálculo. [13] Esas técnicas se pueden adaptar para errores específicos, como desreferencias de punteros nulos. [14]
Corrección automática de errores
La corrección automática de errores es la reparación automática de errores de software sin la intervención de un programador humano. [15] [16] [17] También se conoce comúnmente como generación automática de parches , reparación automática de errores o reparación automática de programas . [17] El objetivo típico de estas técnicas es generar automáticamente parches correctos para eliminar errores en programas de software sin causar regresión del software . [18]
Depuración de sistemas integrados
A diferencia del entorno de diseño de software informático de propósito general, una característica principal de los entornos integrados es la gran cantidad de plataformas diferentes disponibles para los desarrolladores (arquitecturas de CPU, proveedores, sistemas operativos y sus variantes). Los sistemas integrados, por definición, no son diseños de propósito general: normalmente se desarrollan para una sola tarea (o un pequeño rango de tareas) y la plataforma se elige específicamente para optimizar esa aplicación. Este hecho no solo dificulta la vida a los desarrolladores de sistemas integrados, sino que también dificulta la depuración y la prueba de estos sistemas, ya que se necesitan diferentes herramientas de depuración para diferentes plataformas.
A pesar del desafío de la heterogeneidad mencionado anteriormente, se han desarrollado algunos depuradores comercialmente, así como prototipos de investigación. Ejemplos de soluciones comerciales provienen de Green Hills Software , [19] Lauterbach GmbH [20] y MPLAB-ICD de Microchip (para depurador en circuito). Dos ejemplos de herramientas de prototipos de investigación son Aveksha [21] y Flocklab. [22] Todos ellos aprovechan una funcionalidad disponible en procesadores integrados de bajo costo, un módulo de depuración en chip (OCDM), cuyas señales se exponen a través de una interfaz JTAG estándar . Se comparan en función de cuánto cambio se necesita en la aplicación y la tasa de eventos que pueden seguir.
Además de la tarea típica de identificar errores en el sistema, la depuración de sistemas integrados también busca recopilar información sobre los estados operativos del sistema que luego puede usarse para analizar el sistema: para encontrar formas de mejorar su rendimiento u optimizar otras características importantes (por ejemplo, consumo de energía, confiabilidad, respuesta en tiempo real, etc.).
Anti-depuración
La antidepuración es "la implementación de una o más técnicas dentro del código informático que dificulta los intentos de ingeniería inversa o depuración de un proceso objetivo". [23] Los editores reconocidos la utilizan activamente en esquemas de protección contra copias , pero también la utiliza el malware para complicar su detección y eliminación. [24] Las técnicas utilizadas en la antidepuración incluyen:
Basado en API: verifique la existencia de un depurador utilizando información del sistema
Basado en excepciones: verifique si se interfiere con las excepciones
Bloques de procesos y subprocesos: comprueba si se han manipulado los bloques de procesos y subprocesos
Código modificado: comprobar si hay modificaciones de código realizadas por un depurador que maneja puntos de interrupción del software
Basado en hardware y registros: verifique los puntos de interrupción del hardware y los registros de la CPU
Tiempo y latencia: verifica el tiempo que tarda la ejecución de las instrucciones
Detección y penalización del depurador [24]
Un ejemplo temprano de anti-depuración existía en las primeras versiones de Microsoft Word que, si se detectaba un depurador, generaba un mensaje que decía: "El árbol del mal da frutos amargos. Ahora se está destruyendo el disco del programa", después de lo cual hacía que la unidad de disquete emitiera ruidos alarmantes con la intención de asustar al usuario para que no lo intentara nuevamente. [25] [26]
^ "InfoWorld 5 de octubre de 1981". 5 de octubre de 1981. Archivado desde el original el 18 de septiembre de 2019 . Consultado el 17 de julio de 2019 .
^ "Copia archivada". Archivado desde el original el 21 de noviembre de 2019. Consultado el 17 de diciembre de 2019 .{{cite web}}: CS1 maint: archived copy as title (link)
^ S. Gill, The Diagnosis of Mistakes in Programmes on the EDSAC Archivado el 6 de marzo de 2020 en Wayback Machine , Actas de la Royal Society of London. Serie A, Ciencias matemáticas y físicas, vol. 206, n.º 1087 (22 de mayo de 1951), págs. 538-554
^ Robert VD Campbell, Evolución de la computación automática Archivado el 18 de septiembre de 2019 en Wayback Machine , Actas de la reunión nacional de la ACM de 1952 (Pittsburgh), págs. 29-32, 1952.
^ Alex Orden, Solución de sistemas de desigualdades lineales en una computadora digital, Actas de la reunión nacional ACM de 1952 (Pittsburgh), pág. 91-95, 1952.
^ Howard B. Demuth, John B. Jackson, Edmund Klein, N. Metropolis, Walter Orvedahl, James H. Richardson, MANIAC doi=10.1145/800259.808982, Actas de la reunión nacional de la ACM de 1952 (Toronto), págs. 13-16
^ El sistema de tiempo compartido compatible Archivado el 27 de mayo de 2012 en Wayback Machine , MIT Press, 1963
^ "Depuración post mortem". Archivado desde el original el 17 de diciembre de 2019. Consultado el 17 de diciembre de 2019 .
^ EJ Gauss (1982). "Pracniques: El algoritmo 'Wolf Fence' para depuración". Comunicaciones de la ACM . 25 (11): 780. doi : 10.1145/358690.358695 . S2CID 672811.
^ Zeller, Andreas (2005). Por qué fallan los programas: una guía para la depuración sistemática . Morgan Kaufmann. ISBN1-55860-866-4.
^ "Kent Beck, Hit 'em High, Hit 'em Low: Regression Testing and the Saff Squeeze" (Pégales alto, pégales bajo: pruebas de regresión y la presión sobre el papel). Archivado desde el original el 11 de marzo de 2012.
^ Rainsberger, JB (28 de marzo de 2022). "The Saff Squeeze". The Code Whisperer . Consultado el 28 de marzo de 2022 .
^ Zeller, Andreas (1 de noviembre de 2002). "Aislamiento de cadenas de causa y efecto de programas informáticos". Notas de ingeniería de software de ACM SIGSOFT . 27 (6): 1–10. doi :10.1145/605466.605468. ISSN 0163-5948. S2CID 12098165.
^ Bond, Michael D.; Nethercote, Nicholas; Kent, Stephen W.; Guyer, Samuel Z.; McKinley, Kathryn S. (2007). "Tracking bad apples" (Rastreando manzanas podridas). Actas de la 22.ª conferencia anual ACM SIGPLAN sobre sistemas y aplicaciones de programación orientada a objetos - OOPSLA '07 . pág. 405. doi :10.1145/1297027.1297057. ISBN9781595937865. Número de identificación del sujeto 2832749.
^ Rinard, Martin C. (2008). "Perspectiva técnica. Corrección de errores de programas". Comunicaciones de la ACM . 51 (12): 86. doi :10.1145/1409360.1409381. S2CID 28629846.
^ Harman, Mark (2010). "Técnicas de aplicación de parches automatizada". Comunicaciones de la ACM . 53 (5): 108. doi :10.1145/1735223.1735248. S2CID 9729944.
^ ab Gazzola, Luca; Micucci, Daniela; Mariani, Leonardo (2019). "Reparación automática de software: una encuesta" (PDF) . IEEE Transactions on Software Engineering . 45 (1): 34–67. doi : 10.1109/TSE.2017.2755013 . hdl :10281/184798. S2CID 57764123.
^ Tan, Shin Hwei; Roychoudhury, Abhik (2015). "relifix: Reparación automatizada de regresiones de software". 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering . IEEE. págs. 471–482. doi :10.1109/ICSE.2015.65. ISBN .978-1-4799-1934-5.S2CID 17125466 .
^ "Depurador de hardware de SuperTrace Probe". www.ghs.com . Archivado desde el original el 1 de diciembre de 2017. Consultado el 25 de noviembre de 2017 .
^ "Herramientas de depuración y seguimiento en tiempo real". www.lauterbach.com . Archivado desde el original el 25 de enero de 2022 . Consultado el 5 de junio de 2020 .
^ Tancreti, Matthew; Hossain, Mohammad Sajjad; Bagchi, Saurabh; Raghunathan, Vijay (2011). "Aveksha". Actas de la 9.ª Conferencia de la ACM sobre sistemas de sensores integrados en red . SenSys '11. Nueva York, NY, EE. UU.: ACM. págs. 288–301. doi :10.1145/2070942.2070972. ISBN .9781450307185. Número de identificación S2C14769602.
^ Lim, Roman; Ferrari, Federico; Zimmerling, Marco; Walser, Christoph; Sommer, Philipp; Beutel, Jan (2013). "FlockLab". Actas de la 12.ª conferencia internacional sobre procesamiento de información en redes de sensores . IPSN '13. Nueva York, NY, EE. UU.: ACM. págs. 153–166. doi :10.1145/2461381.2461402. ISBN .9781450319591.S2CID 447045 .
^ Shields, Tyler (2008-12-02). «Serie Anti-Debugging – Parte I». Veracode . Archivado desde el original el 2016-10-19 . Consultado el 2009-03-17 .
^ ab "Protección de software mediante antidepuración Michael N Gagnon, Stephen Taylor, Anup Ghosh" (PDF) . Archivado desde el original (PDF) el 2011-10-01 . Consultado el 2010-10-25 .
^ "Microsoft Word para DOS 1.15". Archivado desde el original el 14 de mayo de 2013. Consultado el 22 de junio de 2013 .
Lectura adicional
Agans, David J. (2002). Depuración: las nueve reglas indispensables para encontrar incluso los problemas de software y hardware más difíciles de detectar. AMACOM. ISBN 0-8144-7168-4.
Blunden, Bill (2003). Software Exorcism: Un manual para depurar y optimizar código heredado . APress. ISBN 1-59059-234-4.
Ford, Ann R.; Teorey, Toby J. (2002). Depuración práctica en C++. Prentice Hall. ISBN 0-13-065394-2.
Grötker, Thorsten; Holtmann, Ulrich; Keding, Holger; Wloka, Markus (2012). La guía del desarrollador para la depuración, segunda edición . Crear espacio. ISBN 978-1-4701-8552-7.
Metzger, Robert C. (2003). Depuración mediante el pensamiento: un enfoque multidisciplinario . Editorial digital. ISBN 1-55558-307-5.
Myers, Glenford J (2004). El arte de las pruebas de software. John Wiley & Sons Inc. ISBN 0-471-04328-1.
Robbins, John (2000). Depuración de aplicaciones . Microsoft Press. ISBN 0-7356-0886-5.
Telles, Matthew A.; Hsieh, Yuan (2001). La ciencia de la depuración . El grupo Coriolis. ISBN 1-57610-917-8.
Vostokov, Dmitry (2008). Antología de análisis de volcados de memoria, volumen 1. OpenTask. ISBN 978-0-9558328-0-2.
Zeller, Andreas (2009). Por qué fallan los programas, segunda edición: una guía para la depuración sistemática . Morgan Kaufmann. ISBN 978-0-1237-4515-6.
Peggy Aldrich Kidwell, En busca del esquivo error informático, IEEE Annals of the History of Computing, 1998.
Enlaces externos
Wikiquote tiene citas relacionadas con Depuración .
El Wikilibro Principios de programación informática tiene una página sobre el tema: Depuración
Patrones de análisis de volcados de memoria: artículos detallados sobre el análisis y la búsqueda de errores en volcados de memoria
Lo esencial de la depuración: cómo mejorar sus habilidades de depuración
Depuración basada en complementos para sistemas integrados
Pruebas y depuración de sistemas integrados: generación de entradas digitales: resultados de una encuesta sobre pruebas y depuración de sistemas integrados, Byte Paradigm (archivado desde el original el 12 de enero de 2012)
