linux - mac - musicbrainz picard español

¿Cómo analizar el archivo de volcado del núcleo de un programa con gdb?

Question

Mi programa funciona así:

exe -p param1 -i param2 -o param3

Se bloqueó y generó un archivo core dump core.pid

Quiero analizar el archivo de volcado del núcleo por

gdb ./exe -p param1 -i param2 -o param3 core.pid

pero el gdb reconoce los parámetros de exe como la entrada de gdb.

¿Cómo analizar el archivo de volcado núcleo en esta situación?

Answer 1

Desde el tutorial de gdb Debugger de RMS :

prompt > myprogram
Segmentation fault (core dumped)
prompt > gdb myprogram
...
(gdb) core core.pid
...

Asegúrate de que tu archivo sea realmente una imagen core ; revísalo usando un file .

Answer 2

No importa que los archivos ejecutables tengan argumentos o no, Para ejecutar GDB en cualquier archivo binario con un archivo central generado, la sintaxis está debajo.

Syntax:
gdb <binary name> <generated core file>
Eg:
gdb l3_entity 6290-corefile

déjame tomar el siguiente ejemplo para más comprensión.

bash-4.1$**gdb l3_entity 6290-corefile**
**Core was generated** by `/dir1/dir2/dir3/l3_entity **Program terminated with signal SIGABRT, Aborted.**
#0
#1
#2
#3
#4
#5
#6
#7
#8
#9
#10
(gdb)

Del resultado anterior, puedes adivinar algo sobre el núcleo, ya sea que se trate de un acceso NULO o SIGABORT, etc.

Estos números del 0 al 10 son los cuadros de pila de GDB. Estos marcos de pila no son de tu binario. en los cuadros anteriores de 0 a 10 si sospecha que algo está mal, seleccione ese marco

(gdb) frame 8

Ahora para ver más detalles al respecto:

(gdb) list +

Para investigar más a fondo, puede imprimir los valores de las variables sospechosas aquí en este momento.

(gdb) print thread_name

Answer 3

Puede analizar el archivo de volcado del núcleo con el comando "gdb".

 gdb - The GNU Debugger
syntax:
# gdb executable-file core-file
ex: # gdb out.txt core.xxx

Gracias.

Answer 4

Puede usar el núcleo con gdb de muchas maneras, pero pasar los parámetros que se pasarán a ejecutable en gdb no es la forma de usar el archivo central. Esta también podría ser la razón por la que obtuviste ese error. Puede usar el archivo central de las siguientes maneras:
gdb <executable> <core-file> o gdb <executable> -c <core-file> o

gdb <executable>
...
(gdb) core <core-file>

Al usar el archivo central, no es necesario pasar argumentos. El escenario de bloqueo se muestra en gdb (comprobado con gdb Versión 7.1 en Ubuntu). Por ejemplo:

$ ./crash -p param1 -o param2
Segmentation fault (core dumped)
$ gdb ./crash core
GNU gdb (GDB) 7.1-ubuntu
...
Core was generated by `./crash -p param1 -o param2''. <<<<< See this line shows crash scenario
Program terminated with signal 11, Segmentation fault.
#0 __strlen_ia32 () at ../sysdeps/i386/i686/multiarch/../../i586/strlen.S:99
99 ../sysdeps/i386/i686/multiarch/../../i586/strlen.S: No such file or directory.
in ../sysdeps/i386/i686/multiarch/../../i586/strlen.S
(gdb)

Si desea pasar parámetros al ejecutable para --args en gdb use --args .
Por ejemplo:

$ gdb --args ./crash -p param1 -o param2
GNU gdb (GDB) 7.1-ubuntu
...
(gdb) r
Starting program: /home/@@@@/crash -p param1 -o param2
Program received signal SIGSEGV, Segmentation fault.
__strlen_ia32 () at ../sysdeps/i386/i686/multiarch/../../i586/strlen.S:99
99 ../sysdeps/i386/i686/multiarch/../../i586/strlen.S: No such file or directory.
in ../sysdeps/i386/i686/multiarch/../../i586/strlen.S
(gdb)

Las páginas man serán útiles para ver otras opciones gdb.

Answer 5

Simplemente escriba comando

$ gdb <Binary> <codeDump>

o

$ gdb <binary>
$ gdb) core <coreDump>

No es necesario proporcionar ningún argumento de línea de comando. El volcado de código generado debido a un ejercicio anterior.

Answer 6

Solo omita los params, gdb no los necesita:

gdb ./exe core.pid

Answer 7

Un enfoque ligeramente diferente le permitirá omitir GDB por completo. Si todo lo que quiere es una traza inversa, la utilidad específica de Linux ''catchsegv'' capturará SIGSEGV y mostrará una traza inversa.

Answer 8

Uso simple de GDB para depurar archivos coredump:

gdb <executable_path> <coredump_file_path>

Se crea el archivo Coredump para un "proceso", como archivo "core.pid". Después de ingresar al indicador gdb, (al ejecutar el comando anterior), escriba;

...
(gdb) where

Esto te llevará con la información, de la pila, donde puedes analizar la causa de la falla / falla. Otro comando, para los mismos fines es;

...
(gdb) bt full

Esto es lo mismo que arriba. Por convención, enumera toda la información de la pila (que en última instancia conduce a la ubicación del bloqueo).