GDB 调试
前言
在开发程序时,稳定性是我们首先要保证的,即便是程序的性能很强,但是时不时崩溃,这是没办法接受的。
作为开发人员的基本技能,调试程序能让我们在发现问题时,尽快的直击问题发生的根源,从而快速解决问题。而在Linux上,可以通过GDB设置断点,分析原因,如果程序崩溃并且生成了core dumped,则通过GDB也可以分析到问题产生的具体代码段,这无疑是非常又必须要掌握的技能。
本文就GDB的基础用法
以及core dump的生成及调试
,分享下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.执行程序
- 启动程序,即将程序跑起来
(gdb) run
(gdb) r
如果没有断点,程序将运行至结束
(gdb) continue
(gdb) c
- 单步调试
(gdb) next
(gdb) n
(gdb) step
(gdb) s
4.流程控制
(gdb) finish
- 立即返回
(gdb) return
(gdb) return expression 指定返回值
(gdb) until
(gdb) u
(gdb) until 42
(gdb) u 42
5.跳转至行
(gdb) jump 42
5.设置断点
(gdb) break main.cpp:42
(gdb) break 42
- 在函数入口处设置断点
(gdb) break 函数名
- 条件断点
(gdb) b main.cpp:47 if a == 1
- 一次性断点
(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.查看栈帧
bt 显示所有栈
bt n 显示n号栈,从栈顶算起
bt -n 显示倒数n号栈 从栈底算起
bt full显示栈中所有信息
bt full n 显示n号栈的所有信息
bt full -n 显示倒数n号栈的所有信息
(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.显示源码
# 显示当前断点处代码,默认 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来分析原因
core文件其实就是内存的映像
,当程序崩溃时,存储内存的相应信息,用于对程序进行调试。当程序崩溃时便会产生core文件,其实准确的应该说是core dump文件,默认生成位置与可执行程序位于同一目录下,文件名为core。
如果程序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
- 使用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原因。
以上仅仅是对单线程的调试基本用法,对于多线程,则需要其他的相关命令来进行调试。
原文地址:https://blog.csdn.net/dddgggd/article/details/129100401
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:http://www.7code.cn/show_46308.html
如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱:suwngjj01@126.com进行投诉反馈,一经查实,立即删除!