Customer had this issue a month ago and unfortunately at that
time there was no coredump available and only a hotspot.

The application crashed again and this time we have collected
a dataset which includes a hotspot and coredump (pkgapp output)

The customer is requesting an RCA to be completed

The dataset is located on CORES2
/cores_data/pool-0/data4/3-6908991941

The stack is as follows
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00002aaaaaf1a712, pid=28152, tid=1156618560
#
# JRE version: 6.0_31-b23
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.6-b02 mixed mode
linux-amd64 compressed oops)
# Problematic frame:
# C [libzip.so+0x5712] double+0x42
/Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)/
C [libzip.so+0x5712] double+0x42

<snip>
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/Act
ionCode;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/ut
il/net/SocketWrapper;)Lorg/apache/tomcat/util/net/AbstractEndpoint$Handler$Soc
ketState;
J
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Lorg/apac
he/tomcat/util/net/SocketWrapper;Lorg/apache/tomcat/util/net/SocketStatus;)Lor
g/apache/tomcat/util/net/AbstractEndpoint$Handler$SocketState;
J org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run()V
J java.util.concurrent.ThreadPoolExecutor$Worker.run()V
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub


Customer is requesting a RCA to be completed.

They have not been able to reliably reproduce this issue yet
but are continuing attempts to reprocuce.

One of our senior engineers has done some analysis on the corefile / pkgapp
dataset which follows

 $ ./saenv.gen.sh
jsdb> load("/home/javateam/tools/sa.js");
jsdb> lookAtJavaThread2(8780);
Look at the 8780.stack generated.

hsdb> inspect 0x00000007032a87d8
instance of Oop for org/apache/coyote/Request @ 0x00000007032a87d8 @
0x00000007032a87d8 (size = 160)
unparsedURIMB: Oop for org/apache/tomcat/util/buf/MessageBytes @
0x00000007033105c0 Oop for org/apache/tomcat/util/buf/MessageBytes @
0x00000007033105c0
uriMB: Oop for org/apache/tomcat/util/buf/MessageBytes @ 0x00000007033105f0
Oop for org/apache/tomcat/util/buf/MessageBytes @ 0x00000007033105f0
decodedUriMB: Oop for org/apache/tomcat/util/buf/MessageBytes @
0x0000000703310620 Oop for org/apache/tomcat/util/buf/MessageBytes @
0x0000000703310620

hsdb> inspect 0x00000007033105c0
instance of Oop for org/apache/tomcat/util/buf/MessageBytes @
0x00000007033105c0 @ 0x00000007033105c0 (size = 48)
byteC: Oop for org/apache/tomcat/util/buf/ByteChunk @ 0x0000000703307900 Oop
for org/apache/tomcat/util/buf/ByteChunk @ 0x0000000703307900
charC: Oop for org/apache/tomcat/util/buf/CharChunk @ 0x00000007032fe0f0 Oop
for org/apache/tomcat/util/buf/CharChunk @ 0x00000007032fe0f0

hsdb> inspect 0x0000000703307900
instance of Oop for org/apache/tomcat/util/buf/ByteChunk @ 0x0000000703307900
0x0000000703307900 (size = 48)
_mark: 5
buff: [B @ 0x000000070349d748 Oop for [B @ 0x000000070349d748
start: 4
end: 271


(gdb) x/4gx 0x000000070349d748
0x70349d748:    0x0000000000000001      0x00010000f80001c6
0x70349d758:    0x6572432f20544547      0x74726f5074654e77

(gdb) print (char*) 0x70349d758
$3 = 0x70349d758 "GET
/CrewNetPortal/CrewAdvSearch?searchType=AdvSearch&lncriteria=begins+with&lastn
ame=&fncriteria=begins+with&firstname=david&id=&uid=&extension=&station=&mailp
ort=&supervisorpoid=&supervisorname=&deptID=&deptIDx=&deptNamex=&building=&ski
lls=&projects=&groups=&otherinfo= HTTP/1.1\r\n

HTTP requests ends with HTTP/1.1\r\n.

So the key is, reproducing it reliably.  And then get a fix so that we know
it is fixed.
jdk7 has a newer libzip than 6.