0x0 情景说明

在新安装的Fedora 27系统上执行存在“非法内存访问”的程序，提示“segmentfault”，但是当前目录下无CORE文件产生。

0x1 解决过程

在解决该问题时，避免不了各种百度。其中一般的处理步骤为：

• $ ulimit -c unlimited #将CORE的大小设置成无限大

• 修改 /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

本文转载自异步社区

原文链接：https://www.epubit.com/articleDetails?id=Nb5fe85e1-3a32-4809-9ae4-84bb29c979a4