应用于核心转储的 pstack 输出应包含每个线程的堆栈回溯。但在某些情况下，输出包含每个线程的截断回溯，每个线程只有一个条目。这是一个示例，显示了 pstack 输出的摘录：
core 'core' of 8714: ./rds_rdprod.solsparc64
----------------- lwp# 1 --------------------------------
ffffffff7c2d7bd0 ???????? (ffffffff7ffff5b0, ffffffff7ffff570, 0, 4, 16cf50, ffffffff7c10d240)
----------------- lwp# 2 --------------------------------
ffffffff7c2d7bd0 ???????? (100bf12b0, 100bf12d8, 0, 4, 16cf50, ffffffff7c10e9c0)
----------------- lwp# 3 --------------------------------
ffffffff7c2d7bd0 ???????? (100bf12b0, 100bf12d8, 0, 4, 16cf50, ffffffff7c10e9c0)
----------------- lwp# 4 --------------------------------
ffffffff7c2d7bd0 ???????? (100bf12b0, 100bf12d8, 0, 4, 16cf50, ffffffff7c10e9c0)
----------------- lwp# 5 --------------------------------
ffffffff7c2d7bd0 ???????? (100bf12b0, 100bf12d8, 0, 4, 16cf50, ffffffff7c10e9c0)
... [omitting a number of threads]
----------------- lwp# 52 --------------------------------
ffffffff7c2d7bd0 ???????? (105286af0, 105286b18, 0, 4, 16cf50, ffffffff7c10f600)
----------------- lwp# 53 --------------------------------
0000000100196e80 _ZN9CAtomMap43AddEP6CAtom4S1_ (5ad245980, 19f6751f8, 19f6751f8, 19f6751f8, 25bf97af0, 28) + 60
----------------- lwp# 54 --------------------------------
00000001001a1de8 _ZN12CBasicSearch6ExistsER18ICacheItemIdentity (19b43ed78, ffffffff6faff3b8, 6, 0, 0, 2aa932388) + 28
----------------- lwp# 55 --------------------------------
ffffffff7d300838 ???????? (0, 287812ec8, 5382b3098, 45dde3558, 188ce9053, 15faa9d38)
... [omitting a number of threads]
如您所见，每个 LWP 只有一行，我们通常会在其中获得完整的回溯。您可能还会注意到一些线程有一个有效的损坏的 C++ 符号，这可能是因为处理器在核心转储时正在执行应用程序代码。但是为什么所有的回溯都会被截断呢？
根据应用于同一核心转储的 pflags，上次发生这种情况时，故障线程抛出了 SIGABRT。
核心转储有足够的磁盘空间，并且写入核心转储的权限没有问题。机器是 32 核的 Sparc，SunOS 5.10 Generic_144488-17。应用程序是使用 gcc 4.7.2 构建的。