Gorila Guapo
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/Linux
Estoy 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)
De acuerdo con la wiki del arco“El comportamiento predeterminado de Systemd es generar volcados de núcleo para todos los procesos en /var/lib/systemd/coredump/.”
Okie doke:
$ls /var/lib/systemd/coredump/core.1\x2e13\x2ex.1000.0da6be3a2b4647c8befe14e0e73af848.1719.1438627150000000.lz4
Pero 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.lz4
Yo 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
Intentando generar un volcado de núcleo adjuntando GDB al proceso como se detalla aquí solo hace que mi emulador de terminal comience a capturar caracteres de control (^D, ^Cy ^Z no funcionará en el emulador después de adjuntar GDB), y si se produce un error de segmento 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 estrellado, 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. Si Craig fuera tan amable de publicar una solución diciendo algo similar, me encantaría darle esa gran marca de verificación. Sin embargo, me llevo todo el crédito. ¡Bwahahaha!
Lo más fácil solución 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.
-
Lo más fácil es solo
coredumpctl gdb -1para depurar el último volcado.– jthill
21 de enero de 2018 a las 15:29
-
Sí, estás tratando de abrir un archivo comprimido como si fuera un volcado de memoria. Arch no tiene la culpa, systemd sí, y usted por no saber qué cambió con los volcados de núcleo. cambie /proc/kernel/core_pattern de nuevo a “core” si desea el comportamiento anterior, o simplemente use coredumpctl gdb
– GL2014
6 de diciembre de 2019 a las 15:19
-
También puede obtener el volcado del núcleo (y luego cargarlo donde quiera) con:
coredumpctl dump -1 > core(para escribirlo en el archivocore)– Tanque de Tinker
20 de abril de 2022 a las 10:23
Tengo el mismo propósito contigo. Simplemente descomprima el archivo lz4 por lz4 comando, entonces puede depurar por gdb crashed_C_executable_file uncompressed_coredump_file
-
Si usa coredumpctl gdb, no necesita descomprimirlo o volver a comprimirlo.
– GL2014
6 de diciembre de 2019 a las 15:20
-
“/var/lib/systemd/coredump/core.python.0.5fe0d2b21e0942918513074e7a3a307a.32113.1671175637000000.lz4” no es un volcado del núcleo: formato de archivo no reconocido
– CS QGB
16 de diciembre de 2022 a las 7:30
Al no tener mi caja de Linux a mano, solo puedo especular que gdb está vomitando al recibir un archivo comprimido LZ4 como lo que es. piensa Qué es un volcado de núcleo sin procesar? Solo una suposición, fíjate, pero tal vez valga la pena echarle un vistazo.
– WhozCraig
03/08/2015 a las 20:15
¡Esta es una solución perfectamente plausible! Y ahora estoy bastante avergonzado de no haber reconocido la extensión de archivo .lz4. Tan pronto como termine de leer la documentación relevante en lz4 y logre descomprimir el archivo central, ¡les informaré!
– HandsomeGorilla
03/08/2015 a las 20:32
¿Ha intentado establecer puntos de interrupción y recorrer el programa con GDB?
– Rdesmond
03/08/2015 a las 20:32
@Rdesmond, podría. Y, para programas pequeños como con el que estoy trabajando, ese enfoque es probablemente tan efectivo (quizás más rápido) que examinar el volcado del núcleo. Sin embargo, mi objetivo aquí es aprender cómo para usar volcados de memoria. Supongamos que un futuro programa hipotético es enorme, o tiene una duración de un en realidad mucho tiempo antes de la falla de segmento, o el comportamiento depende de un montón de entradas ambientales aleatorias? Ser capaz de trabajar con archivos principales hace que la depuración en esos escenarios sea un poco menos tediosa e intratable.
– HandsomeGorilla
03/08/2015 a las 20:41
mirando esta pagina freedesktop.org/software/systemd/man/journald.conf.html parece que, de forma predeterminada, si el tamaño del núcleo es mayor, se comprimen. Todo lo que necesita hacer es establecer el valor de Compresión en falso
– Pradheep
4 de agosto de 2015 a las 1:46