Temporada 01: aprendiendo GDB

Ya sea que estés aprendiendo a programar, o ya te ganes la vida haciéndolo, no estás exento de cometer errores; incluso puede que como parte de un equipo, te toque corregir errores cometidos por alguien más, o por ti mismo hace ya algún tiempo. Sea como sea, no siempre resulta obvio diagnosticar qué está mal con el comportamiento de nuestros programas.

Para ayudarnos a encontrar este tipo de fallas tenemos disponibles herramientas muy poderosas llamadas depuradores. Uno de los más importantes que existen es precisamente GNU GDB, el cual nos permite explorar las entrañas de nuestro software. En esta temporada encontrarás información muy útil para acercarte a esta gran herramienta. ¡Espero que la disfrutes!

08. Depuración: cómo depurar programas multiproceso

Con lo visto hasta este punto de la serie, hemos cubierto herramientas suficientes para que explotes las capacidades que GDB te ofrece para encontrar defectos en tus programas. En esta ocasión te mostraré cómo utilizar el depurador de GNU para examinar aplicaciones cliente-servidor. Las recetas que te presento pueden ser adaptadas para otros escenarios (como aplicaciones multihilo o que se comuniquen a través de sockets).

07. Depuración: visualizando variables II

Hace unas semanas te mostré cómo puedes utilizar GDB para observar los valores que toman las variables en un programa. Sin embargo, lo más complejo que observamos en aquella ocasión fueron arreglos. ¿Qué pasa cuando trabajamos con tipos de dato más complejos, como registros u objetos? En esta entrega te mostraré algunas herramientas que te ayudarán a examinar mejor estructuras de datos un poco más complejas.

06. Depuración: la pila de llamadas

En la nota anterior te mostré cómo controlar el flujo de ejecución utilizando breakpoints condicionales y asociando comandos a ellos. Con estas herramientas ganamos bastante flexibilidad a la hora de examinar la ejecución de nuestros programas, sin embargo, para algunas situaciones no es suficiente con averiguar las circunstancias presentes al momento de reproducir un bug, también es necesario saber cómo fue que llegamos a tales circunstancias; es decir: cuál fue el camino que siguió nuestro programa para llegar al punto de falla.

05. Depuración: breakpoints II

A estas alturas ya estamos familiarizados con los breakpoints, sabemos que siempre que nuestro programa alcance uno de estos, su ejecución se detendrá. Pero hay escenarios en los que no necesitamos que el programa se detenga siempre que el breakpoint sea alcanzado, por ejemplo, cuando el bug que buscamos corregir se reproduce en las últimas iteraciones de un bucle. Es aquí donde se vuelve útil decidir cuándo quieres que el breakpoint detenga el programa y cuándo no.

04. Depuración: visualizando variables

Una vez que hemos detenido nuestro programa, el depurador nos proporciona comandos para visualizar el valor que toman las variables dentro del ámbito en el que nos encontramos. Ya he utilizado el modo más simple para observar variables: el comando p o print, el cual simplemente despliega el valor actual de una variable. Si una variable tiene un valor inesperado, resulta ser un muy buen indicio sobre la naturaleza del error que estemos buscando en ese momento.

03. Depuración: watchpoints

Siempre que el depurador alcance un punto de quiebre, éste detendrá la ejecución del programa en ese punto siempre que el breakpoint esté habilitado. Por lo tanto, podemos controlar de una manera un tanto burda, cuando detenernos o no en cierta parte del programa.

Al momento de buscar la causa de un bug, es común que se nos ocurran ideas como: «creo que mi programa fallará en la línea 78» o «tal vez la falla está en la función ‘tal'», pero ¿qué ocurre cuándo el programa no siempre falla donde suponemos o no podemos anticipar en qué circunstancias lo hace?, tal vez sabemos que alguna expresión está relacionada con la falla, así que puede ser buena idea vigilarla para obtener más información sobre el defecto que buscamos corregir.

02. Depuración: breakpoints I

En la nota anterior, a modo de introducción, mostré a grandes rasgos el uso básico del depurador de GNU. Bien, ha llegado el momento de entrar un poco más en detalles.

Gracias a que compilamos nuestro programa incluyendo información extra (los símbolos de depuración); GDB en este caso nos proyecta la ilusión de ejecutar el programa línea por línea, en lugar de instrucción por instrucción, que es como realmente lo ejecuta la computadora.

01. Depuración: introducción a GDB

Nadie es perfecto, eso no es nada nuevo. Y los desarrolladores de software no somos la excepción, cometemos errores todo el tiempo, algo que llamamos «introducir bugs«.

Por cierto: el primer bug de computadora de la historia fue reportado hace casi cincuenta años y se trató de un bicho de verdad.

Es necesario detectar y reparar esos errores para entregar un producto final con calidad que se comporte exactamente como fue diseñado. Muchas veces estos bugs son tan pequeños o requieren de condiciones tan especiales para manifestarse, que resultan complicados no solo de arreglar, sino de diagnosticar, lo cual separa a la depuración de las ciencias exactas y la acerca más a las artes (por más pretencioso que suene, así es).

A lo largo de esta serie exploraremos cómo inspeccionar nuestros programas para detectar anomalías que provocan un funcionamiento no deseado y aprenderás cómo corregirlas. Si ya tienes algo de experiencia en la depuración de tu código fuente, al menos espero que las publicaciones de esta serie te sirvan como referencia para cuando necesites emplear alguna técnica en específico y recuerdes fácilmente cómo se hace.

12. Vim: revisión ortográfica

La revisión ortográfica es una característica presente en muchos procesadores de palabra y editores de texto, la cual marca las palabras en un documento que pudieran no haber sido escritas correctamente.

Vim no es la excepción y también proporciona esta característica, aunque la traducción no sea muy precisa, pues el nombre original de esta función es spell checking, donde la palabra spell se traduce más acertadamente como «deletrear». Vale la pena detenerse en este detalle puesto que el editor se limita a revisar que las palabras sean escritas correctamente sin realizar ninguna revisión sintáctica; por lo que en español, puede pasar por alto detalles como una palabra que se escriba correctamente con tilde y sin tilde dependiendo del contexto; por ejemplo «si» y «sí». De esos detalles si tiene que encargarse quien escribe.