debugging - debugger - ¿Cómo usas gdb para depurar tu código?

javascript console chrome

Question

Como desarrollador, ¿cómo usas gdb para rastrear errores dentro de tu código? ¿Qué trucos de técnicas usas para hacerte la vida más fácil?

Answer 1

En general, encuentras algo que no es así, y trabajas hacia atrás hasta que comprendes por qué.

El más obvio es el más útil: establecer un punto de interrupción en una función o número de línea y recorrer el código línea por línea.

Otro consejo útil es tener funciones de mostrar para todas sus estructuras / objetos, incluso si nunca se utilizan en su programa, ya que puede ejecutar estas funciones desde dentro de gdb:

gdb> p show_my_struct(struct)
My custom display of Foo:
...

Los puntos de observación también pueden ser útiles, pero pueden ralentizar mucho su programa. Estos rompen el flujo cuando cambia el valor de una variable o dirección:

gdb> watch foo
Watchpoint4: foo
gdb>

Answer 2

Use ddd, un front-end visual para gdb. Te permite hacer las cosas fácilmente con unos pocos clics del mouse y visualizar cómo funciona el código, además en la consola del depurador tienes un gdb intercativo.

Answer 3

También puedes usar Geany .

Answer 4

Básico pero muy útil: use la guía de texto con la opción -tui.

Answer 5

Hago un montón de desarrollo paralelo de programas, así que he encontrado que usar un envoltorio simple en python / ruby ​​que me permite tener gdb adjunto a todos los procesos en todos los nodos y comunicarme es extraordinariamente útil (no lo he hecho encontró una mejor manera si alguien sabe de uno, no para secuestrar el hilo, aunque ...)

No estoy seguro de la experiencia del OP, así que:

Los documentos de GDB son bastante agradables y abarcan todo. El primer capítulo es una buena introducción a todos los conceptos básicos.

http://www.gnu.org/software/gdb/documentation/

Aunque no son gdb, están relacionados: personalmente he descubierto que la interrupción de líneas complejas para ayudar a determinar qué afirmaciones son erróneas ayuda.

Además, Valgrind ( http://valgrind.org/ ) es realmente bueno / útil para abordar desbordamientos de búfer y cosas por el estilo (no he tenido suerte con gdb por hacer esto).

Answer 6

Una característica particularmente útil de gdb es su capacidad para inspeccionar el estado final de un programa que se ha bloqueado.

Para inspeccionar un volcado de fallo (o un archivo de núcleo, como se le llama más comúnmente), inicie gdb de la siguiente manera:

gdb <nombre-programa> <archivo-core>

Por ejemplo:

gdb a.out core

Al ejecutar este comando en un archivo core, gdb le dirá cómo terminó el programa y mostrará en qué parte del programa se produjo el error:

Program terminated with signal 11, Segmentation fault.
#0 0x08048364 in foo () at foo.c:4
4 *x = 100;

En el ejemplo anterior, puede ver que el programa terminó con un error de segmentación al intentar asignar un valor a un puntero. Al escribir backtrace (o bt o where ) en el prompt de gdb, puede ver la traza inversa completa del programa:

(gdb) backtrace
#0 0x08048364 in foo () at foo.c:4
#1 0x0804837f in main () at foo.c:9

En este punto, sabes que main() llamado foo() y foo() bloquearon en la línea 4 al intentar asignar un valor a *x . Muchas veces, esto proporciona suficiente información para permitirle corregir el error.

Answer 7

Algunos consejos:

• use un frontend gráfico (kdbg es bastante bueno, ddd es al menos mejor que gdb de línea de comandos, kdevelop tiene un buen interfaz gdb pero tiene algunos bgs, nemiver también se ve bastante bien, pero aún está en proceso)
• asegúrese de tener símbolos de depuración y código fuente para todas las partes importantes (su propio código y también algunas librerías del sistema)
  • en RedHat, puede instalar los paquetes -debuginfo para hacer que los símbolos y el código fuente aparezcan mágicamente en el depurador, realmente genial porque puede examinar las llamadas a funciones de libc, etc.
  • en Debian / Ubuntu, puede instalar los paquetes -dbg para obtener símbolos; Sin embargo, la instalación de los archivos fuente apropiados para los paquetes del sistema parece ser difícil
• Tiendo a agregar llamadas a assert () y abort () en lugares que no deberían ser alcanzados, o en lugares que quiero estudiar (algún tipo de punto de corte de peso pesado)
• lo ideal es que las llamadas assert () o abort () se envuelvan en algún método o macro que solo las habilite en las versiones de depuración, o mejor aún que solo las habilite si se establece una determinada env var
• instalar un manejador de señal para SIGSEGV y SIGABRT; personalmente, compruebo si se ha establecido una cierta env var antes de instalar los controladores; y en el controlador ejecuto un comando externo codificado que generalmente vive en algún lugar en ~ / .local / bin /; ese comando podría entonces iniciar kdbg y adjuntarlo a la aplicación de bloqueo. Voila, el depurador aparece en el momento en que tu aplicación hace algo malo.
• Si usa pruebas unitarias, puede adjuntar un depurador de manera similar cada vez que falla un caso de prueba, luego inspeccionar la aplicación.