GDB (The GNU Project Debugger)是 Linux 系统下调试 C 和 C++ 程序的主要神兵。Vim教程网(https://vimjc.com)介绍多种方式下使用 GDB 启动进程调试的方法和命令。

要使得 C 和 C++ 程序能在 GDB 下正常进行调试,必须在程序编译期间把基本的调试信息(如变量名、函数名、函数调用堆栈等)添加到可执行文件中。gcc、cc、g++ 等编译器可通过编译参数 -g 指定添加调试信息。

当使用 GDB 加载不包含调试信息的二进制文件或进程时,GDB终端会提示错误信息:”no debugging symbols found”。

一、GDB调试未执行程序

对于本地的某个二进制文件 demo ( GDB 也支持远程调试),若其启动时不需要命令行参数,则可以在shell下使用命令 gdb demo 进入 GDB,并输入 run (缩写形式 r) 启动对demo的调试。

若 demo 程序启动时需要命令行参数,则可以在使用 gdb demo 命令进入 GDB 后,使用命令 run arg1 arg2... 提供命令行参数并启动对 demo 程序的调试。

gdb-run.gif

二、GDB调试运行中程序

使用 GDB 调试正在运行的程序时,必须先找到该程序运行在操作系统中的进程号 (PID)。可以使用 Linux 命令 ps ef | grep -w demops aux | grep -w demopidof demo 获取到 demo 进程当前的进程号。

获取到待调试的目标进程号后 (假设为 pid ),可以使用 gdb 命令进入 GDB 终端,并使用 attach pid 的方式启动对当前正在运行的 demo 进程的 GDB 调试。

也可以使用 gdb -p pid 命令直接进入 GDB 并启动对该进程的调试。

对于使用多线程模式的进程,可以在 GDB 中使用 info threads 命令显示当前进程中所有线程的基本调试信息,包括:GDB 分配的线程ID、线程堆栈等。线程列表中,GDB 线程 ID 左侧的 * 表示当前真正被调试的线程。

可通过 thread tid 命令切换和启动对 GDB 线程号为 tid 的线程进行调试。关于使用 GDB 调试多进程和多线程,后续会有独立的文章进行详细介绍。

三、GDB调试core文件

当程序在 Linux 系统下发生异常崩溃(如段错误)时,内核会将该应用程序在崩溃发生时的内存数据、程序调用堆栈等核心信息转存到磁盘,这种功能称之为 core dump,中文可翻译为 核心转储

core dump 是程序异常退出时的内存快照,是异常发生后对程序进行现场还原和故障排查的关键线索。Linux 进程 core 掉可以说是所有 C 和 C++ 程序员接触最频繁而又最不想碰到的问题。

可通过 ulimit -c 查看和指定 core 文件的大小,通过修改 /proc/sys/kernel/core_pattern 文件可指定 core 文件保存在本地磁盘中的路径和文件名格式。

GDB 对 core 文件的分析和调试提供了非常强大的功能支持,可使用 gdb demo/data/core/xxx 启动对 demo 进程某次产生的core文件 /data/core/xxx 的分析和调试,也可以使用 gdb -c /data/core/xxx 加载和分析 core 文件。

GDB 正常加载 core 文件后,便可以使用 backtrace (缩写形式 bt) 显示程序异常退出时刻的函数堆栈情况,再使用 frameprintupdownwhere 等命令对异常现场进行详细分析。

为了让程序产生 dump ,将 demo.cpp 中的输出语句 printf("%s: %d\n",(char*)ptr,array[i]); 改成 printf("%s: %s\n",(char*)ptr,array[i]); 后在编译时加入 -w 参数忽略掉警告后重新生成 demo 可执行文件。

关于 GDB 调试程序和 core 文件的具体方法和命令,请关注Vim教程网(https://vimjc.com)后续 GDB 系列的后续文章。

PS:使用 quit (缩写形式 q) 可退出 GDB。

《女程序员说》

原创不易,希望能给小女子的公众号加个关注~