Ubuntu下corefile生成以及解析

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

 

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值