编辑:这个可重现的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)
启动应用程序,输入"大量数据",等待几秒钟...... …