Comment analyser le fichier core dump d'un programme avec gdb?
mon programme fonctionne comme ceci:
exe -p param1 -i param2 -o param3
il s'est écrasé et a généré un fichier core dump core.pid
je veux analyser le fichier core dump par
gdb ./exe -p param1 -i param2 -o param3 core.pid
mais la gdb reconnaît les paramètres de exe comme entrée de la gdb.
comment analyser un fichier core dump dans cette situation?
8 réponses
vous pouvez utiliser le noyau avec gdb de nombreuses façons, mais passer les paramètres qui doivent être passés à l'exécutable à gdb n'est pas la façon d'utiliser le fichier core. Cela pourrait aussi être la raison pour laquelle vous avez obtenu cette erreur. Vous pouvez utiliser le fichier core de la façon suivante::
gdb <executable> <core-file> ou gdb <executable> -c <core-file> ou
gdb <executable>
...
(gdb) core <core-file>
lorsque vous utilisez le fichier core, vous n'avez pas à passer d'arguments. Le scénario de crash est affiché dans gdb (vérifié avec la Version 7.1 de gdb sur Ubuntu) . Pour exemple:
$ ./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 vous voulez passer des paramètres à l'exécutable à déboguer dans gdb, utilisez --args .
Par exemple:
$ 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)
seront utiles pour voir d'autres options gdb.
utilisation Simple de GDB, pour déboguer les fichiers coredump:
gdb <executable_path> <coredump_file_path>
fichier Coredump pour un " processus "est créé, comme" core.pid" fichier. Après avoir reçu l'invite gdb, (lors de l'exécution de la commande ci-dessus), tapez:
...
(gdb) where
vous obtiendrez avec les informations, de la pile, où vous pouvez analyser la cause du crash/défaut. autre commande, pour les mêmes fins est;
...
(gdb) bt full
Ce sont les mêmes que ci-dessus. Par convention, il Liste toutes les informations de la pile (ce qui conduit finalement à l'emplacement du crash).
il suffit de sauter les params, gdb n'a pas besoin d'eux:
gdb ./exe core.pid
de tutoriel de débogage GDB de RMS :
prompt > myprogram
Segmentation fault (core dumped)
prompt > gdb myprogram
...
(gdb) core core.pid
...
assurez-vous que votre fichier est bien une image core -- vérifiez en utilisant file .
Une approche légèrement différente vous permettra de sauter GDB entièrement. Si tout ce que vous voulez est un backtrace, l'utilitaire spécifique à linux 'catchsegv' attrapera SIGSEGV et affichera un backtrace.
cela n'a pas d'importance exécutable ont des arguments ou non, pour exécuter GDB sur n'importe quel binaire avec une syntaxe de fichier core générée est ci-dessous.
Syntax:
gdb <binary name> <generated core file>
Eg:
gdb l3_entity 6290-corefile
permettez-moi de prendre l'exemple ci-dessous pour plus de compréhension.
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)
à partir de la sortie ci-dessus, vous pouvez deviner quelque chose sur le noyau que ce soit un accès nul ou un SIGABORT etc..
ces nombres #0 à #10 sont les cadres de pile de GDB. Ces cadres ne sont pas de votre binaire. dans les 0 - 10 images ci-dessus si vous soupçonnez quelque chose de mal, sélectionnez ce cadre
(gdb) frame 8
maintenant pour voir plus de détails à ce sujet:
(gdb) list +
pour enquêter sur la question plus loin, vous pouvez imprimer les valeurs variables suspectées ici à ce moment-ci.
(gdb) print thread_name
vous pouvez analyser le fichier core dump en utilisant la commande" gdb".
gdb - The GNU Debugger
syntax:
# gdb executable-file core-file
ex: # gdb out.txt core.xxx
Merci.
tapez simplement la commande
$ gdb <Binary> <codeDump>
ou
$ gdb <binary>
$ gdb) core <coreDump>
pas besoin d'argumenter en ligne de commande. Le dump de code généré en raison de l'exercice plus tôt.