jvmでSIGSEGVをデバッグする方法GCTaskThread

Question

私のアプリケーションでは運用中にキャッシュが発生しています。 クラッシュダンプは、GCTaskThreadでSIGSEGVが発生したことを示します。

これはJNIを使​​用しているため、わかりませんが、メモリ破損の原因がある可能性があります。

どうすればこの問題をデバッグできますか？私は-XX：OnErrorを実行しますが、これをデバッグするのに役立つものはわかりません。

OS：SUSE Linux Enterprise Serverの10（x86_64版）

vm_infoまた

、あなたのいくつかは、JNIコードがEDIT

SIGSEGV

でGCをクラッシュすることができます方法についての具体的な例を与えることができます：linux-amd64 JRE（1.6.0_10-b33）用のJava HotSpot（TM）64ビットサーバVM（11.0-b15）、2008年9月26日に構築01:10:29 gcc 3.2.2で "java_re" Linux）

EDIT： 私たちがハイパースレッディングを無効にした後、問題の停止が発生しました。 JNIコードで

Answer 1

エラーは、いくつかの方法で発生する可能性があります。

The program crashes during execution of a native method (most common). 
The program crashes some time after returning from the native method, often during GC (not so common). 
Bad JNI code causes deadlocks shortly after returning from a native method (occasional). 

あなたは（つまり、JNIの問題を）ユーザーが記述したネイティブコードとJVMの間の相互作用に問題があると思われる場合は、 JNIの遷移を確認するのに役立つ診断を実行できます。これらの診断を呼び出す。 JVMを起動するときに-Xcheck：jniオプションを指定します。

-Xcheck：jniオプションは、JNI関数に関するラッパー関数のセットをアクティブにします。ラッパー関数は、入力パラメーターのチェックを実行します。これらのチェックが含まれます：Plsは障害のあるスレッドので、以下のリンク http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp?topic=/com.ibm.java.doc.diagnostics.50/html/jni_debug.html http://www.oracle.com/technetwork/java/javase/clopts-139448.html#gbmtq

Answer 2

を読ん

Whether the call and the call that initialized JNI are on the same thread. 
Whether the object parameters are valid objects. 
Whether local or global references refer to valid objects. 
Whether the type of a field matches the Get<Type>Field or Set<Type>Field call. 
Whether static and nonstatic field IDs are valid. 
Whether strings are valid and non-null. 
Whether array elements are non-null. 
The types on array elements. 

GCTaskThreadのようですが、verbose:gcを有効にして、出力を解析しようとしましたか（できれば武士のようなグラフィカルなツールを使用するなど）？ hs_errファイルを調べた後、特定のlibを分離することはできますか？

さらに、問題の原因と簡単に再現できるかどうかについてさらに詳しくお知らせください。

Answer 3

valgrindを使用します。これはメモリ破損のように聞こえる。出力は冗長ですが、可能であればJNIライブラリにレポートを分離しようとします。