Java VM: możliwe do odtworzenia SIGSEGV w obu wersjach 1.6.0_17 i 1.6.0_18, jak zgłaszać?

Question

EDIT: Ten powtarzalny SIGSEGV dzieje się na maszynie Linux z więcej niż jednym procem i więcej niż 2 GB pamięci, więc Java domyślnie działa w trybie -server. Co ciekawe, jeśli wymuszam "-klienta", nie ma już awarii ... (nadal nie jestem zbyt pewny, co zrobić z moim powtarzalnym SIGSEGV, ale jest to interesujące).

Pierwsza uwaga, że ​​to jest nieco podobne, ale nie identyczne do następujących bo w naszym przypadku jest to tylko SIGSEGV tak się dzieje, i możemy niezawodnie wywołać go:

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

Jest to związane, ponieważ zdarza się, kiedy karmimy naszą aplikację "potopem danych": dane pochodzą z plików tekstowych, a następnie są numerowane (tak, w chmurze finansowej numeracja w Javie).

Mogę niezawodnie wywołać JVM do SIGSEGV używając tylko poprawnego kodu Java.

UWAGA: Mogę niezmiennie awarii zarówno JVM 1.6.0_17 adn JVM 1.6.0_18 i kwestia ta nie jest o tym, jak rozwiązać ten problem (na przykład gry z VM Parametry może rozwiązać ten problem, ale jestem nie po tym, chcę wiedzieć, co zrobić z tym zawsze odtwarzalnym SIGSEGV).

Mam obejście, które polega po prostu na używaniu Java 1.5 podczas uruchamiania naszej aplikacji (przy jednoczesnym użyciu Java 1.6 do uruchamiania IntelliJ IDEA itp. Na tym samym komputerze, jednocześnie), ale moje pytanie brzmi, czy to powinno być zgłaszane lub nie, a jeśli tak, jak to zgłosić, wiedząc, że sam dziennik zawiera zastrzeżone informacje (pełny dziennik hs_err _..._).

Błąd sprzętowy można wykluczyć dla:

• to dzieje się na stacji roboczej, które regularnie osiąga miesięcy uptime (I tylko restart, gdy poprawki zabezpieczeń krytyczna wpływa na moje okrojone i utwardzony Debian Linux są wydawane , co tak naprawdę nie zdarza się często) i na które aplikacje nigdy się nie zawieszają (sprawiając, że jest to bardzo mało prawdopodobne, że jest to problem sprzętowy na tej maszynie [więcej poniżej])

• ta sama aplikacja działa doskonale na tej samej maszynie pod JVM 1.5 pod tym samym obciążeniem (tak testuję aplikację: po prostu uruchamiam ją pod 1.5 VM)

• sama aplikacja działa perfekcyjnie na więcej niż jednym setek maszyn klientów w ramach tego samego (gigantyczny) obciążenia (nigdy nie rozbił się raz na Windows + JVM 1.5 lub 1.6 i nigdy nie rozbił się raz na OS X + JVM 1.5 lub 1.6 [awaria oznaczałaby natychmiastową rozmowę telefoniczną od klienta])

• inna aplikacja na tej samej maszynie i tym samym 1.6.0_17 lub 1.6.0_18 JVM nigdy się nie zawiesza (na przykład mam dwa wystąpienia IntelliJ IDEA działające jako dwaj różni użytkownicy na tym samym komputerze i nie ulegają awariom)

• Maszyna jest testowana z memtest "regularnie" (przed instalacją nowego OS, który w ubiegłym stało po zainstalowaniu Debiana Lenny, nie tak dawno temu)

Oto powtarzalne-on-demand 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) 

Uruchom aplikację, karmić go „potop danych ", poczekaj kilka sekund ...

Następnie niezmiennie do 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 

(zauważyć, że linia '[libjvm.so + 0x4bc080]' jest spójna w każdym SIGSEGV 1.6.0_17)

lub 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 

(zauważyć, że linia "[libjvm.so + 0x4d88f0]" jest zgodne z 1.6.0_18 w każdym SIGSEGV)

prob lem jest to, że plik dziennika zawiera zastrzeżone informacje , których nie można udostępnić.

Powielanie "małego testu", który odtwarza problem, jest również nierealne: jest podobne do problemu, o którym mowa powyżej, dzieje się tak tylko wtedy, gdy do aplikacji jest podawany "zalew danych".

Zauważ, że dokładnie ta sama aplikacja, na dokładnie tym samym sprzęcie, z dokładnie tą samą maszyną JVM, ale inną wersją Linuksa (miałem wcześniej Etail Debiana) nie wyzwoliła tego SIGSEGV raz.

Ale to nie znaczy, że JVM nie ponosi winy: nadal może to być kwestia JVM.

Czy powinienem to zgłosić i jak? (pamiętając, że napisanie "powtarzalnego, malutkiego przypadku testowego" ma charakter urojeniowy, a dziennik zawiera zastrzeżone informacje, które nie powinny wyciekać). Czy powinienem edytować dziennik i wysłać go?

Jaka jest procedura zgłaszania tak odtwarzalnego SIGSEGV, gdy dziennik zawiera zastrzeżone informacje, a przypadek testowy odtwarzający problem nie jest realnie wykonalny?

Czy któryś z was odniósł sukces otwierając taki błąd, a następnie zobaczył go rozwiązany w kolejnej wersji Java?

Czy uważasz, że to dobre "dla społeczności Java" zgłosić taki problem, czy po prostu nie powinienem się przejmować, ponieważ to nie jest ważne?

Answer 1

mam podobny problem modernizacji do JDK 1.6_18 i wydaje się rozwiązać przy użyciu następujących opcji:

-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 

nadal nie double check (jest to środowisko produkcyjne), ale myślę, że był błąd z dwóch powodów:

1) Nieprawidłowe ustawienie sterty i/lub stałej przestrzeni (myślę, że JDK 1.6 potrzebuje więcej miejsca w sterty i trwałe niż w poprzednich wersjach JVM) spowodował OutOfMemoryError, ale

2) w niewłaściwym pierwotne ustawienie ktoś napisał

-XX:+HeapDumpOnOutOfMemoryError="/tmp" 

i nie

-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath="/tmp" 

więc prawdopodobnie JVM nie udało się napisać pliku heapdump i otrzymaliśmy tylko SIGSEGV (poprzednie wersje zapisują zrzut sterty w katalogu roboczym).

Sprawdź również opcje -server -XX:+UseParallelGC -XX:-UseGCOverheadLimit. Wydaje mi się, że granie z parametrami VM nie jest obejściem, ale właściwym podejściem także dlatego, że garbage collector (i nie tylko) zmienił się pomiędzy 1.5 a 1.6.

Answer 2

Problemem jest to, że plik dziennika zawiera informacje, które nie mogą być udostępniane. Reprodukcji „malutki przypadek testowy”, który odtworzenia problemu nie jest realne albo

Jeśli nie można zapewnić firmie Sun powtarzalny przypadku testowego, nie będą nawet spojrzeć na niego. Szansa jest dobra, że ​​zignorują to, nawet jeśli zapewnimy użyteczny test. Proces zgłaszania błędów w Sun pozostawia wiele do życzenia.

Czy powinienem to zgłosić i jak?

Jeśli nie możesz wymyślić powtarzalnego testu, nie przejmuj się. Jeśli nie mogą odtworzyć problemu, czego się od niego oczekuje?

Zauważ, że dokładnie taki sam wniosek, na dokładnie tym samym sprzęcie, z dokładnie w tym samym JVM, ale inny wersja Linux (Debian Etch miałem poprzednio) nie wywoła to SIGSEGV raz.

Czy działa na innym pudełku z tym samym sprzętem i tą samą wersją systemu Linux?

Answer 3

Pierwsze pytanie należy zadać sobie pytanie:

• używam oficjalnie wspierany dystrybucję Linuksa?

Jeśli nie, przełącz na taki, który jest.

Jeśli tak, to zgłoś to firmie Sun!

Answer 4

Jeśli to pomoże, błąd łącza złożenie w raporcie krach ten Zastrzeżenie:

Ponadto, Sun Microsystems szanuje Państwa potrzebę prywatności. Dane osobowe zebrane z tego programu nie będą sprzedawane, przekazywane ani udostępniane organizacjom zewnętrznym wobec firmy Sun. Będziemy wykorzystywać te dane do komunikacji z Tobą, aby wyjaśnić kwestie dotyczące złożonego raportu i/lub statusu tego raportu. Problemy, które zgłaszasz, mogą zostać udostępnione innym członkom JDC lub klientom firmy Sun, jednak Twoje dane osobowe będą traktowane jako poufne. Jeśli nie jesteś zadowolony z powyższych warunków, nie naciskaj przycisku Wyślij. Jeśli masz jakiekolwiek pytania, zapoznaj się z naszym Privacy Policy.

Osobiście bym go zgłosić, czy to możliwe, aby oddać segment kodu w pytaniu z bali, jeśli dane nie są zbyt wrażliwe (być może dane mogą być maskowane lub ukrywane w logach?).

Nie możesz naprawdę ocenić, czy błąd jest "ważny", czy nie dla innych, chyba że wiesz, co tak naprawdę powoduje. Zgłaszanie tego może być pierwszym krokiem inżynierów firmy Sun, którzy odkryli przyczynę czegoś poważnego.