Java VM:1.6.0_17和1.6.0_18都可以重现SIGSEGV,如何报告？

Question

编辑:这个可重现的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社区"有好处,或者我不应该费心,因为它不重要？

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(之前的版本在工作目录中写了堆dump).

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

Answer 2

问题是日志文件包含无法共享的专有信息.再现一个重现问题的"微小测试用例"也是不现实的

如果您无法为Sun提供可重现的测试用例,他们甚至不会查看它.即使您提供了可用的测试用例,他们也会忽略它.Sun的错误提交过程有很多不足之处.

我应该报告这个以及如何报告？

如果您无法想出可重现的测试用例,请不要打扰.如果他们无法重现这个问题,你期望他们做什么？

请注意,完全相同的应用程序,在完全相同的硬件上,具有完全相同的JVM但是另一个版本的Linux(我以前使用过Debian Etch)并没有触发SIGSEGV一次.

它是否在具有相同硬件和相同版本Linux的不同盒子上工作？