GDB 调试工具

调试器 – Gdb 调试流程

• 首先使用 gcc 对 test.c 进行编译，注意一定要加上选项 -g
• # gcc -g test.c -o test 生成符号表
• # gdb test

gdb 调试流程

• 查看文件 (gdb) l
• 设置断点 (gdb) b 6
• 查看断点情况 (gdb) info b
• 运行代码 (gdb) r
• 查看变量值 (gdb) p n
• 单步运行
  • (gdb) n
  • (gdb) s
• 恢复程序运行 (gdb) c
• 帮助 (gdb) help [command]

gdb 的使用切记点

• 在 GCC 编译选项中一定要加入 -g。
• 只有在代码处于“运行”或“暂停”状态时才能查看变量值。
• 设置断点后程序在指定行之前停止

gdb 调试

• 运行被调试程序，设置所有的能影响该程序的参数和变量。
• 保证被调试程序在指定的条件下停止运行。
• 当被调试程序停止时，让开发工程师检查发生了什么。
• 根据每次调试器的提示信息来做响应的改变，以便修正某个错误引起的问题

Coredump 故障分析

Core Dump-定义

• 如果一个程序运行3天后才会出错,这个时候难道需要我们一直用GDB调试程序3天吗?

• • 答案当然是否定的。我们有更厉害的武器：Core dump

• Core Dump 又叫核心转存。当程序在运行过程中发生异常，这时Linux系统可以把程序出错时的内存内容存储在一个 core 文件中，这种过程叫 Core Dump

Segment fault

• Core Dump 主要用来对付什么样的错误呢？

• • Segment fault

• Linux应用程序在运行过程中，经常会遇到 Segment fault（段错误） 这样的错误。产生这样错误的原因通常有：

• • 数组访问越界
  • 访问空指针
  • 栈溢出
  • 修改只读内存

Core Dump 使能

• 在 Linux 系统中，默认是关闭 core dump 功能的，但是可以通过来 ulimit 命令打开 / 关闭 core dump 功能。
  • 打开：ulimit -c unlimited
  • 关闭：ulimit -c 0

Core 文件分析

• 发生 core dump 之后，可以使用 gdb 进行查看 core 文件的内容，以定位程序出错的位置。
• 用法：gdb 程序名 core文件名
• 例：gdb ./test core.12525

手把手教你找错误

• 使用 GDB+Core file 找出程序中的错误（访问空指针）
• 使用 GDB+Core file 找出程序中的错误（访问只读内存）