Java VM：1.6.0_17和1.6.0_18都可以重现SIGSEGV，如何报告？
编辑 ：这个可重现的SIGSEGV发生在具有多个proc和超过2GB内存的Linux机器上，因此Java默认为-server模式。 有趣的是，如果我强迫“-client”再也没有崩溃……（我仍然不太确定如何处理我可重复的SIGSEGV，但它仍然很有趣）。
首先请注意，这与以下内容有点相关但不同，因为在我们的情况下，它只发生了一个SIGSEGV，我们可以可靠地触发它：
JVM OutOfMemory错误“死亡螺旋”（不是内存泄漏）
它是相关的，因为它发生在我们为应用程序提供“大量数据”时：数据来自文本文件然后数字嘎吱嘎吱（是的，Java中的财务数字运算）。
我只能使用有效的Java代码可靠地触发JVM到SIGSEGV。
注意 ：我总是会崩溃JVM 1.6.0_17和JVM 1.6.0_18这个问题并不是关于如何解决这个问题（例如，使用VM参数可以解决问题，但我不是在那之后，我想知道如何处理这种始终可重复的SIGSEGV）。
我有一个解决方法，只是在启动我们的应用程序时使用Java 1.5（同时仍然使用Java 1.6在同一台机器上运行IntelliJ IDEA等），但我的问题是，是否应该报告这个和如果它应该，如何报告它知道日志本身包含专有信息（完整的hs_err _…_日志）。
可以排除硬件错误：
-
这种情况发生在经常达到几个月正常运行时间的工作站上（我只在重要的安全补丁影响我已经发布的严格和强化的Debian Linux时重新启动它，这实际上并不经常发生）以及哪些应用程序永远不会崩溃（使它非常不太可能是那台机器上的硬件问题[更多下面]）
-
相同的应用程序在相同负载下的JVM 1.5下在同一台机器上完美运行（这就是我测试应用程序的方式：我只需在1.5 VM下启动它）
-
相同的应用程序在相同（巨大）负载下的超过一百台客户端机器上运行完美（在Windows + JVM 1.5或1.6上从未崩溃一次，并且从未在OS X + JVM 1.5或1.6上崩溃一次[崩溃意味着即时电话来自客户的电话]）
-
同一台机器上的其他应用程序和相同的1.6.0_17或1.6.0_18 JVM永远不会崩溃（例如，我有两个IntelliJ IDEA实例作为同一台机器上的两个不同用户运行而且它们不会崩溃）
-
机器用memtest“定期”测试（在安装新的操作系统之前，最后一次发生在安装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
（请注意，每个SIGSEGV的'[libjvm.so + 0x4bc080]’行与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的过程是什么？
你有没有成功打开这样的bug然后看到它在随后的Java版本中解决了？
您是否认为报告此类问题对“Java社区”有好处，或者我不应该费心，因为它不重要？
我有类似的问题升级到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
我仍然没有仔细检查（这是一个生产环境），但我认为错误是由于两个原因：
1）关于堆和/或永久空间的错误设置（我认为JDK 1.6在堆中需要更多空间并且永久性比以前的JVM版本更长）导致OutOfMemoryError，但是
2）在有人写的错误的原始设置中
-XX:+HeapDumpOnOutOfMemoryError="/tmp"
并不是
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath="/tmp"
所以可能JVM无法编写heapdump而我们只得到了SIGSEGV（以前的版本在工作目录中写了堆dump）。
检查-server -XX:+UseParallelGC -XX:-UseGCOverheadLimit选项。 我认为使用VM参数不是一种解决方法，但正确的方法也是因为垃圾收集器（而不仅仅是）在1.5和1.6之间变化。
问题是日志文件包含无法共享的专有信息。 再现一个重现问题的“微小测试用例”也是不现实的
如果您无法为Sun提供可重现的测试用例，他们甚至不会查看它。 即使您提供了可用的测试用例，他们也会忽略它。 Sun的错误提交过程有很多不足之处。
我应该报告这个以及如何报告？
如果您无法想出可重现的测试用例，请不要打扰。 如果他们无法重现这个问题，你期望他们做什么？
请注意，完全相同的应用程序，在完全相同的硬件上，具有完全相同的JVM但是另一个版本的Linux（我以前使用过Debian Etch）并没有触发SIGSEGV一次。
它是否在具有相同硬件和相同版本Linux的不同盒子上工作？
如果有帮助，崩溃报告中的错误提交链接有此免责声明：
此外，Sun Microsystems尊重您对隐私的渴望。 从本程序收集的个人数据不会出售，给予或与Sun外部的组织共享。 我们将使用此数据与您进行通信，以澄清有关您提交的报告和/或该报告状态的问题。 您报告的问题可能会提供给其他JDC会员或Sun客户，但您的个人数据将被保密。 如果您对上述条件不满意，请不要按“提交”按钮。 如果您有任何疑问，请参阅我们的隐私政策 。
就个人而言，如果数据不是太敏感（也许数据可以在日志中屏蔽或混淆？），我会报告是否可以用日志移交有问题的代码段。
你不可能真正判断这个bug是否对其他人“重要”，除非你知道究竟是什么导致它。 报告它可能是Sun工程师找出问题严重原因的第一步。
你应该问自己的第一个问题是：
- 我使用官方支持的Linux发行版吗？
如果没有，请切换到。
如果是，请将其报告给Sun！