我已经和我的客户合作了一段时间，试图确定他们的 Solaris SPARC 系统上核心文件生成的一些奇怪行为。他们当前的 Solaris 版本是 11.4-11.4.44.0.1.113.4。应用程序是使用 GCC 11.2 和 -g 构建的。应用程序和核心文件使用 GDB 10.2 和 pstack 进行调试。
我为客户提供了一个特殊的工具来帮助分析和诊断这个问题。应用程序所做的只是由于分段错误而生成核心文件。
问题：在客户端系统上生成的核心文件不会使用 GDB 显示堆栈、变量或内存信息。但是在我的任何开发系统上使用完全相同的可执行文件生成的核心文件都将生成可以调试的核心文件。
起初我认为这可能与 Solaris 11.4 补丁不兼容有关。我针对从客户端获得的核心文件集尝试了从 11.4.39 到 11.4.47 的每个 Solaris 补丁级别，但没有产生任何显着差异。
例如，在开发系统中，核心文件将在 GDB 中生成。
。 。 。
从 core_dump_tool.exe 读取符号...
[新 LWP 1]
[启用使用libthread_db进行线程调试]
[新线程 1 (LWP 1)]
核心由“./core_dump_tool.exe”生成。
程序因信号 SIGSEGV（分段错误）而终止。
#0 0xfe3cdc80 in _malloc_unlocked () 来自 /usr/lib/libc.so.1
[当前线程为 1 (LWP 1 )]
（gdb）哪里
#0 0xfe3cdc80 in _malloc_unlocked () 来自 /usr/lib/libc.so.1
#1 0xfe3cd9d4 in do_malloc () 来自 /usr/lib/libc.so.1
#2 缓冲区溢出中的 0x00011a40 (iDataLength=100, cpData=0xffbff140 "01234567890123456789012345678901234567890123456789012345678901234567890123456789012 34567890123456789”）在 core_dump_tool.c:82
#3 0x00011f80 in main () at core_dump_tool.c:232
回溯停止：此帧内的前一帧（堆栈损坏？）
(gdb) 退出
。 。 。
当完全相同的应用程序在客户端系统上运行时，生成的核心文件将在 GDB 中生成此文件
。 。 。
从 core_dump_tool.exe 读取符号...
[新 LWP 1]
[启用使用libthread_db进行线程调试]
[新线程 1 (LWP 1)]
核心由“core_dump_tool.exe”生成。
程序因信号 SIGSEGV（分段错误）而终止。
#0 0xfeb6daf0 in _malloc_unlocked () 来自 /usr/lib/libc.so.1
(gdb) BT
#0 0xfeb6daf0 in _malloc_unlocked () 来自 /usr/lib/libc.so.1
#1 0x00022514 在 ?? ()
回溯停止：前一帧与此帧相同（堆栈损坏？）
(gdb) 退出
。 。 。
关于客户的系统以及在其系统上生成的核心文件的问题。
- 该问题于 2021 年 12 月首次出现。我能够从 2021 年 9 月到 2021 年 12 月初之间的某个时间缩小核心文件问题的范围。
- 客户不知道这段时间生产机器发生了什么变化。他们找不到任何记录，管理员已经离开。
- 我已向客户端请求受影响系统的 coreadm 和 dumpadm 配置，但尚未收到任何信息。
如果有人对客户可能对其系统所做的影响生成的核心文件有任何想法或想法，我们将不胜感激。
答案1
您的客户端在相关系统上的核心文件大小可能有限。
Solaris 将堆栈信息写入核心文件最后的，因此如果核心文件大小受到任何资源限制，堆栈信息将不会写入核心文件。并且核心文件对于调试来说实际上毫无用处。
Solaris 上只有两个有用的核心文件大小限制设置： 0防止创建核心文件，unlimited因此生成的核心文件实际上是有用。
还有关于设置的注释coreadm- 如果您更改进程当前工作目录中的默认核心文件模式，core以便执行诸如捕获核心文件名中的进程名称、pid、时间和类似数据之类的操作和/或保留更多信息比最后一个核心文件命名core，或者使用全局核心文件设置将所有核心文件捕获到公共位置，现在您必须主动管理核心文件，以免它们填满您的存储空间。
如果关键系统上的进程进入快速故障切换状态，并且每次都会生成新的核心文件，会发生什么情况？磁盘填满，系统崩溃，这一切都是因为您设置了用于coreadm保留所有核心文件的核心文件名模式。
哎呀。
切勿告诉客户设置核心文件名模式以保留所有核心文件（或配置您自己的系统来执行此操作），而不告诉他们如果这样做，他们将必须主动管理这些系统上的核心文件。
“主动管理核心文件”并不意味着“每天运行一次 cron 作业”——无论您采取什么措施，都必须能够处理每分钟生成 500 个核心文件的失控进程。
或者至少告诉他们使用写入专用文件系统的全局核心文件，该文件系统无法填满系统存储的其余部分，这样，如果该专用核心文件集合文件系统确实填满了，则不会对其余部分造成损害系统的。