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的不同盒子上工作？

Answer 3

如果有幫助，崩潰報告中的錯誤提交鏈接有此免責聲明：

此外，Sun Microsystems尊重您對隱私的渴望。 從本程序收集的個人數據不會出售，給予或與Sun外部的組織共享。 我們將使用此數據與您進行通信，以澄清有關您提交的報告和/或該報告狀態的問題。 您報告的問題可能會提供給其他JDC會員或Sun客戶，但您的個人數據將被保密。 如果您對上述條件不滿意，請不要按“提交”按鈕。 如果您有任何疑問，請參閱我們的隱私政策 。

就個人而言，如果數據不是太敏感（也許數據可以在日志中屏蔽或混淆？），我會報告是否可以用日志移交有問題的代碼段。

你不可能真正判斷這個bug是否對其他人“重要”，除非你知道究竟是什么導致它。 報告它可能是Sun工程師發現問題嚴重原因的第一步。

Answer 4

你應該問自己的第一個問題是：

• 我使用官方支持的Linux發行版嗎？

如果沒有，請切換到。

如果是，請報告給Sun！