Interstage Application Server/Interstage Web Server チューニングガイド

7.2.11.1 異常終了箇所の情報

　異常終了箇所に関する図1の情報が確認できます。

図1 異常終了箇所に関する情報

1. 異常終了時に発生した例外に関する情報(シグナルコードおよび例外発生アドレス)
   　「Unexpected Signal :」から始まる情報です。
2. 異常終了した関数名(実際には異常終了したアドレスに一番近いシンボル名)　　
   　「Function name=」から始まる情報です。
3. 異常終了した関数を含むライブラリ名
   　「Library=」から始まる情報です。
4. 異常終了時のJavaスレッドのスタックトレース
   　「Current Java thread:」から始まる情報です。
5. 異常終了時のダイナミックライブラリ一覧
   　「Dynamic libraries:」から始まる情報です。
6. 発生時間
   　「Local Time =」から始まる情報です。

■調査手順

　まず、図1の1〜3の情報で異常終了した関数を特定し、実行しているJavaアプリケーションから呼び出す関数かどうかを確認します。ただし、図1の2の異常終了した関数名として出力される名前は、異常終了したアドレスに一番近いシンボル名情報であるため、実際に異常終了した関数とは別の名前が出力されている場合がありますので注意してください。
　そして、実行しているJavaアプリケーションが使用する関数の場合には、当該関数使用に際して何らかの問題がないか確認します。
　実行しているJavaアプリケーションで使用していない関数の場合には、図1の4のスタックトレースを調査します。

スタックトレース情報の最初のメソッドがネイティブメソッドだった場合（メソッド名の後ろに「(Native Method)」が付加されている場合）はJNI処理に関係した問題である可能性が高いため、スタックトレース情報で出力された処理のJNI処理に関わる制御で何らかの問題がないか確認します。

　また異常終了した関数を含むライブラリ名が利用者作成のライブラリである場合は、利用者側作成のライブラリ内の問題である可能性が高いため、当該ライブラリ内の処理および当該ライブラリを呼び出すJNI処理に何らかの問題がないか確認します。

　スタックトレースの調査方法は、“スタックトレース”を参照してください。

■スタックオーバーフローの検出

　図1の1の異常終了時に発生した例外に関する情報に、図2のシグナルコードの表記がある場合、例外が発生したスレッドでスタックオーバーフローが発生した（図2の１、３の表記）、または発生した可能性がある（図2の２、４の表記）ことを示しています。
　この場合、例外が発生したスレッドに対するスタックのサイズを大きくすることで問題が解決する可能性があります。

　スタックオーバーフロー発生の原因が、Java APIで生成されたスレッドに対するスタックのサイズにある場合は、“スタックのチューニング”を参照して、Java APIで生成されるスレッドに対するスタックのサイズをチューニングしてください。

図2 スタックオーバーフローを示すシグナルコード

1)「EXCEPTION_STACK_OVERFLOW」
2)「EXCEPTION_ACCESS_VIOLATION (Stack Overflow ?)」

3)「SIGSEGV (Stack Overflow)」
4)「SIGSEGV (Stack Overflow ?)」

ワトソンログの分析

　スタックオーバーフローが原因で発生した異常終了の場合、OS側からFJVM側の処理へ制御が渡らず、そのままワトソン博士へ制御が渡されることがあります。この場合は、FJVMログが出力されないため、ワトソン博士のログファイルを確認してください。
　ワトソンログに図3の例外番号が出力されている場合には、スタックオーバーフローが原因と考えられます。
　なお、ワトソン博士の説明は、“クラッシュダンプ”を参照してください。

図3 スタックオーバーフローを示す例外番号

c00000fd (スタックオーバーフロー)