Ubuntu下corefile生成以及解析

本文详细介绍了Linux下corefile的设置与使用,包括如何生成corefile,设置corefile的目录和命名规则,以及如何使用GDB查看corefile以定位程序崩溃原因。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1.简介:
corefile 是Linux下程序崩溃时生成的文件,可以用来分析程序崩溃的原因,因为它内部包含了程序崩溃时的堆栈信息。

2.corefile的设置

默认情况下,程序崩溃是不会生成corefile的,因为被操作系统限制。可以通过命令: ulimit -c 来查看,如果值为0则表示被限制了,所以不能生成corefile文件.

如果要使用corefile文件分析程序和系统异常信息,可以通过如下命令打开,其中unlimited表示corefile文件的大小无限制.

$ ulimit -c unlimited

这种设置方式虽然简单,但它却只是跟shell相关的,也就是说,如果我们关闭了当前shell再打开一个,则刚才的设置就失效了,这是很不方便的,可以将ulimit -c unlimited 放入/etc/profile中,然后执行source /etc/profile即可立即生效。

如果想配置只针对某一用户有效,则修改此用户的~/.bashrc或者~/.bash_profile文件:

$ ulimit -c unlimited
$ source .bashrc 

3.设置Core Dump的核心转储文件目录和命名规则

默认corefile是生成在程序的执行目录下或者程序启动调用了chdir之后的目录,我们可以通过设置生成corefile的格式来控制它,让其生成在固定的目录下。

/proc/sys/kernel/core_uses_pid可以控制产生的core文件的文件名中是否添加pid作为扩展,如果添加则文件内容为1,否则为0
/proc/sys/kernel/core_pattern可以设置格式化的core文件保存位置或文件名,比如原来文件内容是core-%e

# echo "/home/saneri/corefile/core-%e-%p-%t" > /proc/sys/kernel/core_pattern

将会控制所产生的core文件会存放到corefile目录下,产生的文件名为core-命令名-pid-时间戳

或者(Ubuntu下使用此方法)

$ sysctl -w kernel.core_pattern=/corefile/core-%e-%p-%t

如果想让每次启动都保存设置,则需要写入配置文件中.

# echo "kernel.core_pattern=/home/saneri/corefile/core-%e-%p-%t" >> /etc/sysctl.conf 
# sysctl -p /etc/sysctl.conf 
kernel.core_pattern = /home/saneri/corefile/core-%e-%p-%t

关于格式的的控制有如下几个参数:

复制代码

%%:相当于%
%p:相当于<pid>
%u:相当于<uid>
%g:相当于<gid>
%s:相当于导致dump的信号的数字
%t:相当于dump的时间
%e:相当于执行文件的名称
%h:相当于hostname

复制代码

4.测试是否能生成core文件

$ kill -s SIGSEGV $$

查看 corefile目录下是否生成了core文件 

5.用gdb查看core文件

gdb -c core文件路径 [应用程序的路径]

进去后输入where回车, 就可以显示程序在哪一行当掉的, 在哪个函数中.

 ################################################################################

设置方法二:

1.用户家目录下建立corefiles文件夹.

$ mkdir corefiles

2.修改/etc/init.d/apport文件,在do_start 函数中添加 echo "/home/ubuntu/corefiles/core-%e-%p-%t" > /proc/sys/kernel/core_pattern  (注意替换为你的 corefiles 目录的路径),注释掉原来的 echo "|$AGENT %p %s %c %d %P" > /proc/sys/kernel/core_pattern;

复制代码

do_start()
{
        # Return
        #   0 if daemon has been started
        #   1 if daemon was already running
        #   2 if daemon could not be started

        [ -e /var/crash ] || mkdir -p /var/crash
        chmod 1777 /var/crash

        # check for kernel crash dump, convert it to apport report
        if [ -e /var/crash/vmcore ] || [ -n "`ls /var/crash | egrep ^[0-9]{12}$`" ];then
            /usr/share/apport/kernel_crashdump || true
        fi

        # check for incomplete suspend/resume or hibernate
        if [ -e /var/lib/pm-utils/status ]; then
                /usr/share/apport/apportcheckresume || true
                rm -f /var/lib/pm-utils/status
                rm -f /var/lib/pm-utils/resume-hang.log
        fi

        echo "/home/ubuntu/corefiles/core-%e-%p-%t" > /proc/sys/kernel/core_pattern
        #echo "|$AGENT %p %s %c %P" > /proc/sys/kernel/core_pattern
        echo 2 > /proc/sys/fs/suid_dumpable
}

复制代码

3.添加用户系统变量.在.bashrc文件底部添加如下:

$ vim .bashrc

ulimit -c unlimited
$ source .bashrc 

 当系统异常时就会在corefiles文件目录下生成core文件。

 

 4. 使用GDB解析corefiles

总结一下,需要定位进程挂在哪一行我们只需要4个操作,

ulimit -c unlimited

echo "/tmp/core-%e-%p" > /proc/sys/kernel/core_pattern

gcc -o main -g a.c

gdb main /tmp/core-main-10815 

就可以啦。

 

GDB 常用操作

上边的程序比较简单,不需要另外的操作就能直接找到问题所在。现实却不是这样的,常常需要进行单步跟踪,设置断点之类的操作才能顺利定位问题。下边列出了GDB一些常用的操作。

  • 启动程序:run

     

  • 设置断点:b 行号|函数名

     

  • 删除断点:delete 断点编号

     

  • 禁用断点:disable 断点编号

     

  • 启用断点:enable 断点编号

     

  • 单步跟踪:next 也可以简写 n

     

  • 单步跟踪:step 也可以简写 s

     

  • 打印变量:print 变量名字

     

  • 设置变量:set var=value

     

  • 查看变量类型:ptype var

     

  • 顺序执行到结束:cont

     

  • 顺序执行到某一行: util lineno

     

  • 打印堆栈信息:bt
  • 打印全部线程堆栈: thread apply all bt

 

 

 

### Ubuntu 中出现 `Segmentation fault (core dumped)` 错误的原因 `Segmentation fault (core dumped)` 是一种常见的运行时错误,通常发生在程序试图访问未分配给它的内存区域时。这可能是由多种原因造成的: - **非法内存访问**:当程序尝试读取或写入不属于其地址空间的内存位置时会发生此情况[^1]。 - **空指针解引用**:如果程序尝试通过一个指向 NULL 的指针来访问数据,则会触发该错误[^5]。 - **栈溢出**:函数调用层次过深或者局部变量占用过多堆栈空间也会导致此类异常[^2]。 对于特定于 VMware Tools 安装过程中遇到的问题,可能是因为内核模块编译失败或者是某些依赖库缺失所引起[^3]。 ### 解决方案 #### 方法一:更新系统并重新安装 VMware Tools 确保操作系统处于最新状态可以修复一些潜在兼容性问题: ```bash sudo apt update && sudo apt upgrade -y ``` 接着卸载旧版工具再进行全新安装: ```bash sudo vmware-uninstall-tools.pl # 或者使用如下命令移除残留配置文件 sudo rm -rf /usr/lib/vmware* sudo apt install open-vm-tools-desktop fuse reboot ``` #### 方法二:调整 Python 导入库顺序 针对 Python 编程环境下发生的崩溃现象,适当调整第三方扩展加载次序有助于规避冲突风险: ```python import torch # 将 PyTorch 库置于首位引入 ... if __name__ == '__main__': ... ``` 同时精简不必要的 import 语句以减少资源消耗和初始化时间开销。 #### 方法三:启用 Core Dump 文件调试功能 为了更深入地分析具体哪一部分代码引发了故障,可以通过设置环境变量允许生成核心转储文件用于后续排查工作: ```bash echo "ulimit -c unlimited" >> ~/.bashrc source ~/.bashrc ``` 之后依据不同发行版本定位 core dump 存放目录,并借助 gdb 工具解析其中记录的信息找出根本所在[^4]: ```bash gdb ./your_program path_to_core_file (gdb) bt full ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值