在嵌入式的开发和测试中,有时候一些问题只能在特定的环境下才能重现,重现的时机和条件都难以把握,可能很多次的测试才能偶尔的重现一次问题,这给我们的调试和修改都带来很多不便之处
还有一种难以跟踪调试的情形,在大型的软件项目中,要从数万行甚至更多的代码中准确的找到问题所在,靠设断点和单步跟踪的方法是很麻烦很需要时间的.
这些问题可以通过Core Dump的方式,或者说事后调试(postmortem debug)技术,来协助分析.主要方法是在程序崩溃的时候,将程序的内存映象加上调试信息保存到一个文件中,这后通过分析这个所谓的Core文件来找到程序崩溃的原因.Core Dump的名称来源于以前工业界的叫法---当内存还是线圈的时候,它被叫做Core,我们可以利用GDB来分析core文件来查找出错的原因.
Back in the day, a computer's main memory was built out of ferrite core. This is where the phrase "core dump" comes from: the main memory image of a program stored in a file on disk for diagnosis |
1. core文件的简单介绍
在一个程序崩溃时,它一般会在指定目录下生成一个core文件。core文件仅仅是一个内存映象(同时加上调试信息),主要是用来调试的。
2. 开启或关闭core文件的生成
用以下命令来阻止系统生成core文件:
ulimit -c 0
下面的命令可以检查生成core文件的选项是否打开:
ulimit -a
该命令将显示所有的用户定制,其中选项-a代表“all”。
也可以修改系统文件来调整core选项
在/et