Tomcat se detiene con EXCEPTION_ACCESS_VIOLATION (0xc0000005)

Deja un comentario / Sap

Un Usuario hizo la siguiente pregunta

Hola,

Estamos utilizando BusinessObjects 4.0. A veces, nuestro gato se detiene con el siguiente mensaje en stdout.log

# El entorno de ejecución de Java detecta un error grave:

#

# EXCEPTION_ACCESS_VIOLATION (0xc0000005) en pc = 0x000000006d8734ea, pid = 8548, tid = 2716

#

Versión # JRE: 6.0_37-b06

# Java VM: servidor de máquina virtual Java HotSpot (TM) de 64 bits (oops comprimido 20.12-b01 modo mixto windows-amd64)

# Cuadro de problemas:

# C. [zip.dll+0x34ea]

#

————— TRES —————

Hilo actual (0x000000000000bdec000): demonio JavaThread «http-80-32» [_thread_in_native, id=2716, stack(0x0000000019570000,0x0000000019670000)]

siginfo: ExceptionCode = 0xc0000005, leer dirección 0x000000000750b000

Tengo que iniciarlo y luego funciona bien.

¿Alguna idea de cuál podría ser el error?

¡gracias!

8 respuestas

  • James Rapp

    Hola,

    La pista de apilamiento indica un problema con la compresión gzip:

    Tramas Java: (J = código Java compilado, j = intérprete, V = código VM (C / C ++), v = código VM (generado))

    J java.util.zip.Deflater.deflateBytes (J.[BIII)I (sp=0x0000000020b2ef90) (pc=0x0000000009576afe)

    J java.util.zip.Deflater.deflate([BII)I (sp=0x0000000020b2f010) (pc=0x000000000a00d80c)

    J java.util.zip.GZIPOutputStream.finish()V (sp=0x0000000020b2f080) (pc=0x000000000a60da40)

    J org.apache.coyote.http11.filters.FlushableGZIPOutputStream.finish()V (sp=0x0000000020b2f0b0) (pc=0x0000000009f70fbc)

    J org.apache.coyote.http11.filters.GzipOutputFilter.end()J (sp=0x0000000020b2f0e0) (pc=0x000000000b4a566c)

    J org.apache.coyote.http11.AbstractHttp11Processor.action(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V (sp=0x0000000020b2f110) (pc=0x000000000aaff63c)

    J org.apache.catalina.connector.OutputBuffer.close()V (sp=0x0000000020b2f1b0) (pc=0x000000000b165b44)

    J org.apache.catalina.connector.CoyoteAdapter.service(Lorg/apache/coyote/Request;Lorg/apache/coyote/Response;)V (sp=0x0000000020b2f200) (pc=0x000000000b0c51d0)

    J org.apache.coyote.http11.AbstractHttp11Processor.process(Lorg/apache/tomcat/util/net/SocketWrapper;)Lorg/apache/tomcat/util/net/AbstractEndpoint$Handler$SocketState; (sp=0x0000000020b2f2a0) (pc=0x000000000b16ae88)

    J org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Lorg/apache/tomcat/util/net/SocketWrapper;Lorg/apache/tomcat/util/net/SocketStatus;)Lorg/apache/tomcat/util/net/AbstractEndpoint$Handler$SocketState; (sp=0x0000000020b2f310) (pc=0x000000000a650794)

    J org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run()V (sp=0x0000000020b2f3c0) (pc=0x000000000b116c94)

    J java.util.concurrent.ThreadPoolExecutor$Worker.run()V (sp=0x0000000020b2f450) (pc=0x0000000009a5a090)

    j java.lang.Thread.run()V – Thread.java:743 (bcx=0x000000018004c74b) (sp=0x0000000020b2f4d0) (pc=0x0000000008d0a4f4)

    v ~StubRoutines::call_stub (sp=0x0000000020b2f538) (pc=0x0000000008d02a3a)

    Here are a couple of links that suggest it is a bug in the JVM:

    http://stackoverflow.com/questions/9742785/tomcat-7-0-25-apr-jre-crash

    http://serverfault.com/questions/506420/tomcat-is-closing-randomly

    If the problem is occuring in the SAPJVM then AGS should escalate internally.

    As a workaround you could:

    1. Disable compression in the server.xml

    2. Leverage Apache with mod_deflate + mod+jk using the instructions here. Since compression would now be handled by the webserver you can disable it from Tomcat and still reap the benefits.

    3. Disable APR as the stack suggests a JNI problem (since the stack references a DLL it means Tomcat is accessing the filesystem via Apache Portable Runtime using JNI)

    To disable APR, rename/delete the tc-native.dll file from the Tomcat bin directory and restart Tomcat. While APR is intended to improve performance in Tomcat I have not noticed appreciable differences with it enabled or disabled.

    So, in short … AGS should escalate this with the appropriate stack traces and you can select one of the workarounds above in the meantime. I personally suggest option 2 as Apache compression is ~25% more efficient than Tomcat and you should see improvement to overall performance.

  • Former Member

    Hi ALL,

    we disabled compression in the server.xml.

    Since 2 days no breakdowns anymore.

    Thx for all replies

    Holger

  • Former Member

    We are facing the same problem! We are working around the firewall configuration. I’ll let you know if we find out something

  • JinChong Tsai

    Hi,

    Judging from your tomcat log, it seems your BI4.0/Tomcat is running on a Windows platform.

    # JRE version: 6.0_37-b06

    # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.12-b01 mixed mode windows-amd64 compressed oops)

    # Problematic frame:

    1. Do you have Data Execution Prevention (DEP) on the BI4.0 Windows server? If not, please turn it on and reboot the server,
    2. The default Tomcat shipped with BI4.0 is Tomcat 6.0.24. You might consider to upgrade it to Tomcat 6.0.35 or above for the memory leak fixes. See http://tomcat.apache.org/tomcat-6.0-doc/changelog.html on «Fix memory leak of servlet instances when running with a SecurityManager and either init() or destroy() methods fail or the servlet is a SingleThreadModel one, and of filter instances if their destroy() method fails with an Error. (kkolinko)», etc.

    The steps to replace the default Tomcat6 with new Tomcat 6.0.37 is

    1. Stop tomcat
    2. Move BI4.0InstallDrive:Program Files (x86)SAP BusinessObjectsTomcat6 to BI4.0InstallDrive:Program Files (x86)SAP BusinessObjectsTomcat6.0.24
    3. Download and unpack apache-tomcat-6.0.37-windows-x64.zip to BI4.0InstallDrive:Program Files (x86)SAP BusinessObjectsTomcat6 folder.
    4. Run Tomcat configuration and rename it to «Apache Tomcat 6.0.37» in the display name.
    5. Ensure Java virtual machine is intact as

    E:Program Files (x86)SAP BusinessObjectsSAP BusinessObjects Enterprise XI 4.0win64_x64jdk\jrebinserverjvm.dll

    f. Ensure Java class path is intact as

    E:Program Files (x86)SAP BusinessObjectsTomcat6binbootstrap.jar;E:Program Files (x86)SAP BusinessObjectsSAP BusinessObjects Enterprise XI 4.0win64_x64jdklibtools.jar

    g. Ensure all Java_Option is intact as

    -Dsun.lang.ClassLoader.allowArraySyntax=true

    -Djava.library.path=C:WindowsSysWOW64;E:Program Files (x86)SAP BusinessObjectsSAP BusinessObjects Enterprise XI 4.0win64_x64

    -Djava.library.path=C:WindowsSysWOW64;E:Program Files (x86)SAP BusinessObjectsSAP BusinessObjects Enterprise XI 4.0win64_x64

    -Dcatalina.base=E:Program Files (x86)SAP BusinessObjectsTomcat6

    -Dcatalina.home=E:Program Files (x86)SAP BusinessObjectsTomcat6

    -Djava.endorsed.dirs=E:Program Files (x86)SAP BusinessObjectsTomcat6commonendorsed

    -Dbobj.enterprise.home=E:Program Files (x86)SAP BusinessObjectsSAP BusinessObjects Enterprise XI 4.0

    -Xrs

    -XX:MaxPermSize=384M

    -Dbusinessobjects.olap.bin=

    -Dbusinessobjects.olap.stylesheets=

    -Djava.awt.headless=true

    h. Max memory pool could be 5120 MB or higher,

    i. Copy all BI4.0 war web.xml from BI4.0InstallDrive:Program Files (x86)SAP BusinessObjectsTomcat6.0.24confCatalinalocalhost*.xml to BI4.0InstallDrive:Program Files (x86)SAP BusinessObjectsTomcat6confCatalinalocalhost folder,

    j. Start Tomcat service in CCM and watch the BI4.0 war are been deployed properly.

    Hope this helps,

    Jin-Chong

  • Former Member

    Hello,

    We are also using BusinessObjects 4.0 and every day between 01:00 and 04:00 PM our tomcat stops with exactly the same message!

    After that we start tomcat and it works fine till the next day and then it crashes again 🙁

    #
    # A fatal error has been detected by the Java Runtime Environment:
    #
    # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000006d8734ea, pid=13308, tid=15488
    #
    # JRE version: 6.0_32-b05
    # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.7-b02 mixed mode windows-amd64 compressed oops)
    # Problematic frame:
    # C [zip.dll+0x34ea]
    #

    ————— TRES —————

    Hilo actual (0x000000000000bd75800): demonio JavaThread «http-8080-1» [_thread_in_native, id=15488, stack(0x000000000f830000,0x000000000f930000)]

    siginfo: ExceptionCode = 0xc0000005, leer la dirección 0x000000000c7f5000

    ————————————————– —- ———————————————- ———- ——————

    Actualizamos SP7 pero el error aún existe.

    Tenemos una llamada SAP abierta, pero no todas las soluciones funcionan hasta ahora.

    (La actualización a la versión 6.0.32 no es la redistribución de JRE y tomcat6 :-()

    Nuria, ¿encontraste algo en la consolidación del firewall?

    Jin-Chong, ¿qué hay de tu solución? ¿Es como una solución de SAP en Downgrade?

    ¿Alguien tiene una solución para nosotros ?????

    Holger

  • Ex miembro

    Hola Hans,

    El servidor Tomcat generalmente se detiene debido a una carga pesada del servidor, por lo que crea un servidor de clúster o

    Intente actualizar especialmente la RAM del hardware.

    Sobre

    Jeetan

  • Ex miembro

    Hola Hans

    Verifique la memoria JAVA_OPTS en tomcat y multiplique los valores.

    Verifique la versión de JAVA en tomcat y también verifique la versión de Java en BO.

    Gracias y Saludos,

    V Srinivasan

  • Ex miembro

    Hola,

    He intentado investigar un poco sobre este tipo de error antes.

    Consulte esta nota de KBA:

    http://service.sap.com/sap/support/notes/1906557

    Espero que esto te ayude a resolver tu problema.

    Con todos los buenos deseos.

    Mehrez Ben Ouali

Seguro que también te interesa

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Salir de la versión móvil