Depuracin de programas

Depuracin de programas es el proceso de identificar y corregir errores de programacin. En ingls se le conoce como debugging, ya que se asemeja a la eliminacin de bichos (bugs), manera en que se conoce informalmente a los errores de programacin. Se dice que el trmino bug proviene de la poca de los ordenadores de vlvula termoinica, en los cuales los problemas se generaban por los insectos que eran atrados por las luces y estropeaban el equipo. Si bien existen tcnicas para la revisin sistemtica del cdigo fuente y se cuenta con medios computacionales para la deteccin de errores (depuradores) y facilidades integradas en los sistemas lower CASE y en los ambientes de desarrollo integrado, sigue siendo en buena medida una actividad manual, que desafa la paciencia, la imaginacin y la intuicin del programador. Muchas veces se requiere incluir en el cdigo fuente instrucciones auxiliares que permitan el seguimiento de la ejecucin del programa, presentando los valores de variables y direcciones de memoria y ralentizando la salida de datos (modo de depuracin). Dentro de un proceso formal de aseguramiento de la calidad, puede ser asimilado al concepto de prueba unitaria.

La depuracin es el proceso de identificar la raz de un error y corregirlo. Difiere de la prueba, la cual es el proceso mediante el cual se detecta inicialmente el error. La depuracin puede representar hasta el 50% del tiempo de desarrollo de un programa. Para muchos programadores -especialmente para los principiantes - es la parte ms difcil de la programacin. Pero la depuracin no tiene que ser la parte ms difcil. Si sigues las guas y consejos de este documento, tendrs menos errores que depurar. La mayora de los que tendrs sern olvidos o fallas mecanogrficas, fcilmente detectables mediante la observacin del cdigo o su seguimiento con un depurador. Para el resto que queden, los ms serios, los tips y tcnicas que se describen en este documento sern suficientes para que su depuracin resulte ms fcil.

Depuracion de software. A la hora de hablar de programas para la depuracion del software se debe comentar un hecho fundamental, derivado de su propia naturaleza: el software no sufre desgaste, no se deteriora dado que no tiene existencia fsica real. As pues, si hablamos de mantenimiento del software debemos referirnos a una de las siguientes circunstancias particulares: aplicacion de actualizaciones y parches de mantenimiento del sistema operativo o aplicaciones. Esta es una tarea de administracion del sistema, de ejecucion previsible y que no requiere propiamente de herramientas de mantenimiento para llevarse a cabo. Diagnostico y reparacion en su caso de problemas en las aplicaciones, en el sistema operativo o en la interaccion entre las aplicaciones y el sistema. En este caso s se puede hablar propiamente de mantenimiento, debido a que las aplicaciones, el sistema operativo o ambos, no estan totalmente libres de fallos y estos se manifiestan de forma esporadica. Aunque algunas de las herramientas que se explicaran a continuacion se pueden utilizar en este caso, su uso debera limitarse al diagn ostico del problema. Una vez encontrado, sera responsabilidad de los suministradores de la aplicacion o del sistema operativo el subsanarlos. La unica excepcion a esa regla se da cuando el problema sea debido a falta de algun recurso del sistema por ejemplo, espacio en disco o a una mala configuracion del sistema o la aplicacion, caso en el que s se podra llegar a una solucion local. Herramientas para la depuracion y diagnostico de aplicaciones a disposicion de los propios programadores, para eliminar el mayor numero de fallos en la aplicacion antes de su explotacion y para ayudar a solucionar 7 los problemas del apartado anterior durante el mantenimiento del sistema inform atico. Las herramientas que se describen a continuacion son validas fundamentalmente para estas actuaciones. A continuacion se describen las herramientas de que se dispone para hacer aplicaciones facilmente mantenibles y que en algunos casos permiten detectar e incluso solucionar fallos durante su explotacion. Depuradores debuggers y profilers. Los depuradores de codigo fuente permiten ejecutar el programa compilado o interpretado y observar el estado variables y memoria de su entorno durante la ejecucion, deteniendola mediante puntos de ruptura o actualizando en tiempo casi real las variables inspeccionadas. Los puntos de ruptura se pueden disparar incondicionalmente o estableciendo condiciones de datos, iteraciones, etcetera. De esta manera se puede revisar el codigo y eliminar errores. Una vez el programa se considera validado se compila en su caso eliminando la informacion de depuraci on la que relaciona el codigo compilado con el fuente para obtener la version de distribucion. Los profilers permiten ejecutar el programa una serie de veces con datos de entrada sinteticos vectores de prueba analizando el tiempo que se consume en la ejecucion de cada una de las funciones, bucles

y construcciones mas importantes del codigo. De esta manera se puede, en una segunda pasada, refinar aquellos bloques de codigo que consumen mas tiempo de ejecucion para hacerlos mas eficientes y rapidos, mejorando sustancialmente el tiempo de ejecucion total. Depuradores debuggers y desensambladores. Cualquier programa ejecutable, se disponga o no de su codigo fuente, es susceptible de ser depurado con un depurador estandar del sistema y su codigo analizado con un desensamblador. Esta practica, sin embargo, es mas bien propia del hacking que del mantenimiento de las aplicaciones, aunque en algun caso esporadico pueden ayudar a diagnosticar algun problema de interaccion entre la aplicacion y el sistema. Los depuradores de ejecutables son similares a los de codigo fuente pero permiten exclusivamente la inspeccion de los registros de la arquitectura y de posiciones de memoria, no de las variables propiamente dichas, cuyos nombres y tipos son desconocidos. Codigo de depuracion en las aplicaciones y buenas practicas de programacion. Sin lugar a dudas, la mejor forma de hacer aplicaciones faciles de depurar y de mantener consiste en tener estos dos fines en mente durante el desarrollo de toda la aplicacion. De esta forma, incluso sin la ayuda de un depurador se pueden solucionar la mayor parte de los errores y progresar de manera mas facil y rapida hacia nuevas versiones de la misma. Durante el desarrollo de los programas es comun poner nuestros propios inspectores de ciertas variables mediante la salida de sus valores por pantalla durante la ejecucion de los programas. Este codigo se elimina una vez se ha comprobado el buen funcionamiento de bloque que se esta depurando. Una forma adecuada de llevar a cabo este proceso es incluir el codigo de depuracion dentro de bloques de compilacion condicional, que se incluiran o no en el codigo compilado en funcion de algun par ametro. En lenguaje C, por ejemplo, se podra tener #define DEBUG ... #ifdef DEBUG printf("El valor del area en la iteracion %d es: %f\n", i, area); #endif donde la sentencia printf se ejecutara solo si tenemos el parametro DEBUG definido. Comentando la primera lnea, el codigo que se compila condicionalmente se eliminara totalmente del binario compilado. El entorno estandar del lenguaje C nos ofrece otra forma de incluir sentencias de depuracion condicionalmente mediante la funcion void assert(int expresion), que se encuentra definida en assert.h. Normalmente expresion es una comparacion, que si se evalua como falsa, es decir, con su valor igual a cero, durante la ejecucion, fuerza que el programa aborte indicando, mediante un mensaje por pantalla, en que fichero, funcion y lnea se encuentra la llamada a assert que produjo el fallo. El funcionamiento descrito se da si la constante NDEBUG no se encuentra definida. En caso contrario, si definimos NDEBUG, la

llamada a assert() no genera ningun codigo ni produce ningun efecto. Un funcionamiento similar, pero 8 usando el valor de un cdigo de error del sistema, tiene la funcin assert perror(). Se puede ampliar la informacion sobre estas funciones y su uso en las paginas de manual de cualquier sistema linux mediante las ordenes man assert y man assert perror. Tambin es importante que las aplicaciones desarrolladas sean capaces de detectar en la medida de lo posible los errores que se puedan producir y de informar acerca de ellos para solucionarlos si se trata de un error del sistema que afecta a la aplicaci on o para solicitar su correccin si se trata de un error en la propia aplicacin. Para esto es necesario en primer lugar seguir una practica de programacin que utilice al mximo toda la informacin disponible en tiempo de ejecucin. Todas las llamadas al sistema y la mayor parte de las funciones de las bibliotecas est andar devuelven codificada en el valor devuelto usualmente devolviendo un valor menor que cero informacin acerca de si se ha producido un error en la llamada. En este caso, una variable del sistema guarda un cdigo que identifica el error producido. En lenguaje C esta variable es errno, y existe adems la funcin perror(char *s) que enva a la salida de error estndar el texto que le pasamos como argumento y otro definido en el vector sys errlist[] e indexado por el valor de errno que indica el error producido de nuevo, se puede ampliar esta informacin en las pginas de manual. Junto a la prctica de verificar el valor devuelto por todas las llamadas al sistema o a las bibliotecas, es conveniente incluir un comportamiento similar en nuestras propias funciones, de manera que devuelvan un indicador de error si se da alguna circunstancia anmala durante su ejecucin. En general, es bueno que una aplicacin detecte todas las posibles circunstancias errneas y que informe sobre ellas, abortando o no su ejecucin segn lo criticas que sean. Tambin es bueno a veces que las aplicaciones informen de lo que va ocurriendo durante su ejecucin, sea anmalo u ordinario, sobre todo si las aplicaciones no se comunican directamente con el usuario demonios o servicios del sistema, servicios de red, aplicaciones intermedias, etctera. Sin embargo, cuando todo funciona correctamente, el exceso de informacin puede ser molesto para el usuario o para el propio sistema. Por todo esto, otra prctica comn en la programacin y que debera adoptarse en toda aplicacin en aras de su mantenibilidad, es la de definir diferentes niveles de informacion verbose levels en ingles configurables a la hora de ejecutarla usualmente con el parametro -v N, donde N indica el nivel. As en el nivel mas bajo se informara solo de los errores, y en el mas alto de todo aquello que se va produciendo durante la ejecucion y puede ser de utilizad para verificar lo que esta ocurriendo durante el proceso. En este caso, el codigo que genera los mensajes se encuentra necesariamente incorporado en el ejecutable y se ejecuta o no mediante seleccion condicional en tiempo de ejecucion. Los mensajes que se generan desde una aplicacion pueden dirigirse a la salida est andar o, mas adecuadamente, a un fichero de registro o log cuyo nombre y, al menos, ubicacion, deberan ser configurables.