2017-09-19 12 views
0

この問題に関しては、同様のstackoverflow質問SIGSEGV Java Fatal Error in libjvm.soがあります。JVMが頻繁にSIGSEGVでクラッシュするJava libjvm.soの致命的なエラー

これは、apache tomcatで動作する大規模なアプリケーション(〜30GB)です。常にJVM C++コードの中のように見える同じエラーメッセージ、で失敗するようだ:私は完全なJavaのコア・ダンプを含めました

V [libjvm.so+0x643ee4] InstanceKlass::find_method_index(Array<Method*>*, Symbol*, Symbol*, bool, bool)+0x14 

https://drive.google.com/open?id=0B0rh8NWt2kRySTlleW9Dckw3a3c

どのようにしても、この問題を解決するために開始するために、誰もが正しい方向に私を指すことができます。私はJDKを最新のリリースレベル(JDK 1.8リリース144)にアップグレードしようとしましたが、無駄です。

+0

私はダンプを見ています。これはあなたの問題から独立していますが、Webアプリケーションのクラスパスはかなり混雑しています。 2つのBouncy Castleプロバイダのjarと、別のバージョンと、さらに他のバージョンのbcライブラリが追加されています。これらのjarファイルは署名されているので、実際に動作するのは驚いています。異なるJarファイルと異なるバージョンからBCクラスをロードしようとすると、ClassLoaderがエラーをスローする必要があるからです。ああ、bcライブラリはJava 1.4用にコンパイルされており、Java 8を使用しています。 – Lothar

答えて

0

ダンプを見ると、ホットスポットが最適化を実行しようとしていたときに問題が発生したようです。だから私は、あなたが起動時に設定されたJavaのプロパティをチェックし、その上の影響力を持っているビットがあります。

-Xnoclassgc 

これはもう私の知る限りのJava 8と全く使用していません。同じもの

-XX:MaxPermSize=256m 

使用するガベージコレクタを変更しています。G1

これはクラッシュと関連する可能性がありますので、私の提案はデフォルトの設定を使用するように設定を戻すことです。クラッシュが消えた場合、G1はアプリケーションに適していません。

私のコメントで述べたように、Webアプリケーションのlibディレクトリをクリーンアップする必要があります。異なるバージョンのライブラリが多数あります(例: bcprov-jdk14-140.jarbcprov-jdk14-1.38.jarbcmail-jdk14-139.jarbcmail-jdk14-1.38.jar ...これは見た目のようにアプリケーションをクラッシュさせませんが、バージョン1.39のbcmailからメールクラスをロードしようとすると、クラスローダー内で署名検証の失敗が発生するはずですバージョン1.40のBCプロバイダと協力しています。

+0

同じVM引数が他の場所で使用されているにもかかわらず、合理的な調整のように思えます。 – user3892260

+0

重複した項目のロードを避けるために、maven pom.xmlをクリーンアップしました。それが助けになるかどうかを見てみましょう – user3892260

+0

異なる順列を試みて何週間も経った後、私はG1GCの使用に問題を切り分けました。その設定を省略し、標準のG1ガベージコレクタを使用させると、問題は停止します。あなたの提案に感謝のLothar。 – user3892260

関連する問題