Conoce mi
$ uname -a Linux hostmachine 4.1.2-2-ARCH #1 SMP PREEMPT Wed Jul 15 08:30:32 UTC 2015 x86_64 GNU/LinuxEstoy tratando de aprender a usar GDB para depurar programas en C. Creo que sería particularmente excelente si pudiera usar GDB para descubrir errores que conducen a fallas de segmento. Tengo un pequeño programa que he escrito como una solución para el ejercicio 1-13 de K&R, y dada una cadena de entrada de cierto tamaño generará un error de segmento:
$ ~/learning_c/KR_exercises/chapter_1/1.13.x`--Proporciono una cadena de stdin, y...--
Segmentation fault (core dumped) Según Arch wiki , "el comportamiento predeterminado de Systemd es generar volcados de memoria para todos los procesos en /var/lib/systemd/coredump/ ".
Okie doke:
$ls /var/lib/systemd/coredump/core.1\x2e13\x2ex.1000.0da6be3a2b4647c8befe14e0e73af848.1719.1438627150000000.lz4Pero cuando corro:
$ gdb -q ~/learning_c/KR_exercises/chapter_1/1.13.x /var/lib/systemd/coredump/core.1\\x2e13\\x2ex.1000.0da6be3a2b4647c8befe14e0e73af848.1719.1438627150000000.lz4Yo obtengo:
Reading symbols from /home/dean/learning_c/KR_exercises/chapter_1/1.13.x...done. "/var/lib/systemd/coredump/core.1\x2e13\x2ex.1000.0da6be3a2b4647c8befe14e0e73af848.1719.1438627150000000.lz4" is not a core dump: File format not recognized Intentar generar un volcado del núcleo adjuntando GDB al proceso como se detalla aquí solo hace que mi emulador de terminal comience a capturar caracteres de control ( ^D , ^C y ^Z no funcionarán en el emulador después de adjuntar GDB), y si hay una falla de segmento ocurre después de adjuntar GDB, no se informa en el shell.
¡Ayúdenme a comprender, oh misericordiosos y benéficos señores de Stack Overflow!
APÉNDICE:
Resolví este problema en particular, gracias en gran parte a WhozCraig, quien sugirió que GDB se estaba comportando como debería cuando se alimentaba a la fuerza con un archivo central comprimido lz4. Si Craig fuera tan amable de publicar una solución diciendo algo similar, me encantaría darle esa gran marca de verificación.
La solución más fácil es iniciar gdb a través de una subrutina llamada coredumpctl junto con el PID del programa bloqueado, a la
$coredumpctl gdb *PID HERE*
Esto me fastidia, Arch, y es posible que migre a Gentoo por eso.
Resolví este problema en particular, gracias en gran parte a WhozCraig, quien sugirió que GDB se estaba comportando como debería cuando se alimentaba a la fuerza con un archivo central comprimido LZ4. Sin embargo, si Craig fuera tan amable de publicar una solución diciendo algo similar, estaría feliz de darle esa gran marca de verificación que me llevo todo el crédito. ¡Bwahahaha!
La solución más fácil es iniciar gdb a través de una subrutina llamada coredumpctl junto con el PID del programa bloqueado, a la
$coredumpctl gdb PID AQUÍ
Esto me fastidia, Arch, y es posible que migre a Gentoo por eso .
Tengo el mismo propósito contigo. Simplemente descomprima el archivo lz4 con el comando lz4, luego puede depurarlo con gdb crashed_C_executable_file uncompressed_coredump_file