EDIT:这种可重现的 SIGSEGV 发生在一台具有多个 proc 和超过 2GB 内存的 Linux 机器上,因此 Java 默认为 -server 模式。有趣的是,如果我强制“-client”,就不会再崩溃了......(我仍然不太确定如何处理我的可重现的 SIGSEGV,但它仍然很有趣)。
首先请注意,这与以下内容有点相关但不完全相同,因为在我们的例子中,它只发生一个 SIGSEGV,并且我们可以可靠地触发它:
JVM OutOfMemory 错误“死亡螺旋”(不是内存泄漏) https://stackoverflow.com/questions/2297920/jvm-outofmemory-error-death-spiral-not-memory-leak
这是相关的,因为当我们向应用程序提供“大量数据”时,就会发生这种情况:数据来自文本文件,然后进行数字运算(是的,Java 中的财务数字运算)。
我可以仅使用有效的 Java 代码可靠地将 JVM 触发到 SIGSEGV。
NOTE:我总是会导致 JVM 1.6.0_17 和 JVM 1.6.0_18 崩溃,这个问题不是关于如何解决这个问题(例如使用 VM 参数)may解决问题,但我不在那之后,我想知道如何处理这个总是可重现的 SIGSEGV)。
我有一个解决方法,它只是在启动我们的应用程序时使用 Java 1.5(同时仍然使用 Java 1.6 在同一台计算机上同时运行 IntelliJ IDEA 等),但我的问题是是否应该报告这一点,并且,如果应该,如何报告它知道日志本身包含专有信息(完整的 hs_err_..._log)。
可以排除硬件错误:
这种情况发生在一台经常达到数月正常运行时间的工作站上(我只会在影响我的精简和强化的 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
(请注意,行“[libjvm.so+0x4bc080]”对于 1.6.0_17 在每个 SIGSEGV 都是一致的)
或对于 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]”行对于 1.6.0_18 在每个 SIGSEGV 都是一致的)
问题是日志文件包含专有信息
无法共享的。
重现重现问题的“小测试用例”也不现实:它与上面链接的问题类似,只有当“大量数据”被输入到应用程序时才会发生这种情况。
请注意,完全相同的应用程序,在完全相同的硬件上,具有完全相同的 JVM,但 Linux 的另一个版本(我之前有 Debian Etch)不会触发 SIGSEGV 一次。
但这并不意味着 JVM 没有问题:它仍然可能是 JVM 问题。
我应该报告此事以及如何报告? (请记住,编写“可重现的微小测试用例”是一种妄想,并且日志包含不应泄露的专有信息)。我应该编辑日志并发送吗?
当您的日志包含专有信息并且重现问题的测试用例实际上不可行时,报告此类可重现的 SIGSEGV 的程序是什么?
你们中是否有人成功发现了这样的错误,并在后续的 Java 版本中看到它得到解决?
您认为报告这样的问题对“Java 社区”来说是好事还是我不应该打扰,因为它不重要?