gdb core 调试_gdb coredump 调试_linux gdb core 调试(3)

  $ gdb coredump core
  Core was generated by ./coredump'.
      Program terminated with signal 11, Segmentation fault.
  #0  0x080483a7 in crash () at coredump.c:8
      8       xxx[1] = 'D';
  (gdb) 

我们看到已经能直接定位到出core的地方了，在第8行写了一个只读的内存区域导致触发Segment Fault信号。在载入core的时候有个小技巧，如果你事先不知道这个core文件是由哪个程序产生的，你可以先随便找个代替一下，比如/usr/bin/w就是不错的选择。比如我们采用这种方法载入上边产生的core，gdb会有类的输出：

$ gdb /usr/bin/w core
  Core was generated by ./coredump'.
  Program terminated with signal 11, Segmentation fault.
  #0  0x080483a7 in ?? ()
  (gdb) 

可以看到GDB已经提示你了，这个core是由哪个程序产生的。

GDB 常用操作

上边的程序比较简单，不需要另外的操作就能直接找到问题所在。现实却不是这样的，常常需要进行单步跟踪，设置断点之类的操作才能顺利定位问题。下边列出了GDB一些常用的操作。

启动程序：run

设置断点：b 行号|函数名

删除断点：delete 断点编号

禁用断点：disable 断点编号

启用断点：enable 断点编号

单步跟踪：next 也可以简写 n

单步跟踪：step 也可以简写 s

打印变量：print 变量名字

设置变量：set var=value

查看变量类型：ptype var

顺序执行到结束：cont

顺序执行到某一行： util lineno

打印堆栈信息：bt

bt这个命令重点推荐，尤其是当函数嵌套很深，调用关系复杂的时候，他能够显示出整个函数的调用堆栈，调用关系一目了然。另外上边有两个单步执行的命令，一个是n，一个是s。主要区别是n会将函数调用当成一步执行，而s会跟进调用函数内部。

参考

~donahoo/tools/gdb/tutorial.html

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-40592-3.html