问题标签 [coredump]

我正在运行 Fedora core 14。我有一个偶尔（很少）出现段错误的程序。最近发生这种情况时，我惊愕地注意到在段错误之后没有生成核心文件，所以我无法追溯 gdb 程序和核心文件。

我添加了一个交互式命令，以便我可以故意生成一个应该生成核心文件的故障，我发现有时会生成核心文件，有时不会生成。我已将 coredumpsize 限制设置为“无限制”，并且有足够的磁盘空间和可写的当前工作目录。

我想调试这个无法可靠生成核心文件的问题。（我敢肯定会有一些简单的解决方案，但到目前为止我还没有意识到。）

当 Linux 下的 gcc/g++ 程序出现段错误或发生浮动异常时，有人能告诉我在哪里可以找到生成核心转储文件的源代码吗？我希望查看有关如何生成核心转储文件的源代码将帮助我弄清楚为什么有时我没有得到一个。我正在运行 FC 14，Linux 内核 2.6.35.11-83。

提前感谢您的帮助！

格雷格·约翰逊

我目前正在研究"Creation of Postmortem data logger in Linux on Intel architecture". 它只不过是核心实用程序的创建。任何人都可以分享有关在 Linux 内核内部实现的应用程序崩溃时SIGSEGV,SIGABRT,SIGFPE etc产生的各种信号（）的信号处理程序的详细信息。core dump我需要根据自己的用户特定需求重新编写这些信号处理程序并重建内核。它使我的内核生成具有用户特定需求的核心文件（在应用程序崩溃时），例如显示registers,stackdump and backtrace etc.

任何人都可以分享有关它的详细信息....提前感谢所有回复者:)

我在几个不同的 Fedora Core 9 Hudson Slaves 上看到了 glibc 中偶尔出现的分段错误。我尝试将每个从属配置为生成核心文件并将它们放在 /corefiles 中，但没有运气。

这是我在每个 linux slave 上所做的：

1）创建corefile存储位置
sudo install -m 1777 -d /corefiles

2) 通过将以下内容添加到/etc/sysctl.conf将核心文件定向到存储位置
kernel.core_pattern = /corefiles/core.%e-PID:%p-%t-signal_%s-%h

3) 通过将以下内容添加到/etc/profile为所有用户启用无限核心文件
ulimit -c unlimited

是否需要一些额外的 Linux 魔法，或者我需要对 Hudson slave 或 JVM 做些什么？

谢谢您的帮助

我有一个分配错误，我得到一个段错误，在读取核心转储时会给出：

这是我相信它所指的代码片段。

这是检索功能：

飞行记录：

飞行地图.h

在 gdb 中输入 bt 后，输出如下：

如何从核心转储文件中获取堆栈跟踪？该文件大约为 14 mb，是在我的应用程序退出并说“分段错误”后生成的

我在红帽 5.5

我正在尝试从我正在编写的代码中获取可用的核心转储。我的源位于我在 Windows 和 Linux 操作系统之间共享的 NTFS 分区上。我正在 Linux 下进行开发，并ulimit -c unlimited在我的 bash shell 中进行了设置。当我在 NTFS 分区上执行我的项目目录中的代码并故意导致 SIGSEGV 或 SIGABRT 时，系统会写入一个零字节的核心转储文件。

如果我在我的主目录（一个 ext4 分区）中执行二进制文件，核心转储就可以生成。我查看了 core 的手册页，其中列出了不生成核心转储文件的各种情况。但是，我认为这不是权限问题，因为该分区上的所有文件和目录都具有完全权限 ( chmod 777)。

任何帮助或想法表示赞赏。

我在下面的程序运行时得到核心转储：

我收到了 SIGABRT 信号。请建议我处理此 SIGABRT 信号的方法。

我在 Aix 5.3 和 gcc 4.2.4 上有 application.so。Application.so 使用 boost:asio。有 example.c 为 application.so 执行 dlopen 和 dlclose。但是，当 example.c 退出时 - 我得到一个核心转储。请注意，所有操作均已成功执行。

如果我在 application.so 中注释掉与 boost 相关的代码，并且在构建 application.so 时仍然链接 boost_system.so，我仍然会在退出 example.c 时获得核心转储。但是，如果我在构建 application.so 时没有链接 boost_system.so，我在退出 example.c 时不会得到任何核心转储。

我试过 boost_1_40、boost_1_42、boost_1_45 和 gcc 4.2.0。有没有人见过这个问题。如果是，任何帮助将不胜感激。

上面的部分是问题发生的地方。一旦 example.c 退出，我就会得到核心转储。

编辑

使用 boost-system 构建 application.so 时，我收到以下警告：-

ld: 0711-224 WARNING: Duplicate symbol: .non-virtual thunk to boost::exception_detail::error_info_injector<boost::system::system_error>::~error_info_injector

ld: 0711-224 WARNING: Duplicate symbol: .non-virtual thunk to boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >::~clone_impl()

ld: 0711-224 WARNING: Duplicate symbol: .non-virtual thunk to boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >::~clone_impl()

ld: 0711-224 WARNING: Duplicate symbol: .non-virtual thunk to boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >::clone() const

ld: 0711-224 WARNING: Duplicate symbol: .non-virtual thunk to boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >::rethrow() const

ld: 0711-224 WARNING: Duplicate symbol: .non-virtual thunk to boost::exception_detail::error_info_injector<boost::system::system_error>::~error_info_injector::system_error> >::~clone_impl()

ld: 0711-224 WARNING: Duplicate symbol: .non-virtual thunk to boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system:

ld: 0711-224 WARNING: Duplicate symbol: .non-virtual thunk to boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >::~clone_impl()

ld: 0711-224 WARNING: Duplicate symbol: .global destructors keyed to ras_arg_t

ld: 0711-224 WARNING: Duplicate symbol: .global constructors keyed to ras_arg_t

我假设这些重复的析构函数在 dlclose 期间没有被调用，而是在退出期间被调用——此时库被卸载。

没有深入挖掘 GDB 源代码，我在哪里可以找到有关用于创建核心文件的格式的文档？

ELF规范让核心文件格式保持开放，所以我想这应该是 GDB 规范的一部分！遗憾的是，我没有从 GNU 的 gdb 文档中找到这方面的任何帮助。

这就是我想要做的：将虚拟地址映射到包含正在运行的进程的可执行文件/库中的函数名称。为此，我首先想从核心文件中找出从虚拟地址空间到可执行文件/库名称的映射，然后挖掘相关文件以获取符号信息。

现在'readelf -a core'告诉我核心文件中几乎所有的段都是'load'类型——我猜这些是所有参与文件中的.text和.bss/.data段，加上一个堆栈段。除了这些加载段之外，还有一个音符段，但似乎不包含地图。那么一个段对应哪个文件的信息，是如何存储在核心文件中的呢？这些“加载”段格式是否以特定方式包含文件信息？

它并不总是发生，但会在服务器应用程序运行一段时间后发生。

是什么原因，我该如何解决？

代码如下：

核心转储：