printer-driver/docs/09-debugging.md

Depurar: segfault y gdb

Qué es un segmentation fault

El programa accede a una dirección que no tiene mapeada en su espacio virtual, o la usa sin permiso (por ejemplo, escribe en memoria de solo lectura). La MMU no encuentra la traducción, el procesador avisa al núcleo, y el núcleo envía al proceso la señal SIGSEGV, que por defecto lo mata (ver 03-process-memory.md).

• La shell lo muestra como Segmentation fault (core dumped).
• El código de salida es 139 = 128 + 11 (SIGSEGV es la señal 11). Es la misma cuenta que el 137 de SIGKILL en el OOM killer.
• El caso más típico es escribir o leer a través de un puntero NULL. La página de la dirección 0 nunca se mapea, precisamente para que este error se detecte siempre.

Ojo: no todo acceso indebido da segfault. Si te sales de un bloque pero caes en memoria que sí es del proceso, no pasa nada visible: corrompes datos en silencio. Para eso están Valgrind y AddressSanitizer.

En Go: el mismo fallo da panic: runtime error: invalid memory address or nil pointer dereference, con la traza de la pila. Go captura el SIGSEGV y lo convierte en un panic. En C no hay traza: hay que pedírsela a gdb.

free(): invalid pointer y Aborted

glibc comprueba algunas cosas al hacer free. Si el puntero no es el inicio de un bloque que haya dado malloc, calloc o realloc, imprime free(): invalid pointer y llama a abort().

• La shell muestra Aborted (core dumped), con código 134 = 128 + 6 (SIGABRT).
• Causas típicas: hacer free de la dirección de una variable local (&x), de un literal ("hola"), de un puntero al interior de un bloque, o de un bloque ya liberado (double free).

Para depurarlo, mejor Valgrind que gdb. gdb te dice dónde se cae (en el free), pero el error está antes, donde el puntero recibió un valor malo. Valgrind te dice de dónde viene la dirección:

Invalid free() / delete / delete[] / realloc()
   at free
   by escpos_buffer_free (buffer.c:36)
   by main (hello.c:22)
 Address 0x1ffefff544 is on thread 1's stack

"Is on thread 1's stack": la dirección es de la pila, así que nunca la dio malloc. Después busca cada línea que asigna un valor a ese puntero (grep -n "data =" src/*.c) y mira cuál le da una dirección de la pila.

Método general

1. Lee el mensaje. Valgrind casi siempre dice qué pasó (Invalid write, Invalid free), dónde y de qué tipo es la dirección (pila, N bytes después de un bloque, bloque ya liberado...).
2. El síntoma (donde se cae) no suele ser la causa. Pregúntate de dónde salió el valor malo.
3. Busca todas las asignaciones de esa variable y descarta una a una.

gdb: lo mínimo

Hace falta compilar con -g. El Makefile ya lo hace.

gdb ./build/hello

Comando de gdb	Qué hace
run (r)	Ejecuta el programa. Si se cuelga, gdb se para en la línea exacta
bt (backtrace)	Muestra la pila de llamadas: quién llamó a quién hasta llegar aquí
print expr (p)	Muestra el valor de una variable o expresión: p buffer->data
break fichero.c:línea (b)	Pone un punto de parada
next (n)	Ejecuta la línea actual sin entrar en las funciones
step (s)	Ejecuta la línea actual entrando en las funciones
continue (c)	Sigue hasta el siguiente punto de parada
quit (q)	Sale

Programa que no termina (bucle infinito)

1. gdb ./build/hello y run.
2. Cuando lleve un rato colgado, pulsa Ctrl+C: gdb detiene el programa donde esté y te muestra la línea.
3. bt para ver en qué función está, y print de las variables del bucle (print new_cap). Si al repetir next varias veces la variable no cambia, has encontrado el problema.

Ejemplo real: un bucle while (new_cap < min_cap) { new_cap *= 2; } con new_cap empezando en 0. Cero por dos es cero, así que el bucle no termina nunca. print new_cap da 0 en cada vuelta.

Al arrancar, Fedora pregunta si quieres descargar símbolos de depuración del sistema (debuginfod). Para nuestro código no hacen falta: responde n.

En Go el equivalente es Delve (dlv debug), con comandos casi iguales.

Depurar en VS Code

La extensión C/C++ (ms-vscode.cpptools) lanza el mismo gdb y le envía órdenes por su protocolo de texto (gdb/MI). Cada clic equivale a un comando:

VS Code	gdb
Clic a la izquierda del número de línea (punto rojo)	break fichero.c:línea
F5	run / continue
F10	next
F11	step
Shift+F11	finish (salir de la función actual)
Panel Variables, pasar el ratón por encima o panel Watch	print
Panel Call Stack	bt
Botón de pausa	Ctrl+C

Configuración del proyecto, en .vscode/:

• tasks.json: tareas make, make clean, make (clang) y valgrind. Se lanzan con Terminal → Run Task, y Ctrl+Shift+B ejecuta make.
• launch.json: depura build/hello con gdb y ejecuta make antes. Tiene ya los valores para Windows (MSYS2 UCRT64).
• c_cpp_properties.json: dice a IntelliSense dónde están las cabeceras (include/) y que el estándar es C17, para que el editor avise de lo mismo que gcc.
• settings.json: salto de línea final, sin espacios al final de línea, y tabuladores reales en el Makefile.

Para ver un puntero como array en el panel Watch: *buffer->data@10 (los 10 primeros bytes de data). Es sintaxis de gdb y funciona igual en su consola.

En Go, la extensión de Go hace lo mismo con Delve.