Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8028216

Repeated crashes in java.util.zip.deflater.deflatebytes

    XMLWordPrintable

    Details

    • Subcomponent:
    • CPU:
      generic
    • OS:
      generic

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              coffeys Sean Coffey
              Reporter:
              mbankal Mala Bankal (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: