Java VM: SIGSEGV riproducibile sia su 1.6.0 17 che su 1.6.0 18, come segnalare?

EDIT : Questo SIGSEGV riproducibile avviene su una macchina Linux con più di un proc e più di 2 GB di mem, quindi Java è predefinito per la modalità-server. È interessante notare che se costringo "- client " non c'è più crash... (Non sono ancora troppo sicuro di cosa fare con il mio SIGSEGV riproducibile, ma è comunque interessante).

Innanzitutto si noti che questo è un po ' correlato ma non identico al seguente perché nel nostro caso è solo un SIGSEGV che accade, e possiamo in modo affidabile attivalo:

Errore JVM OutOfMemory " spirale della morte "(non perdita di memoria)

È correlato perché accade quando alimentiamo la nostra app con un "diluvio di dati": i dati provengono da file di testo e quindi da scricchiolii numerici (sì, scricchiolii di numeri finanziari in Java).

Posso attivare in modo affidabile una JVM su SIGSEGV utilizzando solo codice Java valido.

NOTA : posso invariabilmente bloccare sia JVM 1.6.0_17 che JVM 1.6.0_18 e questa domanda non riguarda come risolvere questo problema problema (ad esempio giocare con i parametri VM può risolvere il problema ma non lo sono dopo, voglio sapere cosa fare con questo SIGSEGV sempre riproducibile).

Ho una soluzione alternativa che consiste semplicemente nell'utilizzare Java 1.5 quando si avvia la nostra app (mentre si utilizza ancora Java 1.6 per eseguire IntelliJ IDEA, ecc. sulla stessa macchina, contemporaneamente), ma la mia domanda è se questo debba essere segnalato o meno e, se dovrebbe, come segnalarlo sapendo che il log stesso contiene proprietà informazioni (il hs_err_ completo..._log).

Errore hardware può essere escluso per:

• Questo sta accadendo su una workstation che raggiunge regolarmente mesi di attività (lo riavvio solo quando vengono rilasciate patch di sicurezza critiche che riguardano il mio Debian Linux tagliato e indurito, il che in realtà non accade spesso) e su cui le applicazioni non si bloccano mai (rendendo molto improbabile che si tratti di un problema hardware su quella macchina [più sotto])

• Stessa applicazione funziona perfettamente su quella stessa macchina con una JVM 1.5 sotto lo stesso carico (questo è il modo in cui sto testando l'app: la lancio semplicemente con una VM 1.5)

• La stessa applicazione funziona perfettamente su più di un centinaio di macchine client sotto lo stesso (gigantesco) carico (mai arrestato una volta su Windows + JVM 1.5 o 1.6 e mai arrestato una volta su OS X + JVM 1.5 o 1.6 [un crash significherebbe una telefonata istantanea dal client])

• Altra applicazione su quella stessa macchina e la stessa JVM 1.6.0_17 o 1.6.0_18 non si blocca mai (ad esempio ho due istanze di IntelliJ IDEA in esecuzione come due utenti diversi su quella stessa macchina e non si bloccano)

• La macchina viene testata con memtest "regolarmente" (prima di installare un nuovo sistema operativo, che è accaduto l'ultima volta quando ho installato Debian Lenny, non molto tempo fa)

Ecco il SIGSEGV riproducibile su richiesta:

... $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)

Avviare l'applicazione, alimentarlo un "diluvio di dati", attendere alcuni secondo...

Quindi, invariabilmente, per 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

(si noti che la riga '[libjvm.so+0x4bc080] ' è coerente per 1.6.0_17 ad ogni SIGSEGV)

O per 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

(si noti che la riga "[libjvm.so+0x4d88f0] " è coerente per 1.6.0_18 ad ogni SIGSEGV)

Il problema è che il file di registro contiene informazioni proprietarie questo non può essere condiviso.

Riprodurre un" piccolo test case " che riproduce il problema non è realistico: è simile per il problema collegato sopra, questo accade solo quando un "diluvio di dati" viene alimentato all'app.

Si noti che la stessa identica applicazione, esattamente sullo stesso hardware, con esattamente la stessa JVM ma un'altra versione di Linux (avevo Debian Etch in precedenza) NON ha attivato quel SIGSEGV una volta.

Ma questo non significa che la JVM non sia in colpa: potrebbe comunque essere un problema di JVM.

Devo segnalare questo e come? (tenendo presente che scrivere un "piccolo test case riproducibile" è delirante e che il registro contiene informazioni proprietarie che non dovrebbero essere trapelate). Devo solo modificare il registro e inviarlo?

Qual è la procedura per segnalare tale SIGSEGV riproducibile quando il log contiene informazioni proprietarie e quando un caso di test che riproduce il problema non è realisticamente fattibile?

Qualcuno di voi ha avuto successo nell'aprire un tale bug e poi vederlo risolto in una successiva versione Java?

Pensi che sia bene "per la comunità Java" segnalare un problema del genere o non dovrei disturbarmi perche 'non e' importante?