在运行C程序时,它说“(核心转储)”,但我看不到当前路径下的任何文件。
我已经设置并验证了ulimit:
ulimit -c unlimited
ulimit -a
我还试图找到一个名为“核心”的文件,但没有得到核心转储文件? 有人帮忙吗,我的核心文件呢?
在运行C程序时,它说“(核心转储)”,但我看不到当前路径下的任何文件。
我已经设置并验证了ulimit:
ulimit -c unlimited
ulimit -a
我还试图找到一个名为“核心”的文件,但没有得到核心转储文件? 有人帮忙吗,我的核心文件呢?
当前回答
如果您在RHEL上缺少二进制文件的核心转储,并且在使用abrt时, 确保/etc/abrt/abrt-action-save-package-data.conf
包含
ProcessUnpackaged = yes
这允许为不属于已安装包(例如本地构建的)的二进制文件创建崩溃报告(包括核心转储)。
其他回答
我可以想到以下两种可能性:
正如其他人已经指出的那样,程序可能会chdir()。是否允许运行程序的用户写入chdir()指定的目录?如果没有,则不能创建核心转储。 出于某种奇怪的原因,内核转储不命名为core。你可以检查/proc/sys/kernel/core_pattern。此外,您命名的find命令不会找到典型的核心转储。你应该使用find / name "*core "。*”,因为coredump的典型名称是core.$PID
编写在Ubuntu 16.04 LTS下获得核心转储的指令:
As @jtn has mentioned in his answer, Ubuntu delegates the display of crashes to apport, which in turn refuses to write the dump because the program is not an installed package. To remedy the problem, we need to make sure apport writes core dump files for non-package programs as well. To do so, create a file named ~/.config/apport/settings with the following contents: [main] unpackaged=true Now crash your program again, and see your crash files being generated within folder: /var/crash with names like *.1000.crash. Note that these files cannot be read by gdb directly. [Optional] To make the dumps readble by gdb, run the following command: apport-unpack <location_of_report> <target_directory>
引用: Core_dump - Oracle VM VirtualBox
如果您在RHEL上缺少二进制文件的核心转储,并且在使用abrt时, 确保/etc/abrt/abrt-action-save-package-data.conf
包含
ProcessUnpackaged = yes
这允许为不属于已安装包(例如本地构建的)的二进制文件创建崩溃报告(包括核心转储)。
对于fedora25,我可以在
/var/spool/abrt/ccpp-2017-02-16-16:36:51-2974/coredump
where ccpp-2017-02-16-16:36:51-2974" is pattern "%s %c %p %u %g %t %p % as per ' /proc/sys/kernel/core_pattern'
Ulimit -c unlimited使内核文件在“内核转储”后正确地出现在当前目录中。