为什么我的 Redhat 服务器上的 QuickFIX 进程没有将其核心文件写入应有的位置?

Why does a QuickFIX process on my Redhat server not write its core file where it should?

本文关键字：文件核心位置我的服务器 QuickFIX 进程为什么 Redhat 更新时间：2023-10-16

我在 Redhat 6.9 服务器上运行了 10 个C++程序，全部使用一些内部开发的库。其中一个库实现日志记录，并使日志文件的文件描述符 3 保持打开状态。如果任何进程收到分段冲突信号(信号 11)，则会在/tmp 中生成一个核心文件，这是根据/proc/sys/kernel/core_pattern 的预期。但是，特别是 1 个进程不这样做。如果它得到信号 11，它将核心文件写入日志文件，这变得无用，因为日志消息与二进制核心信息交错。此过程的主要不同之处在于它使用 QuickFIX C++库版本 1.14.3。我有该库的来源，并搜索了它以查看它可能会导致这种情况。它覆盖的唯一信号处理程序是SIGPIPE。它会打开一些文件，但不专门对文件描述符 3 执行任何操作。QuickFIX 进程使用大约 8GB 的内存，但使用更多内存的进程会正确写入其核心文件，因此我认为这不是文件大小问题。

任何想法 QuickFIX 库可以做什么来导致核心文件无法到达应有的位置，或者任何其他可以执行此操作的事情？

您确定该进程实际上是将核心转储写入日志文件，而不仅仅是崩溃前的随机数据吗？您是否尝试过禁用核心转储生成？您实际上在日志文件中看到特征177ELF序列吗？

如果将核心转储写入崩溃过程的打开文件描述符，这将是一个非常严重的内核错误。考虑到内核中的核心转储实现，我真的看不出这是怎么发生的。

事实证明，该问题与QuickFIX无关。这是一个甲骨文问题。我需要补充：

DIAG_SIGHANDLER_ENABLED=FALSE

到 $ORACLE_HOME/network/admin/sqlnet.ora 文件。我仍然不确定为什么这只发生在QuickFIX过程中，而不是其他任何C++Oracle进程，但现在这并不重要。

使用 strace显示 SIGKILL 信号正在中断 SIGSEGV 处理程序，并且在 strace 输出中紧挨着 Oracle 错误消息。它还表明，Oracle正在为包括SIGSEGV在内的许多信号安装自己的信号处理程序。这些信息将我引向另一个StckOverflow答案：用于SIGSEGV/SIGABRT和朋友的Oracle Pro*C/OCI安装处理程序 - 为什么以及如何禁用？