Skip to Content

Archived discussions are read-only. Learn more about SAP Q&A

Tomcat stops with EXCEPTION_ACCESS_VIOLATION (0xc0000005)


We are using BusinessObjects 4.0. Sometimes our tomcat stops with the following message in stdout.log

# A fatal error has been detected by the Java Runtime Environment:


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


# 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:

# C  [zip.dll+0x34ea]


---------------  T H R E A D  ---------------

Current thread (0x000000000bdec000):  JavaThread "http-80-32" daemon [_thread_in_native, id=2716, stack(0x0000000019570000,0x0000000019670000)]

siginfo: ExceptionCode=0xc0000005, reading address 0x000000000750b000

I have to start it and then it works fine.

Any idea what the error could mean?


Former Member
Former Member replied


The stack trace indicates a problem with gzip compression:

Java frames: (J=compiled Java code, j=interpreted, V=VM code (C/C++), v=VM code (generated))

J[BIII)I (sp=0x0000000020b2ef90) (pc=0x0000000009576afe)

J[BII)I (sp=0x0000000020b2f010) (pc=0x000000000a00d80c)

J (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$ (sp=0x0000000020b2f3c0) (pc=0x000000000b116c94)

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

j - (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:

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.

0 View this answer in context
Not what you were looking for? View more on this topic or Ask a question