Java VM: SIGSEGV reproducible en 1.6.0_17 y 1.6.0_18, ¿cómo informar?

Question

EDIT: Este SIGSEGV reproducible ocurre en una máquina Linux con más de un procesador y más de 2 GB de memoria, por lo que Java está por defecto en el modo -servidor. Curiosamente, si forzo "-client", ya no hay colisión ... (Todavía no estoy muy seguro de qué hacer con mi SIGSEGV reproducible, pero es interesante, no obstante).

Primera nota que este es un poco relacionado, pero no idéntica, a la siguiente debido a que en nuestro caso es sólo una violación de segmento que pasa, y de forma fiable puede desencadenarla:

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

Está relacionado, ya que ocurre cuando alimentamos nuestra aplicación con un "aluvión de datos": los datos proceden de archivos de texto y luego se procesan los números (sí, el cálculo del número financiero en Java).

Puedo activar confiablemente una JVM a SIGSEGV utilizando solo código válido de Java.

NOTA: Puedo invariablemente estrello tanto JVM 1.6.0_17 adn JVM 1.6.0_18 y esta pregunta no es acerca de cómo solucionar este problema (por ejemplo, jugar con VM parámetros puede solucionar el problema, pero estoy no después de eso, quiero saber qué hacer con este SIGSEGV siempre reproducible).

Tengo una solución que consiste simplemente en usar Java 1.5 al iniciar nuestra aplicación (mientras todavía utilizo Java 1.6 para ejecutar IntelliJ IDEA, etc. en la misma máquina, simultáneamente), pero mi pregunta es si esto debería ser informados o no y, si corresponde, cómo informarlo sabiendo que el registro en sí contiene información de propiedad (el hs_err _..._ registro completo).

Error de hardware se puede descartar para:

• esto está ocurriendo en una estación de trabajo que alcanza regularmente meses de tiempo de actividad (sólo reiniciarlo cuando los parches de seguridad críticos que afectan a mi recortada y se endurecieron Debian Linux son emitidos , que realmente no sucede a menudo) y en las que las aplicaciones nunca fallan (es muy poco probable que sea un problema de hardware en esa máquina [más abajo])

• misma aplicación funciona perfectamente en esa misma máquina bajo una JVM 1.5 bajo la misma carga (así es como estoy probando la aplicación: simplemente la lanzo bajo 1.5 VM)

• misma aplicación funciona perfectamente bien en más de una máquina de cientos de clientes bajo la misma (gigantesca) carga (nunca se estrelló una vez en Windows + JVM 1.5 o 1.6 y nunca se bloqueó una vez en OS X + JVM 1.5 o 1.6 [un bloqueo significaría una llamada telefónica instantánea del cliente])

• otra aplicación en esa misma máquina y la misma 1.6.0_17 o 1.6.0_18 JVM nunca falla (por ejemplo, tengo dos instancias de IntelliJ IDEA ejecutándose como dos usuarios diferentes en la misma máquina y no se bloquean)

• la máquina se prueba con memtest "regularmente" (antes de instalar una nueva OS, que ocurrió el pasado cuando he instalado Debian Lenny, no hace mucho tiempo)

Aquí está la SIGSEGV reproducible a la carta:

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

lanzar la aplicación, darle de comer una "avalancha de datos ", espera unos segundos ...

Entonces, invariablemente, por 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 

(Observe que la línea '[libjvm.so + 0x4bc080]' es consistente para 1.6.0_17 en cada SIGSEGV)

o para 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 

(tenga en cuenta que la línea "[libjvm.so + 0x4d88f0]" es consistente para 1.6.0_18 en cada SIGSEGV)

la prob Lem es que el archivo de registro contiene información de propiedad que no se puede compartir.

La reproducción de un "minúsculo caso de prueba" que reproduzca el problema tampoco es realista: es similar al problema relacionado anteriormente, esto solo ocurre cuando se carga un "diluvio de datos" a la aplicación.

Tenga en cuenta que exactamente la misma aplicación, exactamente en el mismo hardware, con exactamente la misma JVM pero con otra versión de Linux (tuve Debian Etch anteriormente) NO activó ese SIGSEGV una vez.

Pero esto no significa que la JVM no tenga la culpa: aún podría ser un problema de JVM.

¿Debo informar esto y cómo? (teniendo en cuenta que escribir un "caso de prueba pequeño reproducible" es ilusorio y que el registro contiene información patentada que no debe filtrarse). ¿Debo simplemente editar el registro y enviarlo?

¿Cuál es el procedimiento para informar dicho SIGSEGV reproducible cuando su registro contiene información patentada y cuando un caso de prueba que reproduce el problema no es factible realísticamente?

¿Alguno de ustedes tuvo éxito al abrir un error y luego verlo resuelto en una posterior versión de Java?

¿Crees que es bueno "para la comunidad Java" informar un problema así o simplemente no debería molestarme porque no es importante?

Answer 1

llegué modernización problema similar al JDK 1.6_18 y parece resuelto mediante las siguientes opciones:

-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 

Todavía no retención doble (se trata de un entorno de producción), pero creo que era el error debido a dos razones:

1) Ajuste incorrecto sobre el montón y/o espacio permanente (creo que JDK 1.6 necesita más espacio en el montón y permanente que las versiones de JVM anteriores) causado un OutOfMemoryError, pero

2) en el que alguien la configuración original equivocado escribió

-XX:+HeapDumpOnOutOfMemoryError="/tmp" 

y no

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

así que probablemente JVM no fue capaz de escribir el heapdump y obtuvimos SIGSEGV solamente (las versiones anteriores escribían dump dump en el directorio de trabajo).

Compruebe -server -XX:+UseParallelGC -XX:-UseGCOverheadLimit opciones también. Creo que jugar con los parámetros de VM no es una solución alternativa, sino el enfoque correcto también porque el recolector de basura (y no solo) cambió entre 1.5 y 1.6.

Answer 2

El problema es que el archivo de registro contiene información de propiedad no se pueden compartir. La reproducción de un "caso de prueba pequeña " que reproducen el problema no es realista, ya sea

Si usted no puede proporcionar a Sun un caso de prueba reproducible, ellos ni siquiera mirarlo. Es bueno que lo ignoren incluso si proporciona un caso de prueba utilizable. El proceso de envío de errores en Sun deja mucho que desear.

¿Debo informar esto y cómo?

Si no puede encontrar una funda de prueba reproducible, no se moleste. Si no pueden reproducir el problema, ¿qué espera que hagan?

Tenga en cuenta que la misma aplicación exacta, en exactamente el mismo hardware, con exactamente la misma JVM, pero otra versión de Linux (Debian Etch tuve anteriormente) no provocó que SIGSEGV vez.

¿Funciona en una caja diferente con el mismo hardware y la misma versión de Linux?

Answer 3

La primera pregunta que debe hacerse es:

• estoy usando una distribución Linux compatible oficialmente?

Si no, cambie a uno que sea.

Si es así, ¡comuníquelo a Sun!

Answer 4

Si ayuda, el enlace de envío de errores en su informe de bloqueo tiene esta exención de responsabilidad:

Además, Sun Microsystems respeta su deseo de privacidad. Los datos personales recopilados de este programa no serán vendidos, entregados ni compartidos con organizaciones externas a Sun. Utilizaremos esta información para comunicarnos con usted para aclarar cuestiones relacionadas con el informe que presentó y/o el estado de ese informe. Los problemas que usted informe pueden ponerse a disposición de otros miembros de JDC o clientes de Sun, sin embargo, sus datos personales se mantendrán confidenciales. Si no se siente cómodo con las condiciones anteriores, no presione el botón Enviar. Si tiene alguna pregunta, consulte nuestro Privacy Policy.

Personalmente, me gustaría informar de que si era factible entregar el segmento de código en cuestión con los registros, si los datos no es demasiado sensible (tal vez los datos pueden estar enmascarados o ofuscado en los registros?).

Es imposible para usted juzgar realmente si el error es "importante" o no para los demás a menos que sepa lo que realmente lo causa. Informar que podría ser el primer paso para que los ingenieros de Sun descubran la causa de algo serio.