我有 10 个 C++ 程序在 Redhat 6.9 服务器上运行，全部使用一些内部开发的库。其中一个库实现日志记录，并为日志文件保持文件描述符 3 打开。如果任何进程收到分段违规信号（信号 11），则会按照 /proc/sys/kernel/core_pattern 的预期在 /tmp 中生成核心文件。然而，特别是 1 进程不执行此操作。如果它收到信号 11，则会将核心文件写入日志文件，这会变得无用，因为日志消息与二进制核心信息交织在一起。此过程的主要不同之处在于它使用 QuickFIX C++ 库版本 1.14.3。我有该库的源代码，并对其进行了搜索，看看它可能做了什么导致了这种情况。它覆盖的唯一信号处理程序是 SIGPIPE。它打开一些文件，但对文件描述符 3 不执行任何操作。QuickFIX 进程使用大约 8GB 内存，但使用更多内存的进程可以正确写入其核心文件，因此我认为这不是文件大小问题。
您知道 QuickFIX 库可能会做什么来导致核心文件不去它应该去的地方，或者其他任何可能会这样做的事情吗？
您确定该进程实际上是将核心转储写入日志文件，而不仅仅是崩溃前的随机数据吗？您是否尝试过禁用 coredump 生成？您确实在日志文件中看到了特征
\177ELF如果将 coredump 写入崩溃进程的打开文件描述符，这将是一个非常严重的内核错误。考虑到内核中的 coredump 实现，我真的不明白这是如何发生的。
事实证明该问题与 QuickFIX 无关。这是一个 Oracle 问题。我需要补充：
DIAG_SIGHANDLER_ENABLED=FALSE
到 $ORACLE_HOME/network/admin/sqlnet.ora 文件。我仍然不确定为什么这只发生在 QuickFIX 进程中，而不是任何其他 C++ Oracle 进程中，但现在这并不重要。
使用 strace 显示 SIGKILL 信号正在中断 SIGSEGV 处理程序，并且在 strace 输出中紧接着在此之前有一条 Oracle 错误消息。它还表明 Oracle 正在为许多信号安装自己的信号处理程序，包括 SIGSEGV。此信息引导我找到另一个 StckOverflow 答案：Oracle Pro*C/OCI install handlers for SIGSEGV/SIGABRT 和朋友 - 为什么以及如何禁用？