在嵌入式Linux开发中,使用gdb对core文件进行调试是一种有效的定位程序崩溃的方法。这种方法在之前的文章中也有提到过。实际工作中,使用gdb调试core文件可能会面临一些问题。在本文中,我们将分享关于core文件的几点内容,包括core文件是什么、前台进程生成core文件的方法、后台进程生成core文件的方法、以及如何调试core文件。另外,我们还会提到导致崩溃栈信息有限的可能原因。
下面我们首先来讨论前台进程生成core文件的方法。前台进程是指用户在shell中使用”./”执行的程序,它可以由用户自己控制,在运行过程中可以与用户进行交互。前台进程的优先级相对较高,用户可以使用”ctrl+c”来终止它。在嵌入式Linux开发中,要生成前台进程的core文件,可以按照以下步骤进行:
-
首先,确保系统中的ulimit值允许生成core文件。可以使用命令”ulimit -c unlimited”来设置core文件大小为无限制。
-
然后,在shell中运行需要调试的程序,并使其崩溃。
-
当程序崩溃时,会在当前工作目录下生成一个名为”core”的文件,这就是生成的core文件。
需要注意的是,生成的core文件可能会占用较大的存储空间,因此在生产环境中,我们通常会限制core文件的大小或禁止生成core文件。
在下一部分,我们将讨论后台进程生成core文件的方法。
core文件配置基本命令:
ulimit -c # 查看core文件是否打开
ulimit -a # 也可以查看core文件是否打开
ulimit -c 0 # 禁止产生core文件
ulimit -c unlimited #设置core文件大小为不限制大小
ulimit -c 1024 #限制产生的core文件的大小不能超过1024KB
core文件的转储文件目录和命名规则是可以设置的。
通过配置/proc/sys/kernel/core_uses_pid可以控制产生的core文件的文件名中是否添加pid作为扩展;
通过配置/proc/sys/kernel/core_pattern可以设置格式化的core文件保存位置或文件名。
比如:
-
设置core文件的文件名中是否添加pid作为扩展
echo "1" > /proc/sys/kernel/core_uses_pid
-
设置格式化的core文件保存位置或文件名
echo "/var/core-%e-%p-%t" > /proc/sys/kernel/core_pattern
参数%e、%p、%t表示的意思如:
%p - insert pid into filename 添加pid
%u - insert current uid into filename 添加当前uid
%g - insert current gid into filename 添加当前gid
%s - insert signal that caused the coredump into the filename 添加导致产生core的信号
%t - insert UNIX time that the coredump occurred into filename 添加core文件生成时的unix时间
%h - insert hostname where the coredump happened into filename 添加主机名
%e - insert coredumping executable name into filename 添加可执行程序名
下面开始进行实操:
查看core文件是否有打开,并设置core文件大小为不限制大小:
设置格式化的core文件保存位置或文件名:
测试代码:
#include
int main(int argc, char **argv)
{
printf("==================segmentation fault test==================\n");
int *p = NULL;
*p = 1234;
return 0;
}
运行测试程序生成core文件:
后台进程如何生成core文件?
后台程序生成core文件的方式与前台程序不一样。这我也是前几天才知道的,我们设备上的程序设置为开机自启动运行于后台,程序崩溃时,竟然没有生成core文件。后来查了些资料才知道后台程序打开core文件的方式不同。
“
后台进程:后台进程又叫守护进程,是运行在系统后台的一种特殊进程,它独立于控制终端并且周期性地执行某种任务或等待处理某些发生的事件,后台进程最大的特点就是不受终端控制。一般用作系统服务,比如日志管理进程rsyslogd,数据库服务myspld等,当然也有一些用户程序因需要被放在后台运行,一般被放在/etc/ini.d/文件夹中设置开机自启动。
”
ulimit命令是有作用范围的,ulimit限制的是当前shell进程以及其派生的子进程,所以通过ulimit修改coresize只是针对在当前shell下启动的子进程,而不能影响其他shell下启动的进程。
所以当我们配置完成生成core dump的参数后,在当前shell直接执行的进程发生崩溃时可以正常生成core,而后台开机自启动的程序则无法生成,而实际总,嵌入式应用程序一般都是开机自启动的,并且发送崩溃的时机也是不可预测的,那么使用这种方式就不能正确的去捕捉coredump文件了。
后台进程要生成core dump文件需在进程代码中开启core dump功能,如:
左右滑动查看全部代码>>>
// 公众号:嵌入式大杂烩
#include
#include
#include
#include
#define SHELL_CMD_CONF_CORE_FILE "echo /var/core-%e-%p-%t > /proc/sys/kernel/core_pattern"
#define SHELL_CMD_DEL_CORE_FILE "rm -f /var/core*"
static int enable_core_dump(void)
{
int ret = -1;
int resource = RLIMIT_CORE;
struct rlimit rlim;
rlim.rlim_cur = 1 ? RLIM_INFINITY : 0;
rlim.rlim_max = 1 ? RLIM_INFINITY : 0;
system(SHELL_CMD_DEL_CORE_FILE);
if (0 != setrlimit(resource, &rlim))
{
printf("setrlimit error!\n");
return -1;
}
else
{
system(SHELL_CMD_CONF_CORE_FILE);
printf("SHELL_CMD_CONF_CORE_FILE\n");
return 0;
}
return ret;
}
int main(int argc, char **argv)
{
enable_core_dump();
printf("==================segmentation fault test==================\n");
int *p = NULL;
*p = 1234;
return 0;
}
让程序开机运行于后台:
在开发板/etc/init.d/目录下新建文件S100Test:
#!/bin/sh
cd /home
./test
“
设置程序开机自启动可参考我们往期文章:《浅析程序开机自启动》
”
重启设备,程序运行崩溃时可生成core文件:
调试core文件?
把core文件传到pc端,使用arm-linux-gnueabihf-gdb对test程序进行调试:
arm-linux-gnueabihf-gdb test
core-file core-test-190-119
崩溃栈信息有限?
这个demo比较简单,可以很快定位到问题。实际中,我们的程序会依赖很多动态库,这时候在调试时需要设置库的搜索路径。
这些库需要和板子上的库对应上,最好是用板子里的库。可以把板子里用到的库放到PC上的某个路径,假如放到/home/LinuxZn/lib这个路径。
我们进入gdb时,可以输入如下命令设置及查看库信息:
set solib-search-path /home/LinuxZn/lib
info sharedlibrary
有时候,加载库信息之后,还是看不到有意义的崩溃栈。
有如下两点需要确认:
-
应用程序在编译时没有指定-g选项,导致可执行程序没有调试信息。 -
板子里的libc库和交叉编译器所使用的libc库版本不一致。
如果不一致,可以把交叉编译器所使用的libc库更新到板子里。
参考:
https://baijiahao.baidu.com/s?id=1661025717994426637&wfr=spider&for=pc
https://blog.csdn.net/lhl_blog/article/details/106542754
以上就是良许教程网为各位朋友分享的Linu系统相关内容。想要了解更多Linux相关知识记得关注公众号“良许Linux”,或扫描下方二维码进行关注,更多干货等着你 !