Java VM : reproducible SIGSEGV on both 1. 6.0_17 和 1.6.0_18，如何报？

Question

编辑 :这种可重现的 SIGSEGV 发生在具有多个 proc 和超过 2GB 内存的 Linux 机器上，因此 Java 默认为 -server 模式。有趣的是，如果我强制使用“-client”就不会再崩溃了......(我仍然不太确定如何处理我的可重现 SIGSEGV 但它仍然很有趣)。

首先请注意，这与以下内容有点相关但不完全相同，因为在我们的例子中，它只是一个 SIGSEGV 发生，我们可以可靠地触发它:

JVM OutOfMemory error "death spiral" (not memory leak)

这是相关的，因为当我们向我们的应用程序提供“大量数据”时会发生这种情况:数据来自文本文件，然后经过数字处理(是的，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_..._log)。

可以排除硬件错误:

这发生在一个工作站上，它的正常运行时间经常达到数月(我只在发布影响我的精简和强化的 Debian Linux 的关键安全补丁时才重新启动它，这确实不经常发生)并且应用程序永远不会崩溃(使其非常不太可能是那台机器上的硬件问题 [更多信息如下])

相同的应用程序在相同负载下的 JVM 1.5 下在同一台机器上完美运行(这就是我测试应用程序的方式:我只是在 1.5 虚拟机下启动它)

相同的应用程序在相同(巨大)负载下在一百多个客户端机器上运行得非常好(在 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

(请注意，行 '[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 社区”有好处还是我不应该因为它不重要而烦恼？

Answer 1

我在升级到 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(以前的版本在工作目录中写入了 heap dump)。

查询 -server -XX:+UseParallelGC -XX:-UseGCOverheadLimit选项也是。我认为使用 VM 参数不是一种解决方法，而是正确的方法，因为垃圾收集器(不仅仅是)在 1.5 和 1.6 之间发生了变化。