11

編集：この再現可能なSIGSEGVは、複数のprocと2GBを超えるmemを備えたLinuxマシンで発生するため、Javaはデフォルトで-serverモードになっています。興味深いことに、「-client」を強制すると、クラッシュは発生しなくなります...（再現可能なSIGSEGVをどうすればよいかはまだわかりませんが、それでも興味深いです）。

最初に、これは少し関連していますが、以下と同じではないことに注意してください。この場合、発生するのはSIGSEGVのみであり、確実にトリガーできるためです。

JVM OutOfMemoryエラー「デススパイラル」（メモリリークではない）

これは、アプリに「大量のデータ」をフィードしたときに発生するためです。データはテキストファイルから取得され、数値が処理されます（はい、Javaでは財務番号が処理されます）。

有効なJavaコードのみを使用して、JVMをSIGSEGVに確実にトリガーできます。

注：JVM1.6.0_17とJVM1.6.0_18の両方を常にクラッシュさせる可能性があります。この質問は、この問題を回避する方法に関するものではありません（たとえば、VMパラメーターで遊ぶと問題が解決する場合がありますが、その後は解決しません。知りたいです。この常に再現可能なSIGSEGVをどうするか）。

アプリの起動時にJava1.5を使用するだけの回避策があります（同じマシンで同時にJava1.6を使用してIntelliJIDEAなどを実行している間）が、私の質問は、これを報告する必要があるかどうかです。 、必要に応じて、ログ自体に専有情報（完全なhs_err _..._ log）が含まれていることを認識して報告する方法。

ハードウェアエラーは、次の場合に除外できます。

  • これは、定期的に数か月の稼働時間に達するワークステーションで発生し（トリムダウンおよび強化されたDebian Linuxに影響を与える重要なセキュリティパッチが発行された場合にのみ再起動しますが、実際には頻繁には発生しません）、アプリケーションがクラッシュすることはありません（非常に頻繁に発生します）。そのマシンのハードウェアの問題である可能性は低いです[以下を参照]）

  • 同じアプリケーションは、同じ負荷の下でJVM 1.5の下の同じマシン上で完全に動作します（これが私がアプリをテストしている方法です：1.5 VMの下で単に起動します）

  • 同じアプリケーションは、同じ（巨大な）負荷の下で100を超えるクライアントマシンで完全に正常に動作します（Windows + JVM 1.5または1.6で一度もクラッシュしたことはなく、OS X +JVM1.5または1.6で一度もクラッシュしたことはありません[クラッシュはインスタント電話を意味しますクライアントからの呼び出し]）

  • 同じマシン上の他のアプリケーションと同じ1.6.0_17または1.6.0_18JVMがクラッシュすることはありません（たとえば、同じマシン上で2人の異なるユーザーとして実行されているIntelliJ IDEAの2つのインスタンスがあり、クラッシュしません）

  • マシンはmemtestで「定期的に」テストされます（新しいOSをインストールする前に、Debian Lennyをインストールしたときに最後に発生しましたが、それほど前ではありません）

再現可能なオンデマンドSIGSEGVは次のとおりです。

... $uname -a
Linux saturn 2.6.26-2-686 #1 SMP Wed Nov 4 20:45:37 UTC 2009 i686 GNU/Linux
... $ export /home/wizard/jdk1.6.0_17/bin:$PATH
... $ java -version
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

アプリを起動し、「大量のデータ」をフィードして、数秒待ちます...

次に、常に、1.6.0_17の場合：

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xb76d0080, pid=30793, tid=2514328464
#
# JRE version: 6.0_17-b04
# Java VM: Java HotSpot(TM) Server VM (14.3-b01 mixed mode linux-x86 )
# Problematic frame:
# V  [libjvm.so+0x4bc080]
#
# An error report file with more information is saved as:
# /home/wizard/hs_err_pid30793.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp

（行'[libjvm.so + 0x4bc080]'は、すべてのSIGSEGVで1.6.0_17に対して一貫していることに注意してください）

または1.6.0_18の場合：

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xb77468f0, pid=722, tid=2514516880
#
# JRE version: 6.0_18-b07
# Java VM: Java HotSpot(TM) Server VM (16.0-b13 mixed mode linux-x86 )
# Problematic frame:
# V  [libjvm.so+0x4d88f0]
#
# An error report file with more information is saved as:
# /home/wizard/hs_err_pid722.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Aborted

（行 "[libjvm.so + 0x4d88f0]"は、すべてのSIGSEGVで1.6.0_18に対して一貫していることに注意してください）

問題は、ログファイルに共有できない専有情報が含まれていることです。

問題を再現する「小さなテストケース」を再現することも現実的ではありません。これは上記のリンクの問題と同様であり、これは「大量のデータ」がアプリにフィードされた場合にのみ発生します。

まったく同じアプリケーション、まったく同じハードウェア、まったく同じJVM、ただし別のバージョンのLinux（以前はDebian Etchを使用していた）は、そのSIGSEGVを一度もトリガーしなかったことに注意してください。

ただし、これはJVMに障害がないことを意味するものではありません。それでもJVMの問題である可能性があります。

これとその方法を報告する必要がありますか？（「再現可能な小さなテストケース」を作成することは妄想的であり、ログには漏洩してはならない専有情報が含まれていることに注意してください）。ログを編集して送信するだけでよいですか？

ログに専有情報が含まれている場合、および問題を再現するテストケースが現実的に実行できない場合に、このような再現可能なSIGSEGVを報告する手順は何ですか？

このようなバグを開いて、その後のJavaリリースで解決されるのを確認した人はいますか？

このような問題を報告することは「Javaコミュニティにとって」良いことだと思いますか、それとも重要ではないので気にしないでください。

4

4 に答える 4

6

JDK 1.6_18にアップグレードしても同様の問題が発生し、次のオプションを使用して解決されたようです。

-server
-Xms256m
-Xmx748m
-XX:MaxPermSize=128m

-verbose:gc
-XX:+PrintGCTimeStamps
-Xloggc:/tmp/gc.log
-XX:+PrintHeapAtGC
-XX:+PrintGCDetails
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath="/tmp"

-XX:+UseParallelGC
-XX:-UseGCOverheadLimit

# Following options just to remote monitoring with jconsole, useful to see JVM behaviour at runtime
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=12345
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=MyHost

私はまだ再確認しませんでした（これは実稼働環境です）が、エラーは2つの理由によるものだと思います。

1）ヒープおよび/または永続スペースに関する誤った設定（JDK 1.6は以前のJVMバージョンよりもヒープおよび永続スペースでより多くのスペースを必要とすると思います）がOutOfMemoryErrorを引き起こしましたが、

2）間違った元の設定で誰かが書いた

-XX:+HeapDumpOnOutOfMemoryError="/tmp"

ではなく

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath="/tmp"

したがって、おそらくJVMはヒープダンプを書き込むことができず、SIGSEGVのみを取得しました（以前のバージョンでは、作業ディレクトリにヒープダンプが書き込まれていました）。

-server -XX:+UseParallelGC -XX:-UseGCOverheadLimitオプションも確認してください。VMパラメーターで遊ぶことは回避策ではないと思いますが、ガベージコレクター（だけでなく）が1.5と1.6の間で変更されたため、正しいアプローチでもあります。

于 2010-02-25T08:41:55.230 に答える
5

問題は、ログファイルに共有できない専有情報が含まれていることです。問題を再現する「小さなテストケース」を再現することも現実的ではありません

再現可能なテストケースをSunに提供できない場合、Sunはそれを見ることさえしません。使用可能なテストケースを提供しても、無視される可能性は十分にあります。Sunでのバグ提出プロセスには、多くの要望が残されています。

これとその方法を報告する必要がありますか？

再現可能なテストケースを思い付くことができない場合でも、気にしないでください。彼らが問題を再現できない場合、あなたは彼らに何を期待しますか？

まったく同じアプリケーション、まったく同じハードウェア、まったく同じJVM、ただし別のバージョンのLinux（以前はDebian Etchを使用していた）は、そのSIGSEGVを一度もトリガーしなかったことに注意してください。

同じハードウェアと同じバージョンのLinuxを搭載した別のボックスで動作しますか？

于 2010-02-19T20:20:29.307 に答える
1

それが役立つ場合は、クラッシュレポートのバグ送信リンクに次の免責事項があります。

さらに、SunMicrosystemsはプライバシーに対するお客様の要望を尊重します。このプログラムから収集された個人データは、Sunの外部の組織に販売、提供、または共有されることはありません。このデータは、提出されたレポートやそのレポートのステータスに関する問題を明確にするために、お客様とのコミュニケーションに使用されます。あなたが報告した問題は、他のJDCメンバーまたはSunの顧客に提供される可能性がありますが、あなたの個人データは秘密にされます。上記の条件に満足できない場合は、送信ボタンを押さないでください。ご不明な点がございましたら、プライバシーポリシーをご覧ください。

個人的には、データの機密性が高すぎない場合（おそらく、データがログでマスクまたは難読化される可能性がありますか？）、ログを使用して問題のコードセグメントを渡すことが可能であるかどうかを報告します。

実際に何が原因であるかを理解できない限り、バグが他の人にとって「重要」であるかどうかを実際に判断することは不可能です。それを報告することは、Sunのエンジニアが深刻な問題の原因を見つけるための最初のステップかもしれません。

于 2010-02-20T03:21:48.053 に答える
0

あなたが自分自身に尋ねるべき最初の質問は：

  • 公式にサポートされているLinuxディストリビューションを使用していますか？

そうでない場合は、あるものに切り替えます。

もしそうなら、それをSunに報告してください！

于 2010-02-19T23:39:34.017 に答える