Marco problemático de JVM Crash: Canonicalizer:: do_If

canonical-link (3)

Noté que ambos -javaagent y -noverify en la lista de opciones de Java.

Parece que el agente springloaded genera un bytecode inválido, mientras que la verificación de bytecode está explícitamente desactivada. No es de extrañar, esto puede llevar a resultados impredecibles, incluido el bloqueo de JVM.

Este no es un problema de JVM, pero lo más probable es que haya un error en el agente springloaded por springloaded . Intenta eliminar la opción -noverify .

-XX:-TieredCompilation también puede -XX:-TieredCompilation este problema en particular, pero no espere que la aplicación funcione correctamente si el bytecode no pasa la verificación. Es mejor mantenerse alejado de las bibliotecas de agente con errores.

Iam frente a JVM Crash de manera constante mientras habilita hotdeploy (USANDO debajo de las opciones de java al iniciar JAVA_OPTS -Xmx4096m -XX: MetaspaceSize = 512m -XX: + HeapDumpOnOutOfMemoryError -XX: HeapDumpPath = crash -XX: ThreadStackSize = 512 -XX: + UseConcMarkSweepGC -XX: ParallelGCThreads = 5 -XX: NewRatio = 2 -XX: + UnlockDiagnosticVMOptions -XX: -UseLoopPredicate -Xdebug -Xrunjdwp: transport = dt_socket, address = $ DEBUG_PORT, server = y, suspend = n -XX: NewRatio = 2 -Dspringloaded.synchronize = verdadero JAVA_OPTS = `echo $ JAVA_OPTS -Dspringloaded.synchronize = true -javaagent: springloaded-1.2.1.jar -noverify )

Medio ambiente: JDK 1.8 U 66, RHEL 6.7

# # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007faee9a1e27c, pid=27208, tid=140379827795712 # # JRE version: Java(TM) SE Runtime Environment (8.0_66-b17) (build 1.8.0_66-b17) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode linux-amd64 ) # Problematic frame: # V [libjvm.so+0x35027c] Canonicalizer::do_If(If*)+0x1c # # Core dump written. Default location: core.27208 # # An error report file with more information is saved as: # hs_err_pid27208.log # [ timer expired, abort... ]

4.2.1 Fallo en el hilo del compilador de HotSpot o código compilado
Si el registro de error fatal indica que el bloqueo se produjo en un hilo del compilador, entonces es posible (pero no siempre es el caso) que haya encontrado un error en el compilador. De forma similar, si el bloqueo está en código compilado, entonces es posible que el compilador haya generado un código incorrecto.
En el caso de la máquina virtual del cliente HotSpot (opción de cliente), el hilo del compilador aparece en el registro de errores como CompilerThread0. Con la máquina virtual de HotSpot Server hay varios hilos de compilación y estos aparecen en el archivo de registro de errores como CompilerThread0, CompilerThread1 y AdapterThread.
A continuación se muestra un fragmento de un registro de error para un error del compilador que se encontró y se solucionó durante el desarrollo de J2SE 5.0. El archivo de registro muestra que se utiliza la máquina virtual de HotSpot Server y el bloqueo se produjo en CompilerThread1. Además, el archivo de registro muestra que Current CompileTask fue la compilación del método java.lang.Thread.setPriority.
Un error inesperado ha sido detectado por la máquina virtual de HotSpot: Java VM: Java HotSpot (TM) Server VM (modo mixto 1.5 interno de depuración): --------------- THREAD - -------------
Tema actual (0x001e9350): JavaThread "CompilerThread1" daemon [_thread_in_vm, id = 20]
Pila: [0xb2500000,0xb2580000), sp = 0xb257e500, espacio libre = 505k Marcos nativos: (J = código Java compilado, j = interpretado, Vv = código VM, C = código nativo) V [libjvm.so + 0xc3b13c]:
Current CompileTask: opto: 11 java.lang.Thread.setPriority (I) V (53 bytes)
--------------- PROCESO ---------------
Java Threads: (=> thread actual) 0x00229930 JavaThread demonio "Low Memory Detector" [_thread_blocked, id = 21] => 0x001e9350 JavaThread "CompilerThread1" daemon [_thread_in_vm, id = 20]:
En este caso, hay dos soluciones posibles:
The brute force approach: change the configuration so that the application is run with the -client option to specify the HotSpot
Cliente VM.
Assume that the bug only occurs during the compilation of the setPriority method and exclude this method from compilation.
El primer enfoque (para usar la opción -client) podría ser trivial de configurar en algunos entornos. En otros, puede ser más difícil si la configuración es compleja o si no se puede acceder fácilmente a la línea de comando para configurar la máquina virtual. En general, el cambio de VM de HotSpot Server a VM de HotSpot Client también reduce el rendimiento máximo de una aplicación. Dependiendo del entorno, esto podría ser aceptable hasta que se diagnostique y solucione el problema real.
El segundo enfoque (excluir el método de la compilación) requiere la creación del archivo .hotspot_compiler en el directorio de trabajo de la aplicación. A continuación se muestra un ejemplo de este archivo:
excluir java / lang / Thread setPriority
En general, el formato de este archivo excluye el MÉTODO DE CLASE, donde CLASS es la clase (completamente calificado con el nombre del paquete) y METHOD es el nombre del método. Los métodos de constructor se especifican como y los inicializadores estáticos se especifican como.
Nota: El archivo .hotspot_compiler es una interfaz no compatible. Está documentado aquí únicamente con el objetivo de solucionar problemas y encontrar una solución temporal.
Una vez que se reinicia la aplicación, el compilador no intentará compilar ninguno de los métodos enumerados como excluidos en el archivo .hotspot_compiler. En algunos casos, esto puede proporcionar un alivio temporal hasta que se diagnostique la causa raíz del bloqueo y se solucione el error.
Para verificar que la VM HotSpot ubicó y procesó correctamente el archivo .hotspot_compiler que se muestra en el ejemplo anterior, busque la siguiente información de registro en tiempo de ejecución. Tenga en cuenta que el separador de nombre de archivo es un punto, no una barra inclinada.
Excluyendo compilación: java.lang.Thread :: setPriority

Fuente

De acuerdo con @apangin, en el programa está haciendo bytecode intrumentation (-agent) pero especifica -noverify. Cuando la verificación está desactivada, puede terminar dichos bloqueos.

No debe usar -noverify o -Xverify: none durante la instrumentación de código byte.

Para aquellos de ustedes que no están familiarizados con la verificación de códigos de bytes, es simplemente parte del proceso de carga de clases de la JVM que verifica el comportamiento peligroso y no permitido del código. Puede (pero no debería) desactivar esta protección en muchas JVM agregando -Xverify: none o -noverify a la línea de comandos de Java. https://blogs.oracle.com/buck/entry/never_disable_bytecode_verification_in