Embedded Linux Core Dump 调试方法

在为嵌入式打开Core Dump的时候遇到了一开始想不到的问题，挺有意思

大多数论坛里说的打开Core Dump的方法就是按照如下几个步骤就能实现

1. 在make menuconfig里打开core dump选项

    Userspace binary formats --> Enable core dump support

    General setup --> Configure standard kernel features --> Enable ELF core dumps

2. 程序运行前执行 ulimit -c unlimited，在检查ulimit -c确认开启成功

正常pc机在程序这两步就能产生core文件

 

笔者的挂死的进程有此特点：在rcS.d的脚本以后台方式运行进程

按照以上打开core dump的说明，在ulimit -c确认时获得返回值为0

查到在下列条件下不产生core文件：
( a )进程是设置-用户-ID，而且当前用户并非程序文件的所有者；
( b )进程是设置-组-ID，而且当前用户并非该程序文件的组所有者；
( c )用户没有写当前工作目录的许可权；
( d )文件太大。core文件的许可权(假定该文件在此之前并不存在)通常是用户读/写，组读和其他读。

先为所有终端环境都开启ulimit -c unlimited，在/etc/profile文件加入ulimit -c unlimited

掉电上电，此时ulimit -c可确认core dump已经打开，在终端里运行一场程序，产生了core dump

但是笔者的在rcS.d的脚本以后台方式运行进程异常死掉，依然没有core dump

再满足(a)(b)，因为我们知道我们查看core文件是在root用户下查看的，所以在rc5.d的脚本中使用指定的用户来执行命令

su - root -c "/usr/bin/msgdeliver &"

放后台也会脱离终端导致不产生core dump，所以就做重定向core文件

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

然后core.msgdeliver.xxx.xxx就糊里糊涂的出来了

 

 

查到一段，ulimit作用范围的描述

1. 能够影响ulimit的参数会有这几个文件，除了/etc/profile,/etc/init.d/functions, /etc/security/limits.conf几个系统默认文件外，以及任何写入的ulimit命令的脚本，如用户目录下的. bash_profile文件。
2. ulimit是随着进程的启动而生效的，它只能影响当前父进程以及由它衍生出来的子进程，一旦父进程结束，ulimit的值就将使用系统默认值。
3. 进程启动所获得的ulimit值与用户登录进去用ulimit -a所查看的值是两个概念。这一点可能不太明白，因为linux启动的时候会启动init这个程序，调用inittab ->rc.sysinit->rcx.d->rc.local->minigetty开始侦听，因此进程启动时的ulimit只 是在rcx.d下的启动脚本中设置，并在进程中继承，而用户登录系统时，会去读取/etc/profile配置文件，因而无关，这就是为什么那么多人迷惑 的地方。

 

 

未完待续...