GDB调试core文件

先写一个运行后会崩溃并产生core文件的demo

#include <iostream>
#include <thread>
class MyClass
{
public:
    void PrintNum(int num)
    {
        static int* ptr = nullptr;
        if (num > 10)
        {
            std::cout << "*********" << *ptr << std::endl;
        }
        std::cout << "----" << num << std::endl;
    }

    void func1(int num)
    {
        func2(num);
    }
    void func2(int num)
    {
        func3(num);
    }
    void func3(int num)
    {
        PrintNum(num);
    }
};

int main()
{
    MyClass obj;
    int i = 0;
    while (true)
    {
        i++;
        obj.func1(i);
    }
}

运行下面命令,产生可执行文件:

g++ -std=c++11 -g  main.cpp

运行后,产生core文件。如下图:
在这里插入图片描述
调试core文件,运行命令

 gdb a.out core-a.out-11-0-0-57233-1661611440

1、 backtrace 命令(简写bt)

执行bt命令,查看运行栈
在这里插入图片描述
可以看出,当程序崩溃,栈中共有 5 个栈帧,从栈顶到栈底分别被编号为 0 ~ 4。

2、 frame命令(简写f)

切换到栈帧3
在这里插入图片描述

3、 info命令

执行 info args
可以看到打印出了this指针的地址和参数的值,如果没有参数,则只会打印this指针的值
在这里插入图片描述
执行 info locals
可以看到打印出了当前函数本地的变量的值
在这里插入图片描述

4、 print命令

打印变量的值可以用print命令
在这里插入图片描述
可以看到 ptr 的值为nullptr

分析结果

切换到栈顶
在这里插入图片描述
执行了代码:

 std::cout << "*********" << *ptr << std::endl;

根据print命令显示,ptr指针是空。所以崩溃原因是因为代码尝试输出空指针的值,所以崩溃。分析结束。

在 Linux 中使用 **GDB(GNU Debugger)** 调试 **core dump** 文件可以帮助定位程序崩溃的原因。以下是详细步骤: --- ### **1. 确保系统生成 core 文件** #### **检查 core 文件限制** ```bash ulimit -c ``` - 如果输出为 `0`,表示系统禁止生成 core 文件。 - **临时解除限制**(当前会话有效): ```bash ulimit -c unlimited ``` - **永久生效**(修改 `/etc/security/limits.conf`): ```bash echo "* soft core unlimited" | sudo tee -a /etc/security/limits.conf ``` #### **设置 core 文件保存路径** ```bash echo "/tmp/core-%e-%p-%t" | sudo tee /proc/sys/kernel/core_pattern ``` - `%e`:程序名 - `%p`:进程 ID - `%t`:崩溃时间戳 --- ### **2. 复现崩溃并获取 core 文件** 运行程序直到崩溃,确认生成 core 文件(默认路径为 `/tmp/core-*` 或当前目录下的 `core`)。 --- ### **3. 使用 GDB 调试 core 文件** ```bash gdb <可执行程序路径> <core文件路径> ``` 例如: ```bash gdb ./my_program /tmp/core-my_program-12345-1620000000 ``` --- ### **4. 常用 GDB 调试命令** | 命令 | 作用 | |---------------------|-------------------------------| | `bt` 或 `where` | 查看崩溃时的调用栈(backtrace) | | `frame <N>` | 切换到栈帧 N(如 `frame 2`) | | `info locals` | 查看当前栈帧的局部变量 | | `print <变量名>` | 打印变量值 | | `list` | 查看崩溃点附近的源代码 | | `quit` | 退出 GDB | --- ### **5. 示例调试流程** 1. **定位崩溃位置**: ```bash (gdb) bt # 输出示例: #0 0x00007f8e9b5a2345 in __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007f8e9b588537 in __GI_abort () at abort.c:79 #2 0x000055d5c1a23456 in main () at main.c:10 ``` 2. **查看具体代码**: ```bash (gdb) frame 2 # 切换到 main 函数的栈帧 (gdb) list # 显示崩溃行附近的代码 ``` 3. **分析变量值**: ```bash (gdb) print variable_name ``` --- ### **6. 高级技巧** #### **调试带符号表的 release 程序** 编译时保留调试信息(`-g` 选项): ```bash gcc -g -o my_program my_program.c ``` #### **加载动态库符号** 如果崩溃发生在动态库中,确保 GDB 能加载库的调试符号: ```bash (gdb) set solib-search-path /path/to/libs ``` #### **多线程调试** ```bash (gdb) info threads # 查看所有线程 (gdb) thread <ID> # 切换到指定线程 ``` --- ### **7. 常见问题** 1. **`No such file or directory`** - 确保 core 文件和可执行程序路径匹配(尤其是动态链接库路径)。 - 使用 `file core` 检查 core 文件是否完整。 2. **`Missing debug symbols`** - 重新编译程序并加上 `-g` 选项。 - 安装调试符号包(如 `libc6-dbg`)。 3. **core 文件过大** - 限制 core 文件大小:`ulimit -c 1000000`(单位:KB)。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值