Hi,
I work in the JDK team and have a few reports of the JVM crashing in
lead on calls from the Apache Coyote stack. A typical trace looks like :
# Problematic frame:
# C [libzip.so+0x5712] double+0x42
..
Stack: [0x0000000047949000,0x0000000047a4a000], sp=0x0000000047a48600,
free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)
C [libzip.so+0x5712] double+0x42
..
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J java.util.zip.Deflater.deflateBytes(J[BII)I
J java.util.zip.GZIPOutputStream.finish()V
J org.apache.coyote.http11.filters.FlushableGZIPOutputStream.finish()V
J org.apache.coyote.http11.filters.GzipOutputFilter.end()J
J org.apache.coyote.http11.InternalOutputBuffer.endRequest()V
J
org.apache.coyote.http11.AbstractHttp11Processor.action(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V
J org.apache.catalina.connector.OutputBuffer.close()V
J
org.apache.catalina.connector.CoyoteAdapter.service(Lorg/apache/coyote/Request;Lorg/apache/coyote/Response;)V
J
org.apache.coyote.http11.AbstractHttp11Processor.process(Lorg/apache/tomcat/util/net/SocketWrapper;)Lorg/apache/tomcat/util/net/AbstractEndpoint$Handler$SocketState;
It looks like the FlushableGZIPOutputStream class was designed to
overcome limitations in the JDK 6 API :
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/coyote/http11/filters/FlushableGZIPOutputStream.html.
The subclass gets a handle on the protected Deflater Object and is then
in a position to flush the underlying stream when needed. The crash
occurs deep in the bowls of zlib code (deflate_slow function) - Reports
I've seen suggest it occurs on heavy multi-threaded operations. I've no
root cause for the SEGV yet.
Is anyone on this list aware of similar issues ? The above issue was
seen with JDK 6 and Tomcat 7.0.29.A. Was there any instances of multiple
threads accessing the same stream concurrently ?
regards,
Sean.
