0x0 情景说明
在新安装的Fedora 27系统上执行存在“非法内存访问”的程序,提示“segmentfault”,但是当前目录下无CORE文件产生。
0x1 解决过程
在解决该问题时,避免不了各种百度。其中一般的处理步骤为:
1、$ ulimit -c unlimited #将CORE的大小设置成无限大
2、修改 /proc/sys/kernel/core_pattern 文件,需要root权限,具体可自行百度。
然而这两种方案都不好使。怎么办呢?这个过程中我还学会了使用 journalctl -a 看系统日志、使用 sysctl KEY=VALUE 修改系统参数,其中包括 kernel.core_pattern 参数、使用 systemctl subcommand service 操作系统服务(service已经过时)。
在学会了使用 journalctl -a 查看系统日志时,我就经常运行程序,并观察该日志。其实日志中已经打印出了一些程序core时的堆栈信息,但是不够全面,无法通过gdb调试。我有另外一台虚拟机装的应该是fedora23,那台虚拟机可以,我例行检查了上述“处理步骤”中的配置,发现 /proc/sys/kernel/core_pattern 这个值与我不同,其值为:|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t %e。而我当前的为:|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e。简单的做法就是拷贝过来,然后看看abrt-hook-ccpp服务是否启动了。修改完core_pattern,并启动abrt-hook-ccpp服务后执行程序,还是无法生成core。这个时候我就开始关注abrt这个服务程序了,从名字和man的信息来看,这个服务应该就是处理bug reporting的服务。那么为什么在23发行版上abrt-hook-ccpp服务是启动的,而27就默认关闭了呢?还有个问题就是23上 ulimit -c默认是0,而27默认是unlimited,我意识到可能在新版上产生core的行为发生了变化。
于是继续百度,直到找到了这篇官方的文章fedoraproject.coredumpctl , 所有的疑惑都解开了。
0x2 解决方案
从24发行版开始,fedora默认行为不会产生core文件。同时,ulimit中core size也默认设置成了ulimited。之前的版本会支持abrt-ccpp.service来获取core dump文件,该服务有自己的core_pattern,即/proc/sys/kernel/core_dump,它会覆盖由systemd产生的corepattern。24+后简单的禁用了该服务。默认会关闭abrt-ccpp.service,而使用abrt-journal-core。而我在27上,该服务确是关闭的,我推测是写上述文章的时候27还未出,可能开发团队又做了优化。那么在24+以后的系统调试core文件的方法其实更加友好和强大了。其使用了 coredumpctl这个工具,该工具可以在调试无论是终端用户产生的core还是后台服务产生的core,使用方法为:coredumpctl gdb。该命令会调试最近一次coredump并进入gdb调试模式。其他程序的调试,也可以通过 coredumpctl gdb pid来进行调试。
知道了这个更友好的调试方式,我还是对如何生成core的问题心存疑惑。最后还是在度娘的帮助下,知道了要修改这个参数:vi /etc/abrt/plugins/CCpp.conf 修改MakeCompatCore = yes。至此问题都解决了。
详细步骤为:
1、sysctl kernel.core_pattern="|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t %P %I”
2、vi /etc/abrt/plugins/CCpp.conf 修改MakeCompatCore = yes
3、 systemctl stop abrt-journal-core
4、 systemctl start abrt-ccpp
完!