8

JVM がクラッシュすると、エラー ログ hs_err_pid.log が書き込まれます。JVM がクラッシュした原因を知りたいですか? これらのログを理解する方法は、このログがどのように配置されているかについてどこかに文書化されています。ネットで調べてみましたがだめでした(-_-;)

関連する URL を指摘していただければ幸いです。ありがとう。

4

3 に答える 3

5

ネイティブ コード (JNI) を呼び出していない限り、コード内で JVM がクラッシュすることはありません。そのため、そのログ ファイルのスタック トレース情報は、ほとんどの開発者にとってあまり有用ではない可能性があります。それがおそらく、文書化されていない可能性がある理由です(少なくとも外部的に)。そのため、おそらく最善の方法は、エラー メッセージに示されているようにバグ レポートを提出することです。

でも、どうしても理解したいなら、浩介さんのブログがいいですよ。いつものように。:)

于 2009-05-12T06:09:01.643 に答える
0

まず、「ntdll.dll+0x2000」のような一番上の行を探します。

ホットスポットがネイティブ コードで発生しいる場合(つまり、DLL が自分のものである場合)、コンパイラに DLL オフセットから行番号へのマッピングのリストを生成させる方法を見つけてください。明らかに、新しくコンパイルされた DLL を使用して再実行し、問題が再び発生するのを待つ必要があることを意味する場合があります。

それ以外の場合は、その特定の行を検索すると、Google で何かが表示されるかどうかを確認してください。同じエラーがさまざまな問題を意味する可能性があることを念頭に置いてください。また、DLL 名が認識可能なもの (たとえば、プリンター ドライバー名、グラフィックス ドライバー、または特定の呼び出しまで追跡できるその他のコンポーネント) であるかどうかを確認します。そのコンポーネントが何であれ、修正されたバージョンにアップグレードするか、問題の呼び出しを回避できる場合があります。コンポーネントが何であるかわからない場合は、アップグレードする必要があるのは単に「JVM」である可能性があります-少なくとも、使用しているバージョンの最新の更新/マイナーバージョン番号にアップグレードすることは、おそらく良い考えです.

過去に、問題の特定のメソッドをコンパイルしようとしないように指示することで一時的に解決できる JIT コンパイラのバグも見てきました。どのメソッドだったのか (おそらく Java スタックのダンプにすぎない) が、詳細を思い出すための例が手元にありません。

于 2009-05-12T06:26:48.200 に答える
0

これはかなり便利です: http://weblogs.java.net/blog/kohsuke/archive/2009/02/crash_course_on.html

最初の回答者はすでにこの URL について言及していますが、気にしないでください。

于 2009-05-12T08:46:59.093 に答える