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

关注公众号【程序员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 
  1. 继续运行至下一个断点
如果没有断点,程序将运行至结束
(gdb) continue
(gdb) c
  1. 单步调试
(gdb) next
(gdb) n 
  1. 跳入函数体并停在第一行
(gdb) step 
(gdb) s 

4.流程控制

  1. 执行当前函数结束返回
(gdb) finish
  1. 立即返回
(gdb) return 
(gdb) return expression  指定返回值
  1. 执行程序直至退出当前循环
(gdb) until
(gdb) u
  1. 执行到某一行停止
(gdb) until 42
(gdb) u 42

    5.跳转至行

(gdb) jump 42

5.设置断点

  1. 在具体文件的某行设置断点
(gdb) break main.cpp:42 
  1. 当前文件设置断点
(gdb) break 42
  1. 函数入口处设置断点
(gdb) break 函数名 
  1. 条件断点
(gdb) b main.cpp:47 if a == 1
  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.查看栈帧

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

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

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

bt full显示栈中所有信息

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

bt full -n 显示倒数n号栈的所有信息
  1. 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

  1. 设置生成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
  1. 使用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进行投诉反馈,一经查实,立即删除!

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注