Depuración

En ingeniería , la depuración es el proceso de encontrar la causa raíz de los errores y sus soluciones alternativas y posibles arreglos .

En el caso del software , las tácticas de depuración pueden incluir depuración interactiva , análisis del flujo de control , análisis de archivos de registro , monitoreo a nivel de aplicación o sistema , volcados de memoria y creación de perfiles . Muchos lenguajes de programación y herramientas de desarrollo de software también ofrecen programas para ayudar en la depuración, conocidos como depuradores .

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]

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.

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 general, los lenguajes de programación de alto nivel , como Java , facilitan la depuración, ya que tienen características como el manejo de excepciones y la verificación de tipos que hacen que las fuentes reales de comportamiento errático sean más fáciles de detectar. En lenguajes de programación como C o ensamblador , los errores pueden causar problemas silenciosos, como corrupción de memoria , y a menudo es difícil ver dónde ocurrió el problema inicial. En esos casos, pueden ser necesarias herramientas de depuración de memoria .

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.

Para depurar hardware electrónico (por ejemplo, hardware de computadora ), así como software de bajo nivel (por ejemplo, BIOS , controladores de dispositivos ) y firmware , a menudo se utilizan instrumentos como osciloscopios , analizadores lógicos o emuladores en circuito (ICE), solos o en combinación. Un ICE puede realizar muchas de las tareas típicas de un depurador de software en software y firmware de bajo nivel .

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 ]}

• 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]

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.).

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]}

• 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.

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)