背景说明：
在程序产生了奔溃，而 未打开产生core dump配置（即ulimit -c unlimited）等，或者打开了core dump 配置而产生的core文件过大无法拷贝或者难以从现场拿回。开发人员通过日志确认问题时，很多时候因日志注释不够全面或者core时把日志给截断了而导致日志不全，难以分析。
方法说明：
Linux 环境中如果发生Segmentation fault等问题core dump 时，在系统日志中一般都可以存储日志信息，而且信息中存在有一个符号地址，该地址则是发生问题所在或者附近。故而此时可以去查看系统日志，且过滤出需要的信息找到该地址值。在得到该地址值后则可以根据编译时的map 文件去对应找到出问题的代码所在处。如果map文件不存在，则将代码回退至发布的版本进行编译得到map 文件，但需要保证编译环境是一样的，因为不同环境的red hat对应的各文件标记符号映射关系不一样。
验证说明：
使用如上代码编辑进行运行，代码中标红之处，在运行时会产生段错误进而程序崩溃。此时如果没有ulimit -c unlimited 则不会产生core dump 文件。但可以到系统日志中查看到系统日志中有记录说明该程序在运行时发生了段错误，而且带有一个地址信息,于/var/log/messages 文件可查看 。
上图中在 /var/log/messages
此时再次去test程序对应的map 文件中查找4009dc 这个地址的位置或者其附近的代码可看到其里main 函数最近，进而可确定发生文件的位置在main 函数中，最后在计算其偏移量去确定具体位置。
对比使用ulimit -c unlimited 打开后产生core文件可看出其对应的位置是一致的：
备注：
1、系统日志不一定是在/var/log/messages 这个文件中，可能是其它文件中，但是其是按照日期存在，按照对应文件去取即可。
