Неиспользуемый вывод pstack для дампа ядра в Solaris
Вывод pstack, примененный к coredump, должен содержать обратную трассировку стека для каждого потока. Но в некоторых случаях выходные данные содержат усеченные обратные следы для каждого потока, только одну запись на поток. Вот пример, показывающий выдержку из вывода 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++, и это, вероятно, потому, что процессор выполнял код приложения во время дампа ядра. Но почему все обратные следы усекаются?
В прошлый раз, когда это произошло, сбойный поток выбросил SIGABRT, в соответствии с pflags, примененным к тому же дампу ядра.
На диске достаточно места для дампа ядра и нет проблем с разрешениями на запись дампа ядра. Машина Sparc с 32 ядрами, SunOS 5.10 Generic_144488-17. Приложение построено с помощью gcc 4.7.2.