Mi programa funciona así:¿Cómo analizar el archivo de volcado del núcleo de un programa con gdb?
exe -p param1 -i param2 -o param3
Se estrelló y genera un archivo de vaciado core.pid
quiero analizar el archivo de vaciado por
gdb ./exe -p param1 -i param2 -o param3 core.pid
pero el BGF reconocer los parametros de exe como entrada de gdb.
¿Cómo analizar el archivo de volcado del núcleo en esta situación?
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 utilizar el archivo central en las formas siguientes:
gdb <executable> <core-file> o gdb <executable> -c <core-file> o
gdb <executable>
...
(gdb) core <core-file>
Cuando se utiliza el archivo central que no tienen que 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 a ser depurado en uso GDB --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)
páginas hombre será útil para ver otras opciones BGF.
omita la params, el BGF no los necesita:
gdb ./exe core.pid
Pero esto no funciona. La advertencia de salida de gdb: el archivo central puede no coincidir con el archivo ejecutable especificado. Error al leer una imagen de archivo de objeto válida de la memoria. – Treper
"el archivo principal puede no coincidir con el ejecutable especificado". ¿Modificó el exe después de que produjo el núcleo? ¿Quizás lo reconstruyas con diferentes opciones de línea de comandos? Es muy importante darle a GDB el * exacto * mismo binario que produjo el núcleo. Si no lo haces, obtendrás basura. –
También asegúrese de que el binario que se pasa a gdb no se elimine. Puede ejecutar 'archivo
De RMS's gdb Debugger Tutorial:
prompt > myprogram
Segmentation fault (core dumped)
prompt > gdb myprogram
...
(gdb) core core.pid
...
Asegúrese de que el archivo es realmente una imagen de core - comprobarlo usando file.
Su tutorial es bastante bueno. Sin embargo, desde el 30/11/16, su sitio no está allí. Puede volver, pero mientras tanto, puede ver su tutorial en Wayback Machine: https://web.archive.org/web/20161015015746/http://www.unknownroad.com/rtfm/gdbtut/gdbtoc. html –
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.
Uso simple de GDB, para depurar los archivos de volcado de núcleo:
gdb <executable_path> <coredump_file_path>
archivo Coredump de un "proceso" se crea, como archivo "core.pid". Después de ingresar al indicador gdb, (al ejecutar el comando anterior), escriba;
...
(gdb) where
Esto le dará a la información, de la pila, donde se puede analayze la causa del accidente/fallo. Otro comando, para los mismos fines es;
...
(gdb) bt full
Esto es igual que el anterior.Por convención, enumera toda la información de pila (que finalmente conduce a la ubicación del bloqueo).
Un enfoque ligeramente diferente le permitirá omitir completamente GDB. Si todo lo que quiere es una traza inversa, la utilidad específica de Linux 'catchsegv' capturará SIGSEGV y mostrará una traza inversa.
Simplemente tipo de comando
$ gdb <Binary> <codeDump>
o
$ gdb <binary>
$ gdb) core <coreDump>
No hay necesidad de proporcionar ningún argumento de línea de comandos. El volcado de código generado debido a un ejercicio anterior.
No importa el ejecutable tiene argumentos o no, Para ejecutar GDB en cualquier archivo binario con un archivo de núcleo generado La sintaxis está a continuación.
Syntax:
gdb <binary name> <generated core file>
Eg:
gdb l3_entity 6290-corefile
déjame tomar el siguiente ejemplo para obtener más informació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)
A partir del resultado anterior, se puede adivinar algo acerca de núcleo si se trata de un acceso nulo o SIGABORT etc ..
Estos números # 0 y # 10 son los marcos de pila de BGF. Estos marcos de pila no son de tu binario. en las anteriores 0 - 10 fotogramas si sospecha que algo malo seleccionar ese marco
(gdb) frame 8
Ahora ver más detalles al respecto:
(gdb) list +
Para investigar Otra cuestión que puede imprimir los valores de las variables presuntos aquí en este punto del tiempo
(gdb) print thread_name
¿Está seguro de que su 'exe' no es un script de shell (para establecer algunas variables, etc.) como p. Ej. 'firefox' está en Linux? –
http://unix.stackexchange.com/questions/89933/how-to-view-core-files-for-debugging-purposes-in-linux/202443#202443 –