コアダンプのトラブルシューティング

CscTsWebDocs · ‎2013-04-11

コアダンプイベントの特定
コアダンプファイルのリスト表示
コア分析の実行
Core File のバックトレースの概要
例 1：ファイルサイズ制限の超過
例 2：メモリリークがプロセスメモリの最大サイズに達した場合のコア
例 3：コアスタックの破損
シスコバグツールキットでの検索
意図的な強制終了のトラブルシューティング
TAC サービスリクエストを作成するときに役立つ情報

このドキュメントは、英語版（バージョン10）の日本語訳です。

最新の内容は英語版をご確認ください。

-------------------------------------------------------------------------------------------------------------

Linux プロセスで障害が発生するとコアダンプが作成されます。これにより、影響を受けるプロセスやサービスが停止します。回復するためには、プロセスやサービスを再起動する必要があります。このようなインシデントが発生してもサーバは稼働を続ける場合がありますが、特定のサービスが一時的に停止することがあります。この文書では、Communications Manager（CM または CUCM）、Unity Connection（UC）、Cisco Emergency Responder（CER）、Cisco Unified Presence Server（CUPS）、Cisco Unified Contact Center Express（UCCX または IPCC Express）、またはシスコの Voice Operating System（VOS）アプライアンスモデルに基づいた製品で発生する可能性のある、コアダンプとバックトレースのトラブルシューティングについて説明します。

コアダンプイベントの特定

CallManager でコアダンプの発生を特定する最も一般的な 2 つの方法を紹介します。

Alert Central で表示される CoreDumpFileFound RTMT アラートメッセージ

RTMT Alert Central でアラート選択項目を右クリックすることにより、コアを生成した特定のアプリケーションに関する詳細を表示できます。コアダンプアラートの詳細情報の例を以下に示します。

コアダンプの発生を示すアプリケーションイベントログアラートメッセージ：

May 15 05:32:09 ccm-pub local7 2 : 0: May 15 09:32:08.865 UTC :

%CCM_LPM-LPMTCT-2-CoreDumpFileFound: The new core dump file(s) have been found in the

system. TotalCoresFound:1 CoreDetails:The following lists up to 6 cores dumped by

corresponding applications. Core1:Cisco CallManager (core.10499.6.ccm.1273915815) App

ID:Cisco Log Partition Monitoring Tool Cluster ID: Node ID: ccm-pub

May 15 05:32:15 ccm-pub local7 2 : 138: May 15 09:32:15.231 UTC :
%CCM_RTMT-RTMT-2-RTMT-ERROR-ALERT: RTMT Alert Name:CoreDumpFileFound Detail:
CoreDumpFileFound TotalCoresFound : 1 CoreDetails : The following lists up to 6 cores
dumped by corresponding applications. Core1 : Cisco CallManager
(core.10499.6.ccm.1273915815) AppID : Cisco Log Partition Monitoring Tool ClusterID :
NodeID : ccm-pub . The alarm is generated on Sat May 15 05:32:08 EDT 2010. App
ID:Cisco AMC Service Cluster ID: Node ID:ccm-pub

コアダンプファイルのリスト表示

問題の CallManager サーバで以下のコマンドを実行すると、コアダンプのリストを取得できます。

utils core list （CallManager バージョン 5.x、6.x）

utils core active list （CallManager バージョン 7.x 以降）

「utils core list」の例を以下に示します。CCM サービスがコアダンプジェネレータとして表示されています。

「utils core active list」コマンドの出力は、「active」パラメータが含まれていることを除き、上記の例と同様です。このパラメータは、最近の CallManager リリースに追加され、バージョンの切り替えとリブートを実行する必要なく CM 非アクティブパーティション（アップグレードが行われている場合はシステム上の前の CM バージョン）の Core File をリスト表示できるようになりました。非アクティブパーティションの Core File のリスト表示は、コマンドラインパラメータとして「active」を指定する代わりに「utils core inactive list」を使います。

「utils core active list」の例を以下に示します。

コア分析の実行

リストコマンドによってコアダンプインスタンスが特定されたら、次に確認用の Core File のバックトレースを取得します。実行するには、以下のコマンドを使用します。

utils core analyze <CoreFileName> （CallManager バージョン 5.x、6.x）

utils core active analyze <CoreFileName> （CallManager バージョン 7.x 以降）

「utils core anayze」コマンドの例を以下に示します。この例では、2009 年 11 月 30 日午前 11 時 11 分 50 秒に生成された CCM サービスの Core File を表示しています。

「utils core active list」コマンドと同様に「utils core inactive analyze <CoreFileName>」コマンドを使って、非アクティブパーティションで Core File の分析を実行することもできます。この機能は CallManager 7.x 以降で利用できます。「utils core active analyze」コマンドのスクリーンショットを以下に示します。

どちらの例でも警告が表示されており、この実行によって大量の I/O が消費されてシステムパフォーマンスに影響がおよぶ可能性があることが示されています。分析プロセスの実行中に、raw Core File が解析されてバックトレース出力に解析結果が示されます。これを使って、コアダンプの原因を特定できます。

通常、分析プロセスは 1 分以内に完了します。システムパフォーマンスへの影響に関する警告では、潜在的なリソース問題を回避するためにこのコマンドをピーク時以外に実行するよう推奨します。

Core File のバックトレースの概要

コア分析プロセスで最も重要となるのは、確認用のバックトレースを取得することです。分析コマンドが実行されると、以下のスクリーンショットと同様の「Backtrace」というタイトルのセクションがコマンドラインに表示されます。

コアバックトレースの出力は、#0、#1、#2 などで示されるいくつかのプロセスコールで構成されます。これらはサービスの障害時にメモリに保存されたプロセスコールを示しています。多くの場合、これらのバックトレースシグニチャは固有のフィンガープリントであり、これらを使って CallManager の特定の既知または新規の障害を特定できます。

例 1：ファイルサイズ制限の超過

Core was generated by `/usr/local/cm/bin/ccm'.
Program terminated with signal 25, File size limit exceeded.

#0 0x0067a211 in __write_nocancel () from /lib/tls/libc.so.6
#1 0x00616d0f in _IO_new_file_write () from /lib/tls/libc.so.6
#2 0x00615c6e in new_do_write () from /lib/tls/libc.so.6
#3 0x00615c06 in _IO_new_do_write () from /lib/tls/libc.so.6
#4 0x006164ba in _IO_new_file_sync () from /lib/tls/libc.so.6
#5 0x0060abbb in fflush () from /lib/tls/libc.so.6
#6 0x08271749 in dBProcs::addDevice (this=0xee6b1a0,
deviceName=0xbc59c3e0 "SEP0022905BC978", deviceProtocol=0,
deviceType=Device7941G) at dBProcs.cpp:7388

この例ではプロセスがファイルに書き込みを行おうとしています。書き込みを行おうとすると、例外が発生して Core File が生成されます。原因である「Program terminated with signal 25, File size limit exceeded（シグナル 25：ファイルサイズ制限の超過によるプログラムの終了）」は、以下の内容と一致します。

CSCsu94937 Multiple services core dumping with signal 25, File size limit exceeded（シグナル 25：ファイルサイズ制限の超過による複数のサービスのコアダンプ）.

例 2：メモリリークがプロセスメモリの最大サイズに達した場合のコア

Memory leak in CCM process, resulting in intentional abort.

#0 0x00a157a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2

#1 0x01276825 in raise () from /lib/tls/libc.so.6

#2 0x01278289 in abort () from /lib/tls/libc.so.6

#3 0x0050d58b in __gnu_cxx::__verbose_terminate_handler () from /usr/local/cm/lib/libstlport.so.5.1

#4 0x0050b2a1 in __cxxabiv1::__terminate () from /usr/local/cm/lib/libstlport.so.5.1

#5 0x0050b2d6 in std::terminate () from /usr/local/cm/lib/libstlport.so.5.1

#6 0x0050b41f in __cxa_throw () from /usr/local/cm/lib/libstlport.so.5.1

#7 0x0050b86c in operator new () from /usr/local/cm/lib/libstlport.so.5.1

#8 0x0a06bb2d in SdlProcessBase::operator new (size=102700) at SdlProcessBase.cpp:105

#9 0x0a0014e2 in H245SessionManager::create (parentId={mSdlProcessName = 0x0, mSdlNodeId = 4, mSdlAppId = 100, mSdlProcessNumber = 150, mSdlProcessInstance = 2629}, vH245TerminalType=H245_Gateway, vH245TransportConnectionMode=H245Client, vH245IpAddress=404699044, vH245IpPort=40076, vTCPTos=96, vPassThruMSD=false, vTCSTimeout=10, vFastStartInd=0, vFsAudioOutgoingLCN=0, vFsAudioIncomingLCN=0, pktCaptureContext=0xbffab74d "", allowTCPKeepAlivesForH323=true) at ProcessH245SessionManager.cpp:221

#10 0x08a5629c in H245Interface::start_Transition (this=0xbff99008, s=@0x5c70990) at /vob/ccm/Common /Include/Sdl/SdlProcessBase.hpp:123

#11 0x08a99354 in H245Interface::fireSignal (this=0xbff99008, sdlSignal=@0x5c70990) at /vob/ccm/Common /Include/Sdl/SdlProcessBase.hpp:175

#12 0x0a06c904 in SdlProcessBase::inputSignal (this=0xbff99008, rSignal=0x5c70990, traceType=SdlSystemLog::SignalRouterThread, highPriority=0, normalPriority=0, lowPriority=0, veryLowPriority=0, lazyPriority=0, dbUpdatePriority=0) at SdlProcessBase.cpp:397

#13 0x0a0746ce in SdlRouter::callProcess (this=0xe225ac0, _sdlSignal=0x5c70990, _deleteSignal=@0x36b8d07, _traceType=SdlSystemLog::SignalRouterThread, _hp=0, _np=0, _lp=0, _vlp=0, _lzp=0, _dbp=0) at SdlRouter.cpp:371

#14 0x0a0740f3 in SdlRouter::scheduler (sdlRouter=0xe225ac0) at SdlRouter.cpp:281

#15 0x05514bd7 in ACE_OS_Thread_Adapter::invoke (this=0xfe57a30) at OS_Thread_Adapter.cpp:94

#16 0x054d5087 in ace_thread_adapter (args=0x0) at Base_Thread_Adapter.cpp:137

#17 0x00db73cc in start_thread () from /lib/tls/libpthread.so.0

#18 0x0131a96e in clone () from /lib/tls/libc.so.6

この例では、メモリリークとそれに続くリソース不足が原因となり、CCM プロセスでコアが発生しています。「operator new」へのコールを含むバックトレースは通常、メモリリークが原因で作成されます。オペレーティングシステムが許容している最大メモリ量をプロセスが要求しているため、コアが発生しています。コアで特定できることはメモリリークが原因であるということだけであり、具体的なメモリリークを識別することは不可能です。リークの原因を特定するには、他の方法を使う必要があります。多くの場合は SDL トレースを解析し、「Started」または「Created」になっているオブジェクトのうち、「Stopped」に変わっていないオブジェクトを識別することで特定できます。上記のコアは、トレースに基づいて最終的に以下のように診断されています。

CSCte50152 Memory Leak in CCM due to Transient SIP Connections（一時的な SIP 接続による CCM におけるメモリリーク）.

例 3：コアスタックの破損

Memory corruption results in corrupted stack with "??" characters in place of function calls.

#0 0x4e52500a in ?? ()

#1 0xaffb3070 in ?? ()

#2 0xaffb9084 in ?? ()

#3 0x030dc678 in ?? ()

#4 0x00000000 in ?? ()

この例では、メモリ破損インシデントが発生してスタックが上書きされます。関数コールの代わりに「??」文字が表示されています。このバックトレースのみに対する検索では、既知の障害との関連を見つけることはできません。対応するサービスログ（CCM トレース、tomcat ログなど）と完全な Core File を、影響を受けたシステムから取得して、TAC で確認することをお勧めします。

シスコバグツールキットでの検索

コアダンプイベントのバックトレースを取得した後、バグツールキットで検索を行い、既知の障害を見つけます。この例では、以下の障害を取り上げます。

CSCta39769 UnicastBridgeControl Causes CUCM to Crash（CUCM がクラッシュする原因となる UnicastBridgeControl）

#0 0x097a0850 in UnicastBridgeControl::removeConfResources (this=0x6a69f698) at
/vob/ccm/Common/Include/CallManager/TDCLCpShares.hpp:2622
#1 0x097ab5ae in UnicastBridgeControl::star_StationClose (this=0x6a69f698, s=@0x6a981938)
at ProcessUnicastBridgeControl.cpp:2193
#2 0x097bff64 in UnicastBridgeControl::fireSignal (this=0x6a69f698,
sdlSignal=@0x6a981938) at /vob/ccm/Common/Include/Sdl/SdlProcessBase.hpp:174
#3 0x09e4ae58 in SdlProcessBase::inputSignal (this=0x6a69f698, rSignal=0x6a981938,
traceType=SdlSystemLog::SignalRouterThread, highPriority=0, normalPriority=0,
lowPriority=0, veryLowPriority=0, lazyPriority=0, dbUpdatePriority=0) at
SdlProcessBase.cpp:396
#4 0x09e52c1a in SdlRouter::callProcess (this=0xde9bcc8, _sdlSignal=0x6a981938,
_deleteSignal=@0x324bd97, _traceType=SdlSystemLog::SignalRouterThread, _hp=0, _np=0,
_lp=0, _vlp=0, _lzp=0, _dbp=0) at SdlRouter.cpp:372
#5 0x09e5263f in SdlRouter::scheduler (sdlRouter=0xde9bcc8) at SdlRouter.cpp:282
#6 0x00a00ef3 in ACE_OS_Thread_Adapter::invoke (this=0x10b70b90) at
OS_Thread_Adapter.cpp:94
#7 0x009c1abf in ace_thread_adapter (args=0x0) at Base_Thread_Adapter.cpp:137
#8 0x003bf371 in start_thread () from /lib/tls/libpthread.so.0
#9 0x01339ffe in clone () from /lib/tls/libc.so.6

以下の文字列を使って、バグツールキットで初回の検索を実行します。

#2 0x097bff64 in UnicastBridgeControl::fireSignal (this=0x6a69f698,
sdlSignal=@0x6a981938) at /vob/ccm/Common/Include/Sdl/SdlProcessBase.hpp:174

この検索例のスクリーンショットでは、一致するものが見つかるように、メモリの場所を示す固有の ID は検索文から削除されています。検索を実行しても一致するものが見つからない場合は、以下のように特定の CUCM バージョンに合わせた検索条件の調整が必要になることもあります。

上記で変更された検索条件では、ソフトウェアバージョン 7.0 を選択し、CUCM に該当する特定のグループの障害に絞り込んでいます。バージョン 7.0 に関連する障害の検索条件を再送信すると、以下の結果が表示されます。

意図的な強制終了のトラブルシューティング

「IntentionalAbort」というステートメントを含むコアダンプは、サービス障害の原因となっているシステムリソース問題を示します。以下の CCM サービスコアダンプバックトレースの例を使って、意図的な強制終了のトラブルシューティングを行うステップを説明します。

#0 0x001627a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2

#1 0x00d64815 in raise () from /lib/tls/libc.so.6

#2 0x00d66279 in abort () from /lib/tls/libc.so.6

#3 0x084c4e7a in preabort () at ProcessCMProcMon.cpp:101

#4 0x084c4e92 in IntentionalAbort (reason=0xa9fdbdc "CallManager's timers appear

incorrect. This may be due to CPU or blocked function. Attempting to restart

CallManager.") at ProcessCMProcMon.cpp:106

#5 0x084c66c3 in CMProcMon::verifySdlTimerServices () at ProcessCMProcMon.cpp:843

#6 0x084c7035 in CMProcMon::callManagerMonitorThread (cmProcMon=0xec122d0) at

ProcessCMProcMon.cpp:439

#7 0x0107e5fb in ACE_OS_Thread_Adapter::invoke (this=0xf3ef3b8) at

OS_Thread_Adapter.cpp:94

#8 0x01040cbf in ace_thread_adapter (args=0x0) at Base_Thread_Adapter.cpp:137

#9 0x002dc3cc in start_thread () from /lib/tls/libpthread.so.0

#10 0x00e061ae in clone () from /lib/tls/libc.so.6

コアダンプが発生した CUCM ノードから RTMT を介して RIS Data Collector Perfmonlog 情報を取得し、コアダンプアラートのタイムスタンプを確認する必要があります。Windows パフォーマンスログビューアを使用すると、以下に示すようにプロセス CPU 使用率カウンタが最初に確認されます。

上記のスクリーンショットでは、コアダンプインシデントの発生前は CPU 使用率が安定していることが分かります。クラッシュの発生中はリソースが解放されるため、CPU 使用率は急激に下がります。潜在的な CPU 使用率の問題をトラブルシューティングする際には、コアダンプインシデントにつながる CPU 使用率の増加に関する傾向に注意を払う必要があります。

Perfmon データで次に調査するのは、システムによって使用される VM の割合です。現在の例では、コアダンプインシデントが発生するまでの間、このカウンタが特に高くなっています。

次に、すべてのプロセスごとに固有の VMSize を調査して、システムでメモリ使用率が徐々に増えた原因を特定します。この例では、CCM プロセスの VMSize カウンタが比較的高く、上昇していることがわかります。これは CCM がメモリリークが原因でコアを作成したことを意味します。

TAC サービスリクエストを作成するときに役立つ情報

コアダンプインシデントのトラブルシューティングを行うために新しい TAC サービスリクエストをオープンする際には、以下の情報を TAC に提供していただくことでプロセスを迅速に進めることができます。

使用中の CallManager のフルバージョン（7.1.3.32900-4 など）
コアダンプインシデントの日付/時刻
アプリケーションイベントログも提供していただくと役に立ちます
完全なタイムスタンプと Core File 名に関する「utils core list」コマンドの出力を提供してください
コアダンプを生成した、問題が起こっているサービス（CCM、CEF、Tomcat など）
Core File のバックトレースの出力
Core File
問題のプロセスのサービスログ
例：CCM コアダンプの場合は、インシデント発生中の Cisco CallManager トレースを提供してください。
RIS Data Collector Perfmonlog
「意図的な強制終了のトラブルシューティング」を参照してください。