コアダンプに適用される pstack の出力には、すべてのスレッドのスタック バックトレースが含まれている必要があります。ただし、場合によっては、各スレッドの切り捨てられたバックトレースが出力に含まれ、スレッドごとに 1 つのエントリのみが含まれます。次に、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 ごとに 1 行しかなく、通常はここで完全なバックトレースを取得します。また、いくつかのスレッドに有効なマングルされた C++ シンボルがあることにも気付くかもしれません。これはおそらく、コア ダンプの時点でプロセッサがアプリケーション コードを実行していたためです。しかし、なぜすべてのバックトレースが切り捨てられるのでしょうか?
これが最後に発生したとき、同じコア ダンプに適用された pflags によると、障害のあるスレッドが SIGABRT をスローしました。
コア ダンプ用の十分なディスク容量があり、コア ダンプを書き込む権限に問題はありません。マシンは 32 コアの Sparc、SunOS 5.10 Generic_144488-17 です。アプリケーションは gcc 4.7.2 でビルドされています。