使用GDB调试(上篇：配置、分析core文件)

在Linux系统中配置生成用于GDB分析的core dump（核心转储）文件，可以按照以下步骤进行：

步骤 1: 核心转储使能设置
首先，你需要确认系统的核心转储设置是否符合要求。可以通过以下命令检查当前设置：

bashCopy Code
ulimit -c
　　1.临时配置

　　这个命令会显示核心转储文件的最大大小。如果输出为 0，则表示核心转储功能被禁用。你可以使用以下命令临时修改为不限制大小：

　　bashCopy Code
　　　　ulimit -c unlimited

　　2.永久配置系统打开生成核心转储文件

永久性配置： 如果希望永久性地修改核心转储设置，可以编辑 /etc/security/limits.conf 文件，添加如下内容：

Copy Code
*        hard    core    unlimited
这会使得所有用户的核心转储文件大小限制为无限制。

　　　　格式是<domain>        <type>  <item>  <value>
		
		#<domain> can be:
		# - a user name
		# - a group name, with @group syntax
		# - the wildcard *, for default entry
		# - the wildcard %, can be also used with %group syntax,
		# for maxlogin limit
		#
		#<type> can have the two values:
		# - "soft" for enforcing the soft limits
		# - "hard" for enforcing hard limits
		#
		#<item> can be one of the following:
		# - core - limits the core file size (KB)
		# - data - max data size (KB)
		# - fsize - maximum filesize (KB)
		# - memlock - max locked-in-memory address space (KB)
		# - nofile - max number of open file descriptors
		# - rss - max resident set size (KB)
		# - stack - max stack size (KB)
		# - cpu - max CPU time (MIN)
		# - nproc - max number of processes
		# - as - address space limit (KB)
		# - maxlogins - max number of logins for this user
		# - maxsyslogins - max number of logins on the system
		# - priority - the priority to run user process with
		# - locks - max number of file locks the user can hold
		# - sigpending - max number of pending signals
		# - msgqueue - max memory used by POSIX message queues (bytes)
		# - nice - max nice priority allowed to raise to values: [-20, 19]
		# - rtprio - max realtime priority
		#
		#<domain> <type> <item> <value>

 

步骤 2: 核心文件存放位置
核心转储文件默认情况下会存放在进程的当前工作目录下，通常以 core 为文件名前缀。你可以通过修改 /proc/sys/kernel/core_pattern 文件来自定义核心转储文件的存放位置和命名规则。

例如，通过以下命令查看当前的核心转储文件设置：

	bashCopy Code
	cat /proc/sys/kernel/core_pattern
默认情况下，可能会显示类似于 /var/core/core.%e.%p.%h.%t 的设置，其中 %e 表示可执行文件名，%p 表示进程ID，%h 表示主机名，%t 表示时间戳。你可以根据需要自定义这个模式，确保目录存在并且有合适的权限。

　　/var/core/core.%e.%p.%h.%t，这个模式使用了一些特殊变量：

	%e：可执行文件名。
	%p：进程ID。
	%h：主机名。
	%t：时间戳。
	%s：线程ID。
	临时修改：

	echo "/tmp/core.%e.%p.%h.%t" > /proc/sys/kernel/core_pattern

永久修改：

要永久修改核心转储文件的存放位置，你需要编辑系统的配置文件，通常是 			  /etc/sysctl.conf 或 /etc/sysctl.d/coredump.conf，然后sysctl --system或重启系统以确保修改生效

里面有这配置项

	kernel.core_pattern = /new/path/core.%e.%p.%t

 

比如某嵌入式开发板的

	/etc/sysctl.d/10-default.conf文件就有以下配置

	kernel.core_pattern = /tmp/core.%e.%p.%t.%s

对于10-default.conf文件名，内核参数通常会根据文件名的数字前缀顺序加载，因此较高数字的文件（如99-xxx.conf）会在较低数字的文件（如10-xxx.conf）之后加载。这种顺序控制对于参数之间的依赖关系和优先级很重要

 

Ubuntu20的是用脚本配置

在启动脚本etc/init.d/apport中:

　　echo "|$AGENT -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" > /proc/sys/kernel/core_pattern

cat /proc/sys/kernel/core_pattern后可以看到
　　|/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E

 

这个配置文件/proc/sys/kernel/core_pattern指定了系统在出现核心转储（core dump）时，将核心转储的信息传递给apport工具，配置完了sysctl -p或重启生效

|/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E
。具体参数的含义如下：

	-p%p: 进程号（PID）
	-s%s: 信号号
	-c%c: CPU 核心号
	-d%d: 当前工作目录
	-P%P: 父进程的 PID
	-u%u: 用户 ID
	-g%g: 用户组 ID
	--: 分隔符，之后是核心文件的路径 %E
所以，当系统发生核心转储时，这个配置会将相关的信息传递给apport工具，用于处理和记录核心转储信息。Apport（应用程序错误报告）是一个用于处理和报告应用程序崩溃、错误和异常的工具。它主要用于Ubuntu及其衍生发行版中，用来捕获程序崩溃时的核心转储（core dump）和其他相关信息，然后生成错误报告并向开发者或维护团队发送。

 

可以在自启动脚本中，加入这两句命令也达到永久配置效果

	ulimit -c unlimited
	
	echo "/new/path/core.%e.%p.%t" > /proc/sys/kernel/core_pattern

 

 

步骤 3: 测试核心转储功能
为了验证配置是否生效，可以创建一个简单的程序，例如 test.c：

cCopy Code
#include <stdio.h>
#include <stdlib.h>

void segfault() {
    char *ptr = NULL;
    *ptr = 'a';  // 引发段错误
}

int main() {
    segfault();
    return 0;
}
编译并运行该程序：

bashCopy Code
gcc test.c -o test
./test
如果一切配置正确，会在程序运行时生成一个名为 core 的文件（或者根据你设置的模式生成的文件），你可以用 GDB 进行后续分析：

bashCopy Code
gdb ./test core

如果不加-g选项进行编译时，就会提示no debug信息，解开core文件后，看到的信息相对比较少，这里是只有函数信息

加入-g编译后


解开core文件后，看到的信息比较多，可以定位到代码的这一行

当有依赖库时，可以使用以下方式运行

先运行gdb

set auto-load safe-path / 加载自动加载的文件时，只从根目录开始寻找并加载，对于安全性很重要，因为它限制了 GDB 在加载文件时的搜索路径
set solib-search-path /lib /usr/lib 允许你设置一个或多个目录路径，告诉 GDB 在这些路径下搜索共享库文件.也可以使用冒号连接/lib:/usr/lib

set solib-absolute-prefix /lib /usr/lib 设置共享库文件所在的绝对路径前缀
file /bin/test_g 设置对应coredump的可执行文件(应用)
core-file tmp/core.test_g.7475.549.1722910610 设置对应coredump文件

可以写成脚本,解析coredump文件

gdb_parse.sh

#!/bin/bash
# File: gdb_parse.sh
# Brief: A bash script to quickly run arm-gdb on core files for the Gen GM12 project
# ./gdb_parse.sh  /bin/test_g /tmp/core.test_g.2396.1662184593
#可以导入环境变量
#source ./env_init.sh  

if [ $# -ne 2 ]; then
    echo "Invalid arguments"
    echo "usage: $0 <Binary Path> <Core-file Path>"
    exit
fi

BINARY=$1
CORE_FILE=$2
#配置gdb路径，如果是arm的，可以配置绝对路径。导入环境后，也可以配置相对路径

ARM_GDB=xxx/xxx/xxx/xxxx/gdb

function gdb_check
{
    printOut "Check if xxxx/gdb  exists."
    if [ -f "$ARM_GDB" ];then
        echo -e "Found $ARM_GDB \n"
    else
       echo -e "$ARM_GDB not found!exit gdb \n"
       exit
    fi
}

function gdb_parse
{
    echo -e "Start GDB\n"
　　$ARM_GDB << GDB_SHELL
　　set auto-load safe-path /
　　set solib-search-path /lib:/usr/lib
　　file $BINARY
　　core-file $CORE_FILE
　　bt full
　　GDB_SHELL
}
gdb_check
gdb_parse

还可以使用以下的命令进一步分析

1.分析堆栈信息
一旦 GDB 加载了 core 文件，它会显示程序崩溃时的堆栈信息。可以使用 bt 命令查看完整的堆栈回溯：

(gdb) bt
#0  0x0000555555555206 in main () at crash_example.c:5
这里显示了程序在 crash_example.c 文件的第 5 行崩溃。通过查看堆栈信息，可以了解到程序是如何到达崩溃点的。

2.查看变量状态
可以使用 print 命令查看变量的当前状态。例如，假设我们想查看某个变量的值：

(gdb) print some_variable
这将显示 some_variable 的当前值。

3.分析内存状态
可以查看内存中特定地址的内容。例如，查看某个地址的内容：

(gdb) x/10xg 0x7fffffffde60  // 查看地址0x7fffffffde60处的10个64位长字
这在分析特定内存区域时非常有用。

4.查看源代码和行号
list: 查看当前位置附近的源代码。
(gdb) list
list <function_name>: 查看特定函数的源代码。
(gdb) list main

5.查看内存和寄存器状态
info registers: 查看当前寄存器的值。
(gdb) info registers
x/<n><fmt> <address>: 以不同格式查看内存中的数据。
(gdb) x/4xw 0x7fffffffe080  // 查看地址0x7fffffffe080处的四个字（每个字为32位）

6.管理线程和进程
info threads: 查看当前线程的信息。
(gdb) info threads
thread <id>: 切换到特定的线程。
(gdb) thread 2