Depurar con gdb

1. Preparar el programa: -g y -O0

El programa de prueba calcula el promedio de las notas de un alumno y el factorial de 5. Tiene un error plantado, y por ahora no se sabe dónde:

#include <stdio.h>

struct alumno {
    char nombre[16];
    int notas[3];
    int faltas;
};

static double promedio(const int *v, int n)
{
    int total = 0;

    for (int i = 0; i <= n; i++)
        total += v[i];
    return (double)total / n;
}

static long factorial(int n)
{
    if (n <= 1)
        return 1;
    return n * factorial(n - 1);
}

int main(void)
{
    struct alumno a = {"Ana", {7, 9, 8}, 40};
    double p = promedio(a.notas, 3);

    printf("%s: promedio %.2f\n", a.nombre, p);
    printf("5! = %ld\n", factorial(5));
    return 0;
}

$ gcc -std=c17 -Wall -Wextra -g -O0 -o demo demo.c
$ ./demo
Ana: promedio 21.33
5! = 120

Las notas son 7, 9 y 8: el promedio debería ser 8,00. El compilador no advierte nada (el error está en la lógica, no en la sintaxis). Para depurar con comodidad, el ejecutable debe llevar información que lo relacione con el código fuente, y dos opciones de gcc controlan eso:

• -g agrega los símbolos de depuración: tablas que dicen a qué línea del fuente corresponde cada instrucción, y el nombre, tipo y ubicación de cada variable. Sin ellas gdb solo ve direcciones y ensamblador.
• -O0 desactiva las optimizaciones. Con optimización el compilador reordena, elimina y combina código y variables, y lo que se ve en el depurador deja de parecerse al fuente.

La diferencia se aprecia en tres compilaciones del mismo programa. El ejecutable con -g es algo mayor (17 880 bytes frente a 16 072 sin símbolos). Sin -g, gdb pierde las líneas y las variables; con -O2 las conserva pero muchas desaparecen:

$ gcc -std=c17 -O0 -o demo_sin_g demo.c
$ gdb -q ./demo_sin_g
(gdb) break promedio
Breakpoint 1 at 0x1171
(gdb) run
Breakpoint 1, 0x0000555555555171 in promedio ()
(gdb) bt
#0  0x0000555555555171 in promedio ()
#1  0x000055555555525b in main ()
(gdb) info locals
No symbol table info available.

$ gcc -std=c17 -g -O2 -fno-inline -o demo_o2 demo.c
$ gdb -q ./demo_o2
(gdb) break promedio
Breakpoint 1 at 0x1210: file demo.c, line 15.
(gdb) run
Breakpoint 1, promedio (v=v@entry=0x7fffffffd7d0, n=3) at demo.c:15
15	    return (double)total / n;
(gdb) info locals
i = <optimized out>
total = <optimized out>

Sin -g, el punto de ruptura está en una dirección (0x1171), la pila muestra funciones sin líneas ni argumentos, y no hay variables. Con -O2, el punto de ruptura salta a la línea 15 (el bucle se optimizó) y total es <optimized out>: el compilador la mantuvo en un registro, o la eliminó, y gdb no puede mostrarla. (Con -O2 sin -fno-inline, promedio ni siquiera existe como función: se incorporó a main y break promedio responde Function "promedio" not defined.) De ahí la receta: para depurar, compilar con -g -O0 (o -Og, una optimización moderada pensada para depurar). Los ejecutables que se entregan se compilan después sin -g, o con -g pero separando los símbolos.

2. Una primera sesión

Se arranca con gdb ./demo (la opción -q omite el texto de bienvenida). gdb muestra el prompt (gdb) y espera órdenes. El programa aún no corre: primero se fijan los puntos de ruptura (breakpoints) y luego se lo lanza con run. Una sesión corta por main:

$ gdb -q ./demo
(gdb) break main
Breakpoint 1 at 0x120b: file demo.c, line 26.
(gdb) run
Breakpoint 1, main () at demo.c:26
26	{
(gdb) list
21	        return 1;
22	    return n * factorial(n - 1);
23	}
24
25	int main(void)
26	{
27	    struct alumno a = {"Ana", {7, 9, 8}, 40};
28	    double p = promedio(a.notas, 3);
29
30	    printf("%s: promedio %.2f\n", a.nombre, p);
(gdb) next
27	    struct alumno a = {"Ana", {7, 9, 8}, 40};
(gdb) next
28	    double p = promedio(a.notas, 3);
(gdb) print a
$1 = {nombre = "Ana", '\000' <repeats 12 times>, notas = {7, 9, 8}, faltas = 40}
(gdb) print a.notas
$2 = {7, 9, 8}
(gdb) info locals
a = {nombre = "Ana", '\000' <repeats 12 times>, notas = {7, 9, 8}, faltas = 40}
p = 0
(gdb) step
promedio (v=0x7fffffffd7e0, n=3) at demo.c:11
11	    int total = 0;
(gdb) bt
#0  promedio (v=0x7fffffffd7e0, n=3) at demo.c:11
#1  0x000055555555525b in main () at demo.c:28

Hay varias cosas que ver en esta sesión:

• break main puso el punto de ruptura en la línea 26, la llave de apertura: en main hay un arreglo local y gcc agrega código de protección de la pila antes de la primera línea «real», y el punto de ruptura se coloca después de preparar el marco. Dos next llevan a la línea 28.
• list muestra el fuente alrededor de la línea actual. Con list 20,30 o list promedio se elige otro tramo.
• print a muestra la estructura completa; el nombre aparece como "Ana", '\000' <repeats 12 times>: tres letras y doce ceros que completan los 16 bytes. Cada resultado queda guardado en una variable de gdb, $1, $2…, que se puede reutilizar en otras expresiones.
• info locals lista las variables locales del marco actual. Obsérvese que p = 0 todavía: la línea 28 aún no se ejecutó.
• next avanza una línea sin entrar en las funciones que se llamen en ella; step sí entra. Aquí step entró en promedio, y bt (backtrace) muestra que estamos dentro de ella, llamada desde main en la línea 28.

Las órdenes tienen abreviaturas, y con un poco de práctica casi no se escribe otra cosa:

Pulsar Intro sin escribir nada repite la última orden, cómodo para avanzar con next varias veces.

3. Cazar el error: argumentos, memoria y watch

Ya estamos dentro de promedio. El camino habitual es mirar los datos de entrada, sospechar, y confirmar. Se empieza con un punto de ruptura en la función (sesión nueva) y se examinan sus argumentos:

(gdb) break promedio
Breakpoint 1 at 0x1178: file demo.c, line 11.
(gdb) run
Breakpoint 1, promedio (v=0x7fffffffd7e0, n=3) at demo.c:11
11	    int total = 0;
(gdb) info args
v = 0x7fffffffd7e0
n = 3
(gdb) print *v@3
$1 = {7, 9, 8}
(gdb) print v[3]
$2 = 40

Un puntero a int se muestra como una dirección, y no dice cuántos elementos tiene. El operador @ de gdb lo resuelve: *v@3 significa «los tres elementos que empiezan en *v» y muestra {7, 9, 8}. Hasta aquí todo bien. Pero print v[3] da 40: el arreglo tiene tres notas, y sin embargo v[3] existe (C no lo impide) y vale 40, que es justo el campo faltas que está a continuación en la estructura. Es una pista fuerte: la función lee un elemento de más. Para confirmarlo, en vez de adivinar, se puede vigilar la variable total con watch: gdb detiene el programa en cada instante en que cambia, e indica el valor anterior y el nuevo:

(gdb) watch total
Hardware watchpoint 2: total
(gdb) continue
Hardware watchpoint 2: total

Old value = 16777216
New value = 0
promedio (v=0x7fffffffd7e0, n=3) at demo.c:13
13	    for (int i = 0; i <= n; i++)
(gdb) continue
Hardware watchpoint 2: total

Old value = 0
New value = 7
promedio (v=0x7fffffffd7e0, n=3) at demo.c:13
13	    for (int i = 0; i <= n; i++)
(gdb) continue
Old value = 7
New value = 16
(gdb) continue
Old value = 16
New value = 24
(gdb) continue
Old value = 24
New value = 64
promedio (v=0x7fffffffd7e0, n=3) at demo.c:13
13	    for (int i = 0; i <= n; i++)
(gdb) continue
Watchpoint 2 deleted because the program has left the block in
which its expression is valid.
0x000055555555525b in main () at demo.c:28
28	    double p = promedio(a.notas, 3);

(En los cambios tercero a quinto se resume la salida: gdb repite el mismo encabezado y la misma línea cada vez.) La historia queda a la vista. La primera parada, Old value = 16777216, es la basura que había en la pila antes de inicializar total (por eso es importante inicializar las variables). Luego suma 7 (primera nota), 9 (16), 8 (24) y un cuarto sumando de 40 (64): el bucle ejecuta cuatro vueltas, para i de 0 a 3, cuando la lista solo tiene tres elementos. La condición del for es i <= n y debería ser i < n. Una vez que la función retorna, gdb elimina la vigilancia sola, porque la variable ya no existe. 64 / 3 = 21,33: el resultado erróneo del programa.

El «Hardware watchpoint» es la forma eficiente: los procesadores tienen registros de depuración que avisan al acceder a una dirección de memoria, y gdb los usa mientras hay pocos (suelen ser cuatro). Si no puede, usa una vigilancia por software, que ejecuta el programa instrucción por instrucción y es mucho más lenta. Hay tres variantes: watch x (avisa al cambiar), rwatch x (al leer) y awatch x (en ambos casos). watch -l expr vigila la dirección de la expresión y no su ámbito, útil para memoria dinámica o cuando se vigila a través de un puntero.

4. La pila de llamadas

Cada función en ejecución tiene un marco (frame) en la pila (tema 12), y bt los enumera de la función actual hacia atrás. Es la herramienta para responder «¿cómo llegué hasta aquí?». factorial es recursiva y sirve de ejemplo. Un punto de ruptura condicional (break … if condición) detiene el programa solo cuando la condición es cierta, aquí cuando n vale 2:

(gdb) break factorial if n == 2
Breakpoint 1 at 0x11d5: file demo.c, line 20.
(gdb) run
Ana: promedio 21.33

Breakpoint 1, factorial (n=2) at demo.c:20
20	    if (n <= 1)
(gdb) bt
#0  factorial (n=2) at demo.c:20
#1  0x00005555555551f5 in factorial (n=3) at demo.c:22
#2  0x00005555555551f5 in factorial (n=4) at demo.c:22
#3  0x00005555555551f5 in factorial (n=5) at demo.c:22
#4  0x0000555555555292 in main () at demo.c:31
(gdb) frame 2
#2  0x00005555555551f5 in factorial (n=4) at demo.c:22
22	    return n * factorial(n - 1);
(gdb) info frame
Stack level 2, frame at 0x7fffffffd790:
 rip = 0x5555555551f5 in factorial (demo.c:22); saved rip = 0x5555555551f5
 called by frame at 0x7fffffffd7c0, caller of frame at 0x7fffffffd760
 source language c.
 Arglist at 0x7fffffffd780, args: n=4
 Locals at 0x7fffffffd780, Previous frame's sp is 0x7fffffffd790
 Saved registers:
  rbx at 0x7fffffffd778, rbp at 0x7fffffffd780, rip at 0x7fffffffd788
(gdb) finish
0x00005555555551f5 in factorial (n=5) at demo.c:22
22	    return n * factorial(n - 1);
Value returned is $1 = 24
(gdb) info breakpoints
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x00005555555551d5 in factorial at demo.c:20
	stop only if n == 2
	breakpoint already hit 1 time

Cada elemento del bt trae el número de marco, la dirección de retorno, la función con sus argumentos y la línea. La imagen es la de la recursión del tema 12: factorial(5) llamó a factorial(4), y así hasta factorial(2); main está al fondo.

• frame N (o f N) cambia el marco «seleccionado»; up y down suben y bajan uno. Con un marco seleccionado, print, info locals o info args se refieren a sus variables: en el marco 2 la n vale 4.
• info frame muestra el detalle del marco: dónde guarda el registro de retorno (rip), la base del marco (rbp), etc. Se corresponden con lo estudiado en el tema 12.
• finish ejecuta hasta que el marco seleccionado termina, y muestra el valor que devuelve: como el marco seleccionado era el 2 (n=4), el resultado es factorial(4) = 24, que es lo que informa Value returned is $1 = 24.
• info breakpoints lista todos los puntos de ruptura, con su condición y cuántas veces se activaron.
• Un punto de ruptura temporal, tbreak, se borra solo tras la primera parada. break archivo.c:25 fija el punto en una línea concreta, y delete 1 (o disable 1) lo quita (o lo apaga).

5. Inspeccionar datos: print, ptype y x

print acepta casi cualquier expresión de C: aritmética, punteros, miembros de estructuras, elementos de arreglos, casts, llamadas a funciones. Se puede cambiar el formato con una barra: /x hexadecimal, /d decimal, /t binario, /c carácter, /o octal. Y para ver los tipos, ptype. Con el programa detenido en la línea 30:

(gdb) break 30
Breakpoint 1 at 0x1264: file demo.c, line 30.
(gdb) run
Breakpoint 1, main () at demo.c:30
30	    printf("%s: promedio %.2f\n", a.nombre, p);
(gdb) print sizeof(a)
$1 = 32
(gdb) ptype struct alumno
type = struct alumno {
    char nombre[16];
    int notas[3];
    int faltas;
}
(gdb) print/x a.notas
$2 = {0x7, 0x9, 0x8}
(gdb) print/c a.nombre[0]
$3 = 65 'A'
(gdb) print/t a.faltas
$4 = 101000
(gdb) print &a.notas[1]
$5 = (int *) 0x7fffffffd7e4
(gdb) print *&a.notas[1]
$6 = 9
(gdb) set print pretty on
(gdb) print a
$7 = {
  nombre = "Ana", '\000' <repeats 12 times>,
  notas = {7, 9, 8},
  faltas = 40
}
(gdb) info line 28
Line 28 of "demo.c" starts at address 0x555555555246 <main+71> and ends at 0x555555555264 <main+101>.

Se confirma el tamaño del tema 25 (sizeof(a) es 32: 16 + 12 + 4, sin relleno), el tipo de la estructura, y las conversiones de formato (40 es 101000 en binario; 'A' es 65). set print pretty on imprime las estructuras en varias líneas, útil cuando son grandes.

Para ver la memoria cruda, la orden x (examine) tiene la forma x/NFU dirección: N es cuántas unidades, F el formato (x hexa, d decimal, s cadena, i instrucción, c carácter) y U el tamaño (b byte, h 2 bytes, w 4 bytes, g 8 bytes):

(gdb) x/s a.nombre
0x7fffffffd7d0:	"Ana"
(gdb) x/4dw a.notas
0x7fffffffd7e0:	7	9	8	40
(gdb) x/16xb &a
0x7fffffffd7d0:	0x41	0x6e	0x61	0x00	0x00	0x00	0x00	0x00
0x7fffffffd7d8:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00

La segunda orden, x/4dw a.notas («cuatro enteros de 4 bytes, en decimal»), es la que cierra el caso del error: en memoria, a las tres notas les sigue un cuarto valor, 40, y es el que promedio leyó de más. La tercera muestra los 16 primeros bytes de la estructura: 0x41 0x6e 0x61 son «Ana», seguidos de ceros. (Las direcciones tipo 0x7fffffffd7e0 de la pila son las de este equipo: gdb desactiva por defecto la aleatorización de direcciones, y el valor exacto depende del tamaño del entorno, de modo que en otra máquina serán otras.)

6. Probar hipótesis: set var y call

gdb no solo mira: también puede cambiar variables y llamar a funciones del programa detenido. Eso permite comprobar una hipótesis sin editar ni recompilar. Detenidos en la línea 28, antes de calcular el promedio:

(gdb) break 28
Breakpoint 1 at 0x1246: file demo.c, line 28.
(gdb) run
Breakpoint 1, main () at demo.c:28
28	    double p = promedio(a.notas, 3);
(gdb) print promedio(a.notas, 3)
$1 = 21.333333333333332
(gdb) print factorial(4)
$2 = 24
(gdb) print a.faltas
$3 = 40
(gdb) set var a.faltas = 0
(gdb) print promedio(a.notas, 3)
$4 = 8
(gdb) continue
Ana: promedio 8.00
5! = 120

Primero se llama a promedio y a factorial directamente desde el depurador (print función(args), o call, que es igual pero no muestra resultado si la función devuelve void). Después se pone a.faltas a cero con set var: el promedio da 8, lo que prueba que el valor sobrante se estaba colando, y al continuar el programa imprime 8.00. No se corrigió el código —esa corrección se hace en el fuente (i < n)—, sino que se confirmó el diagnóstico antes de tocar nada. Otras formas de lo mismo: print x = 5 asigna también, y set var se usa cuando el nombre de la variable coincidiría con una orden de gdb.

7. Menos teclas: display, until y commands

display expr hace que gdb muestre la expresión automáticamente cada vez que el programa se detiene. Con un punto de ruptura dentro del bucle (línea 14) y dos display, cada continue enseña cómo evolucionan i y total:

(gdb) break 14
Breakpoint 1 at 0x1188: file demo.c, line 14.
(gdb) run
Breakpoint 1, promedio (v=0x7fffffffd7e0, n=3) at demo.c:14
14	        total += v[i];
(gdb) display i
(gdb) display total
(gdb) continue
Breakpoint 1, promedio (v=0x7fffffffd7e0, n=3) at demo.c:14
14	        total += v[i];
1: i = 1
2: total = 7
(gdb) continue
Breakpoint 1, promedio (v=0x7fffffffd7e0, n=3) at demo.c:14
14	        total += v[i];
1: i = 2
2: total = 16
(gdb) info display
Auto-display expressions now in effect:
Num Enb Expression
1:   y  i
2:   y  total
(gdb) delete 1
(gdb) until 15
promedio (v=0x7fffffffd7e0, n=3) at demo.c:15
15	    return (double)total / n;
2: total = 64

(Esta captura se hizo con un guion de gdb, y en ese modo los display no mostraron su valor al crearse; en una sesión interactiva gdb los muestra de inmediato y, desde entonces, en cada parada.) delete 1 borró el punto de ruptura, y until 15 ejecutó hasta la línea 15 sin detenerse en las vueltas restantes del bucle: cómodo para saltar un bucle largo o una llamada. Sin argumento, until es como next pero no retrocede en un bucle. undisplay N quita un display.

Para observar sin detenerse, un punto de ruptura puede llevar su propia lista de órdenes con commands. Con silent no imprime el aviso de parada, y terminando con continue el programa sigue solo. El resultado es una traza, como un printf insertado sin recompilar:

break factorial
commands
silent
printf "factorial(%d)\n", n
continue
end
run

Ana: promedio 21.33
factorial(5)
factorial(4)
factorial(3)
factorial(2)
factorial(1)
5! = 120
[Inferior 1 (process 473) exited normally]

Los guiones de gdb (la opción -x archivo, o -batch para que gdb termine al acabar) sirven para reproducir una sesión, repetirla tras corregir el código, o ejecutar un diagnóstico dentro de un script. gdb también lee, al iniciar, un archivo ~/.gdbinit y otro .gdbinit en el directorio actual, con las órdenes que se quiera ejecutar siempre (por ejemplo, set print pretty on); el segundo requiere autorización explícita por seguridad.

8. Cuando el programa se cae

Para la depuración más típica, un programa que termina con Segmentation fault, gdb es más rápido que cualquier otra herramienta, porque se detiene en el instante exacto del fallo, con la pila y todas las variables intactas. El programa caida.c construye una lista de tres nodos y recorre mostrando, para cada uno, el valor del siguiente:

struct nodo {
    int valor;
    struct nodo *sig;
};

static int valor_siguiente(const struct nodo *n)
{
    return n->sig->valor;
}

static void mostrar(const struct nodo *n)
{
    for (; n != NULL; n = n->sig)
        printf("%d -> siguiente %d\n", n->valor, valor_siguiente(n));
}

int main(void)
{
    struct nodo *lista = nuevo(1, nuevo(2, nuevo(3, NULL)));

    mostrar(lista);
    return 0;
}

$ ./caida; echo "rc=$?"
1 -> siguiente 2
2 -> siguiente 3
Segmentation fault
rc=139
$ gdb -q ./caida
(gdb) run
1 -> siguiente 2
2 -> siguiente 3

Program received signal SIGSEGV, Segmentation fault.
valor_siguiente (n=0x555555559010) at caida.c:22
22	    return n->sig->valor;
(gdb) bt
#0  valor_siguiente (n=0x555555559010) at caida.c:22
#1  0x000055555555520c in mostrar (n=0x555555559010) at caida.c:28
#2  0x0000555555555286 in main () at caida.c:35
(gdb) frame 1
#1  0x000055555555520c in mostrar (n=0x555555559010) at caida.c:28
28	        printf("%d -> siguiente %d\n", n->valor, valor_siguiente(n));
(gdb) print *n
$1 = {valor = 3, sig = 0x0}
(gdb) print n->sig
$2 = (struct nodo *) 0x0
(gdb) frame 2
#2  0x0000555555555286 in main () at caida.c:35
35	    mostrar(lista);
(gdb) print *lista
$3 = {valor = 1, sig = 0x555555559030}
(gdb) print *lista->sig
$4 = {valor = 2, sig = 0x555555559010}
(gdb) print lista->sig->sig->sig
$5 = (struct nodo *) 0x0

La salida normal del programa ya sugería el problema (el valor «siguiente» del tercer nodo no llega a mostrarse), pero gdb lo explica. Al recibir la señal SIGSEGV, el programa se detiene en la línea 22, n->sig->valor; bt muestra los tres marcos: valor_siguiente ← mostrar ← main. En el marco 1, *n es {valor = 3, sig = 0x0}: el nodo tiene sig nulo, y por tanto n->sig->valor desreferencia un puntero nulo. Es el último nodo de la lista. En el marco 2 se confirma desde main que la lista tiene tres nodos cuyo último apunta a NULL (lista->sig->sig->sig es 0x0). El error no estaba en la función donde cayó, sino en quien la llamó sin comprobar que existía el siguiente: la corrección va en valor_siguiente o en mostrar (comprobar n->sig != NULL). Es el uso más habitual del depurador: la línea del fallo da el síntoma, y la pila y los datos del marco anterior dan la causa.

9. Después de la caída: volcados de memoria

No siempre se puede ejecutar el programa bajo gdb: la caída ocurrió en otra máquina, o una vez en mil ejecuciones. Para esos casos el sistema puede guardar, al morir el proceso, un volcado de memoria (core dump): un archivo con el estado completo de la memoria y los registros en ese instante, que gdb abre como si fuera el proceso detenido. Por omisión Linux no los genera porque el límite de tamaño es cero (ulimit -c lo muestra), y se activa en el shell con ulimit -c unlimited:

$ ulimit -c
0
$ ulimit -c unlimited
$ cat /proc/sys/kernel/core_pattern
core
$ ./caida > /dev/null; ls core*
Segmentation fault (core dumped)
core.837
$ gdb -q ./caida core.837
Core was generated by `./caida'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  valor_siguiente (n=0x56f05bcf5010) at caida.c:22
22	    return n->sig->valor;
(gdb) bt
#0  valor_siguiente (n=0x56f05bcf5010) at caida.c:22
#1  0x000056f03f4c320c in mostrar (n=0x56f05bcf5010) at caida.c:28
#2  0x000056f03f4c3286 in main () at caida.c:35
(gdb) frame 1
#1  0x000056f03f4c320c in mostrar (n=0x56f05bcf5010) at caida.c:28
28	        printf("%d -> siguiente %d\n", n->valor, valor_siguiente(n));
(gdb) print n->valor
$1 = 3
(gdb) print n->sig
$2 = (struct nodo *) 0x0
(gdb) info registers rip
rip            0x56f03f4c320c      0x56f03f4c320c <mostrar+30>

La «autopsia» da lo mismo que la sesión en vivo: el mismo punto de fallo, la misma pila y los mismos valores, sin volver a ejecutar nada. Dos observaciones. La primera, que se puede inspeccionar el estado, pero no avanzar: no hay proceso que continuar (next o continue dan error). La segunda, que las direcciones son otras (0x56f05bcf5010 en vez de 0x555555559010): bajo gdb en vivo se desactiva la aleatorización del espacio de direcciones (ASLR), pero la ejecución normal que produjo el volcado la tenía activada. Los valores y la estructura son los que importan.

El nombre core.837 incluye el identificador del proceso; en otros sistemas el nombre es solo core, y el patrón lo fija /proc/sys/kernel/core_pattern. Otras distribuciones envían los volcados a un servicio que los guarda aparte —systemd-coredump (se consulta con coredumpctl) o apport en Ubuntu de escritorio— y core_pattern lo indica; en tal caso hay que mirar allí. Los volcados pueden ocupar mucho espacio y contienen la memoria del proceso, con contraseñas o datos privados si los tenía: se tratan con cuidado y no se desactivan por descuido. Para que un volcado sea útil, el ejecutable debe haberse compilado con -g y ser exactamente el mismo que murió.

10. Argumentos, entrada y otras funciones

Cuando el programa recibe argumentos, hay tres formas de pasárselos. Con este programa, que muestra argv y devuelve 1 si hay más de dos argumentos:

#include <stdio.h>

int main(int argc, char **argv)
{
    for (int i = 0; i < argc; i++)
        printf("argv[%d] = %s\n", i, argv[i]);
    return argc > 2;
}

(gdb) break main
Breakpoint 1 at 0x115c: file args.c, line 5.
(gdb) run uno "dos tres"
Breakpoint 1, main (argc=3, argv=0x7fffffffd918) at args.c:5
5	    for (int i = 0; i < argc; i++)
(gdb) print argc
$1 = 3
(gdb) print argv[2]
$2 = 0x7fffffffdbad "dos tres"
(gdb) print *argv@argc
$3 = {0x7fffffffdb9b "/home/ana/c/args", 0x7fffffffdba9 "uno", 0x7fffffffdbad "dos tres"}
(gdb) show args
Argument list to give program being debugged when it is started is "uno "dos tres"".
(gdb) continue
argv[0] = /home/ana/c/args
argv[1] = uno
argv[2] = dos tres
[Inferior 1 (process 591) exited with code 01]
$ gdb -q --args ./args a b c
(dentro de gdb: break main; run; print argc  →  $1 = 4; print argv[1]  →  "a")

Los argumentos se pasan (1) con run arg1 arg2, (2) con set args arg1 arg2 antes de run, o (3) desde el shell con gdb --args ./prog arg1 arg2; show args muestra los actuales. La redirección vale igual: run < entrada.txt entrega ese archivo como entrada estándar. print *argv@argc es la forma de ver el arreglo completo de punteros. El final del programa se informa: exited with code 01 indica que main devolvió 1 (el código de salida del tema 37, en octal), y exited normally, que fue 0.

Otras posibilidades

• Interfaz de texto (TUI). gdb -tui ./demo, o layout src dentro de gdb, divide la terminal y muestra el fuente con la línea actual resaltada. Con layout asm se ve el ensamblador.
• Adjuntarse a un proceso en marcha. gdb -p PID (o attach PID) depura un proceso que ya corre; en muchos sistemas el kernel lo restringe (ptrace_scope) y exige permisos adicionales.
• Ensamblador y registros. x/3i $pc desensambla las próximas instrucciones, info registers muestra los registros y disassemble la función entera. Útil cuando no hay código fuente.
• Señales. gdb se detiene en cada señal que recibe el programa; handle SIGUSR1 nostop noprint pass cambia el comportamiento. Las señales se estudian en el curso Procesos e Hilos, donde también se verá cómo depurar programas con varios hilos (info threads).
• Fugas y desbordes de memoria. gdb muestra el estado del programa, pero no detecta por sí mismo errores de memoria que no provocan una caída. Para eso están Valgrind y los sanitizadores (tema 29), y el análisis estático que se verá en el tema siguiente.

11. Errores frecuentes

12. Resumen

• Para depurar, compilar con -g -O0: -g agrega símbolos (líneas, variables, tipos) y -O0 evita que las optimizaciones desfiguren el código. Sin -g solo hay direcciones; con -O2, variables <optimized out>.
• Una sesión típica: gdb ./prog, break (en una función o línea), run, y avanzar con next (sin entrar) y step (entrando); continue sigue hasta el siguiente punto, finish hasta salir de la función y until hasta una línea.
• Se inspecciona con print (con formatos /x /d /t /c), info locals, info args, ptype y x/NFU para la memoria cruda. *ptr@n muestra n elementos desde un puntero y display repite una expresión en cada parada.
• watch detiene el programa cuando una variable cambia y muestra el valor anterior y el nuevo, con lo que se ve el instante exacto en que algo se corrompe. Los puntos de ruptura admiten condiciones (break f if n == 2), son temporales con tbreak y pueden llevar órdenes propias con commands.
• bt muestra la pila de llamadas; frame N, up y down cambian el marco seleccionado, y entonces print e info locals se refieren a sus variables.
• set var y print función(args) permiten cambiar datos y llamar funciones en vivo, para comprobar una hipótesis antes de corregir el fuente.
• Ante un SIGSEGV, gdb se detiene en el instante del fallo: la línea es el síntoma, y la pila (bt) y los datos del marco que llamó (frame 1, print *n) dan la causa.
• Con ulimit -c unlimited el sistema guarda un volcado de memoria al morir el proceso, y gdb ./prog core.PID lo examina después (sin poder continuar la ejecución). Los argumentos se pasan con run args, set args o gdb --args.

13. Preguntas de repaso

Intenta responder cada una antes de abrir la respuesta.

Para practicar

1. Compila demo.c con -g -O0 y repite el diagnóstico completo: punto de ruptura en promedio, print *v@3, watch total y seguimiento hasta ver el cuarto sumando. Corrige i <= n y comprueba que sale 8,00.
2. Con un programa propio que tenga varias funciones, coloca un punto de ruptura en la más interna, usa bt y recorre los marcos con up y down mostrando las variables de cada uno.
3. Escribe un programa que calcule la suma de los elementos de un arreglo dinámico (malloc) y mira con x/8dw la memoria justo después del bloque reservado. ¿Qué hay? ¿Qué pasa con watch si se escribe fuera?
4. Provoca un Segmentation fault con un puntero nulo, otro con un puntero sin inicializar y otro con una cadena en .rodata modificada (char *s = "hola"; s[0] = 'H';). Compara cómo se ve cada caída en gdb.
5. Activa los volcados con ulimit -c unlimited, haz caer un programa, y analiza el core sin ejecutarlo de nuevo. Comprueba qué pasa si recompilas el ejecutable entre la caída y el análisis.
6. Escribe un guion de gdb (-batch -x) que ponga un punto de ruptura con commands en una función, imprima sus argumentos y continúe, y úsalo para trazar todas las llamadas de un programa sin modificarlo.
7. Abre una sesión con layout src (o gdb -tui) y recorre un programa con next. Prueba layout asm y x/5i $pc: ¿qué instrucciones corresponden a una línea de C?
8. Depura el mismo programa compilado con -O0, con -O2 y con -Og, y anota qué cambia en info locals, en el orden de las líneas con next y en los nombres de funciones con break.