Depuración

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

En el caso del software , las tácticas de depuración pueden incluir la depuración interactiva , el análisis del flujo de control , el análisis de archivos de registro , la monitorización a nivel de aplicación o sistema , los volcados de memoria y la creación de perfiles . Muchos lenguajes de programación y herramientas de desarrollo de software también ofrecen programas para facilitar 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ó "bugs" (errores y dificultades) en sus inventos.

Una anécdota 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 colegas descubrieron una polilla atascada en un relé que impedía su funcionamiento y escribieron en un cuaderno de bitácora: «Primer caso real de un error informático encontrado». Aunque probablemente se trate de una broma , que mezcla los dos significados de «bug» (biológico y defecto), la historia indica que el término se utilizaba en el campo de la informática en aquella época.

De manera similar, el término depuración se usaba en aeronáutica antes de entrar en el mundo de la informática . Una carta de J. Robert Oppenheimer , director del Proyecto Manhattan de la bomba atómica de la Segunda Guerra Mundial en Los Alamos, usó 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 debug usa el término debugging 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ág. 50) se refiere a la depuración de cámaras de aeronaves. 

El artículo fundamental de Gill ^{[ 3 ]} de 1951 es la primera discusión en profundidad sobre errores de programación, pero no utiliza el término bug ni 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.

Para 1963, la depuración era un término lo suficientemente común como para mencionarse de pasada sin explicación en la página 1 del manual CTSS . ^{[ 7 ]}

A medida que el software y los sistemas electrónicos se han vuelto más complejos, las diversas técnicas comunes de depuración se han ampliado con más métodos para detectar anomalías, evaluar el impacto y programar parches de software o actualizaciones completas del sistema. Los términos "anomalía" y "discrepancia" pueden usarse, por ser más neutrales , para evitar "error", "defecto" o "bug", donde podría implicar que todos los supuestos 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 si una nueva versión programada podría hacer innecesarios dichos cambios . No todos los problemas son críticos para la seguridad o la misión de un sistema. Además, es importante evitar la situación en la que un cambio pueda resultar más perjudicial para los usuarios a largo plazo que convivir con el problema conocido (donde "el remedio sería peor que la enfermedad"). Basar las decisiones sobre la aceptabilidad de ciertas anomalías puede evitar una cultura de "cero defectos", donde las personas podrían verse tentadas a negar la existencia de problemas para que el resultado parezca cero defectos . Al considerar cuestiones colaterales, como la evaluación del impacto costo-beneficio, las técnicas de depuración más amplias se extenderán para determinar la frecuencia de las anomalías (con qué frecuencia ocurren los mismos "errores") y así evaluar su impacto en el sistema general.

La depuración varía en complejidad, desde corregir errores simples hasta realizar tareas largas y tediosas de recopilación y análisis de datos, así como de programación de actualizaciones. La habilidad del programador para depurar puede ser un factor clave para resolver un problema, pero la dificultad de la depuración de software varía considerablemente según la complejidad del sistema y también depende, en cierta medida, del lenguaje o lenguajes de programación utilizados 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 modificar 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 cuentan con características como el manejo de excepciones y la verificación de tipos, que permiten identificar con mayor facilidad las causas reales del comportamiento errático. En lenguajes como C o el lenguaje ensamblador , los errores pueden provocar problemas silenciosos, como la corrupción de memoria , y a menudo resulta difícil determinar el origen del problema. En estos casos, pueden ser necesarias herramientas de depuración de memoria .

En ciertas situaciones, las herramientas de software de propósito general, pero específicas para cada lenguaje, pueden resultar muy útiles. Estas herramientas son, por ejemplo, las de análisis estático de código . Buscan un conjunto muy específico de problemas conocidos, algunos comunes y otros poco frecuentes, dentro del código fuente, centrándose más en la semántica (por ejemplo, el flujo de datos) que en la sintaxis, como hacen los compiladores e intérpretes.

Existen herramientas, tanto comerciales como gratuitas, para diversos lenguajes de programación; algunas afirman poder detectar cientos de problemas diferentes. Estas herramientas pueden ser extremadamente útiles al revisar árboles de código fuente muy grandes, donde resulta poco práctico realizar recorridos de código. Un ejemplo típico de un problema detectado sería la desreferenciación de una variable antes de que se le asigne un valor. Como otro ejemplo, algunas de estas herramientas realizan una comprobación de tipos estricta cuando el lenguaje no la requiere. Por lo tanto, son mejores para localizar posibles errores en código sintácticamente correcto. Sin embargo, estas herramientas tienen fama de generar falsos positivos, donde 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 , se suelen utilizar 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 compleja, especialmente con procesos paralelos y algunos errores de Heisen, por ejemplo. El entorno de usuario específico y el historial de uso también pueden dificultar la reproducción del problema.

Una vez reproducido el error, puede ser necesario simplificar la entrada del programa para facilitar la depuración. Por ejemplo, un error en un compilador puede provocar que falle al analizar un archivo fuente extenso. Sin embargo, tras simplificar el caso de prueba, unas pocas líneas del archivo fuente original pueden ser suficientes para reproducir el mismo fallo. La simplificación puede realizarse manualmente mediante un enfoque de divide y vencerás , en el que el programador intenta eliminar algunas partes del caso de prueba original y luego comprueba si el problema persiste. Al depurar en una interfaz gráfica de usuario (GUI) , el programador puede intentar omitir algunas interacciones del usuario de la descripción original del problema para comprobar si las acciones restantes son suficientes para provocar el error.

Una vez que el caso de prueba se ha simplificado lo suficiente, un programador puede usar una herramienta de depuración para examinar los estados del programa (valores de las variables, además de la pila de llamadas ) y localizar el origen del problema o problemas . Alternativamente, se puede usar el rastreo . En casos sencillos, el rastreo consiste simplemente en unas pocas instrucciones print que muestran los valores de las variables en puntos específicos durante la ejecución del programa. ^{[ 8 ]}

• La depuración interactiva utiliza herramientas que permiten procesar la ejecución de un programa paso a paso y pausarlo para inspeccionar o modificar su estado. Las subrutinas o llamadas a funciones suelen ejecutarse a máxima velocidad y pausarse al regresar a la función que las llamó, o bien ejecutarse paso a paso, o una combinación de ambas opciones. Se pueden instalar puntos de interrupción que permiten la ejecución a máxima velocidad del código que no se sospecha que sea defectuoso, y luego detenerse en un punto donde sí lo sea. Colocar un punto de interrupción inmediatamente después del final de un bucle del programa es una forma práctica de evaluar código repetitivo. Los puntos de observación son habituales, permitiendo que la ejecución continúe hasta que cambie una variable específica, y los puntos de captura hacen que el depurador se detenga ante ciertos eventos del programa, como excepciones o la carga de una biblioteca compartida.
• La depuración o rastreo de impresiones consiste en observar (en vivo o grabadas) las instrucciones de rastreo o de impresión que indican el flujo de ejecución de un proceso y la progresión de los datos. El rastreo se puede realizar con herramientas especializadas (como con el rastreo de GDB) o insertando instrucciones de rastreo en el código fuente. Esto último a veces se denominaLa depuración mediante printf se debe al uso de laprintfen C. Este tipo de depuración se activaba con el comandoTRONen las versiones originales delBASIC. TRON significaba "Trace On" (Rastrear activado). TRON hacía que se imprimieran los números de línea de cada comando de BASIC mientras se ejecutaba el programa.
• El rastreo de actividad es similar al rastreo (descrito anteriormente), pero en lugar de seguir la ejecución del programa instrucción por instrucción o función por función, rastrea la actividad del programa en función del tiempo total que el procesador/CPU dedica a ejecutar segmentos específicos de código. Esto se suele presentar como una fracción del tiempo de ejecución del programa que se emplea en el procesamiento de instrucciones dentro de direcciones de memoria definidas (programas en código máquina) o ciertos módulos del programa (programas en lenguaje de alto nivel o compilados). Si se observa que el programa que se está depurando dedica una fracción excesiva de su tiempo de ejecución a las áreas rastreadas, esto podría indicar una mala asignación 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 depurar un programa que se ejecuta en un sistema distinto al del depurador. Para iniciar la depuración remota, el depurador se conecta a un sistema remoto mediante un enlace de comunicación, como unared de área local (LAN). De esta forma, el depurador puede controlar la ejecución del programa en el sistema remoto y obtener información sobre su estado.
• La depuración post mortem consiste en depurar el programa después de que haya fallado . Las técnicas relacionadas suelen incluir diversas técnicas de rastreo, como el examen de archivos de registro, la generación de una pila de llamadas tras el fallo ^{[ 9 ]} y el análisis del volcado de memoria (o volcado de núcleo ) del proceso que falló. El volcado del proceso puede obtenerse automáticamente por el sistema (por ejemplo, cuando el proceso ha finalizado debido a una excepción no controlada), mediante 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 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 en que puedas ver al lobo". ^{[ 10 ]} Esto se implementa, por ejemplo, en el sistema de control de versiones Git como el comando git bisect , que utiliza el algoritmo anterior para determinar qué commit introdujo un error en particular.
• La depuración mediante grabación y reproducción consiste en crear una grabación de la ejecución de un programa (por ejemplo, utilizando la herramienta gratuita rr de Mozilla , que permite la depuración/ejecución reversible), la cual puede reproducirse y depurarse de forma interactiva. Resulta útil para la depuración remota y para depurar defectos intermitentes, no deterministas y otros defectos difíciles de reproducir.
• La depuración mediante 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 qué sucede durante la ejecución de un programa informático; para permitir a los usuarios interactuar 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. ^{[ 11 ] : p.123 [ 12 ]} 
• Saff Squeeze : una técnica para aislar fallos dentro de la prueba mediante la inserción progresiva de partes de la prueba que falla. ^{[ 13 ] [ 14 ]} 
• Seguimiento de causalidad : Existen técnicas para rastrear las cadenas de causa y efecto en el cálculo. ^{[ 15 ]} Estas técnicas pueden adaptarse a errores específicos, como las desreferencias de punteros nulos. ^{[ 16 ]}
• Depuración por escopeta: un proceso que intenta corregir un error mediante modificaciones del código fuente en gran medida no dirigidas, lo que a veces resulta en problemas adicionales. ^{[ 17 ]}
• La localización de fallos es la técnica automatizada para identificar elementos del programa (instrucciones, métodos o componentes) que probablemente contengan fallos. Los enfoques modernos utilizan el aprendizaje automático para mejorar la precisión de la localización. ^{[ 18 ]}

A diferencia del entorno de diseño de software de propósito general, una característica principal de los entornos embebidos es la gran cantidad de plataformas diferentes disponibles para los desarrolladores (arquitecturas de CPU, proveedores, sistemas operativos y sus variantes). Los sistemas embebidos, por definición, no son diseños de propósito general: se desarrollan normalmente para una sola tarea (o un pequeño conjunto de tareas), y la plataforma se elige específicamente para optimizar esa aplicación. Esto no solo dificulta el trabajo de los desarrolladores de sistemas embebidos, sino que también complica la depuración y las pruebas 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 tanto a nivel comercial como prototipos de investigación. Ejemplos de soluciones comerciales provienen de Green Hills Software , ^{[ 23 ]} Lauterbach GmbH ^{[ 24 ]} y MPLAB-ICD de Microchip (depurador en circuito). Dos ejemplos de herramientas prototipo de investigación son Aveksha ^{[ 25 ]} y Flocklab. ^{[ 26 ]} Todos ellos aprovechan una funcionalidad disponible en procesadores embebidos 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 evalúan en función de la cantidad de cambios necesarios en la aplicación y la tasa de eventos que pueden procesar.

Además de la tarea típica de identificar errores en el sistema, la depuración de sistemas embebidos también busca recopilar información sobre los estados operativos del sistema que luego se puede utilizar para analizarlo: para encontrar formas de mejorar su rendimiento u optimizar otras características importantes (por ejemplo, consumo de energía, fiabilidad, 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 dificultan los intentos de ingeniería inversa o depuración de un proceso objetivo". ^{[ 27 ]} Es utilizada activamente por editores reconocidos en esquemas de protección contra copias , pero también por malware para complicar su detección y eliminación. ^{[ 28 ]} Las técnicas utilizadas en la antidepuración incluyen:

• Basado en API: comprueba la existencia de un depurador utilizando la información del sistema.
• Basado en excepciones: comprueba si las excepciones se ven afectadas.
• Bloques de procesos e hilos: compruebe si se han manipulado los bloques de procesos e hilos.
• Código modificado: compruebe si hay modificaciones en el código realizadas por un depurador que maneja puntos de interrupción de software.
• Basado en hardware y registros: compruebe los puntos de interrupción de hardware y los registros de la CPU.
• Tiempos y latencia: compruebe el tiempo que tarda en ejecutarse la instrucción.
• Detección y penalización del depurador ^{[ 28 ]}

Un ejemplo temprano de anti-depuración existió en las primeras versiones de Microsoft Word que, si se detectaba un depurador, mostraba un mensaje que decía: "El árbol del mal da frutos amargos. Ahora se está destruyendo el disco del programa.", tras 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 de nuevo. ^{[ 29 ] [ 30 ]}

• Agans, David J. (2002). Depuración: Las nueve reglas indispensables para encontrar incluso los problemas de software y hardware más difíciles de resolver . AMACOM. ISBN 0-8144-7168-4.
• Blunden, Bill (2003). Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code . 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 . Digital Press. 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 . The Coriolis Group. 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, Tras la pista del escurridizo error informático , IEEE Annals of the History of Computing, 1998.

• Patrones de análisis de volcados de memoria : artículos en profundidad sobre el análisis y la detección de errores en volcados de memoria. 
• Fundamentos de la depuración : cómo mejorar tus habilidades de depuración. 
• Depuración basada en complementos para sistemas embebidos. Archivado el 10/12/2019 en Wayback Machine.
• Pruebas y depuración de sistemas embebidos: información sobre la generación de entradas digitales . Resultados de una encuesta sobre pruebas y depuración de sistemas embebidos, Byte Paradigm (archivado del original el 12 de enero de 2012).