使用gdb来debug程序并查找Segmentation fault原因

关注公众号【程序员DeRozan】，回复【1207】，免费获取计算机经典资料及现金红包

前言

  在开发程序时，稳定性是我们首先要保证的，即便是程序的性能很强，但是时不时崩溃，这是没办法接受的。
作为开发人员的基本技能，调试程序能让我们在发现问题时，尽快的直击问题发生的根源，从而快速解决问题。而在Linux上，可以通过GDB设置断点，分析原因，如果程序崩溃并且生成了core dumped，则通过GDB也可以分析到问题产生的具体代码段，这无疑是非常又必须要掌握的技能。

本文就GDB的基础用法以及core dump的生成及调试，分享下gdb的用法

GDB基础用法

GDB中，我们经常用到的命令大概可以分为这么几类

1.启动及退出调试

为了保证gdb可以调试你的程序，在编译你的程序时需要加上-g 参数

gdb <program>  进入二进制文件的调试
gdb <program> <PID> 调试program的某一个进程
gdb --args <program> <args>  带运行参数启动调试
quit/q 退出调试

2.设置参数

set args [arguments] 设置运行参数
show args  显示运行参数
set args 清空参数

3.执行程序

1. 启动程序，即将程序跑起来

(gdb) run 
(gdb) r 

2. 继续运行至下一个断点

如果没有断点，程序将运行至结束
(gdb) continue
(gdb) c

3. 单步调试

(gdb) next
(gdb) n 

4. 跳入函数体并停在第一行

(gdb) step 
(gdb) s 

4.流程控制

1. 执行到当前函数结束返回

(gdb) finish

2. 立即返回

(gdb) return 
(gdb) return expression  指定返回值

3. 执行程序直至退出当前循环体

(gdb) until
(gdb) u

4. 执行到某一行停止

(gdb) until 42
(gdb) u 42

    5.跳转至行

(gdb) jump 42

5.设置断点

1. 在具体文件的某行设置断点

(gdb) break main.cpp:42 

2. 在当前文件设置断点

(gdb) break 42

3. 在函数入口处设置断点

(gdb) break 函数名 

4. 条件断点

(gdb) b main.cpp:47 if a == 1

5. 一次性断点

(gdb) tbreak 42 

6.删除断点

# 删除所有断点
(gdb) clear 
# 删除42行的断点
(gdb) clear 42
# 删除函数func内所有断点
(gdb) clear <func>
# 删除编号为Num的断点
(gdb) delete <Num>
# 删除所有断点
(gdb) delete breakpoints

6.输出信息

(gdb) print val
(gdb) p val

7.查看栈帧

1. backtrace命令
   backtrace简写成bt，显示当前程序应景调用的所有函数的函数调用栈信息，每个栈有一个编号，当前调用的函数帧编号为0（栈顶）。

bt  显示所有栈

bt n 显示n号栈，从栈顶算起

bt -n 显示倒数n号栈 从栈底算起

bt full显示栈中所有信息

bt full n 显示n号栈的所有信息

bt full -n 显示倒数n号栈的所有信息

2. frame命令

   frame主要用于切换栈帧

(gdb) frame <栈帧编号>
# 查看指定栈帧详细信息
(gdb) info frame <栈帧编号>
# 进入上层栈帧
(gdb) up
# 进入下层栈帧
(gdb) down

8.info命令

 info可以查看各种变量的值，如果我们希望看到详细的函数调用信息帧的信息，如：函数地址、调用函数的地址、被调用函数的地址、当前函数由哪种编程语言编写、函数参数地址及形参值、局部变量的地址、当前桢中存储的寄存器等.

# 缩写为 i f ，查看函数调用帧所有信息
(gdb) info frame
# 查看函数变量的值
(gdb) info args 
# 查看本地变量的信息
(gdb) info locals 
# 查看寄存器的情况（除了浮点寄存器）
(gdb) info registers
# 查看所有寄存器的情况（包括浮点寄存器）
(gdb) info all-registers

9.显示源码

  使用list来查看当前代码段的源码

# 显示当前断点处代码，默认 10 行
(gdb) list
(gdb) l

# 显示区间内源码
(gdb) list <begin>,<end>

# 向前显示源码
(gdb) list +

# 向后显示源码
(gdb) list -

# 显示函数源码
(gdb) list <func>

# 显示指定位置源码
(gdb) list <location>

GDB调试coredump文件

 在程序发生Segmentation fault时，可以通过找到`core..，使用gdb来分析原因

1. 什么是core文件

  core文件其实就是内存的映像，当程序崩溃时，存储内存的相应信息，用于对程序进行调试。当程序崩溃时便会产生core文件，其实准确的应该说是core dump文件，默认生成位置与可执行程序位于同一目录下，文件名为core。

2. 设置生成coredump的大小及位置

  如果程序Segmentation fault时，没有出现core文件，则可以通过如下命令查看有关core dump的设置

ulimit -a:  查看系统参数,若后面的数字为0，则代表不生成core文件
ulimit -c unlimited:    将core文件大小设置为无限制，即生成core文件

# 临时设置 core 文件的生成路径为当前路径
$ sudo bash -c 'echo core.%e.%p > /proc/sys/kernel/core_pattern'

# 永久设置core文件位置，在/etc/sysctl.conf文件中加入如下配置
kernel.core_pattern = core.%e.%p    #配置为程序当前路径
kernel.core_uses_pid = 0
# kernel.core_pattern = /var/core/core.%e.%p  #配置core文件生成到指定路径

或者
mkdir -p /www/coredump/
chmod 777 /www/coredump/

/etc/profile
ulimit -c unlimited

/etc/security/limits.conf
*          soft     core   unlimited

echo "/www/coredump/core-%e-%p-%h-%t" > /proc/sys/kernel/core_pattern

 生成core文件的命名，core.后面可以跟如下参数来决定生成的core文件的名字

%e：发生Segmentation fault的程序名
%p：所dump的进程PID
%c：转储文件的大小上限
%g：所dump的进程的实际组ID
%h：主机名
%s：导致本次coredump的信号
%t：转储时刻(由1970年1月1日起计的秒数)
%u：所dump进程的实际用户ID

3. 使用gdb调试core文件

   成功生成 core 文件之后，可以通过以下命令来使用GDB调试core文件。

$ gdb <program> <core>

 例如

$ gdb Client core.Client.26823
GNU gdb (Ubuntu 8.1.1-0ubuntu1) 8.1.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from Client...done.
[New LWP 26823]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./Client'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __GI___libc_free (mem=0xcdfe302f93dfa028) at malloc.c:3113
3113    malloc.c: No such file or directory.

 程序在malloc.c:3113 出现了问题，使用where命令查看程序内函数的调用过程, 可以看到具体在哪个文件的哪一行出现了问题

在gdb中输入where命令，可以获取堆栈调用信息。当进行coredump调试时候，这个是最基本且最有用处的命令。where命令输出的结果包含程序中 的函数名称和相关参数值。

(gdb) where
#0  __GI___libc_free (mem=0xcdfe302f93dfa028) at malloc.c:3113
#1  0x00007f72e61c3f67 in SendCommandClass<tutorial::Agent_Cpu, tutorial::Agent_Cpu>::sendCommandToAddr (
    this=0x563bab7c04f0, cmd=301, port=5050, in=..., out=...) at src/Convert.h:146
#2  0x00007f72e61c2083 in SpcSendAndRecvProtobufToAddrFunc (cmd=301, port=5050, in=..., out=...)
    at src/Convert.cpp:138
#3  0x00007f72e61c41c2 in SendMsgToAddr (cmd=301, port=5050, in=..., out=...)
    at src/Client.cpp:34
#4  0x00007f72e61c424a in SpcSendAndRecvProtobufToAddr (in=..., out=..., port=5050, cmd=301)
    at src/Client.cpp:47
#5  0x0000563bab32541a in main (argc=1, argv=0x7ffcf014fe28) at src/Client.cpp:195

在多线程运行的时候，core不一定在当前线程，这就需要我们对代码有一定的了解，能够保证哪块代码是安全的，然后通过thread num切换线程，然后再通过bt或者where命令查看堆栈信息，进而定位coredump原因。

  以上仅仅是对单线程的调试基本用法，对于多线程，则需要其他的相关命令来进行调试。

代码007普通

打赏 收藏 海报 链接