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

Crash when hprof heap=dump with some JVM options is used in JDK6

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Won't Fix
    • Affects Version/s: 6u1
    • Fix Version/s: 7
    • Component/s: tools
    • Labels:
    • Subcomponent:
    • CPU:
      sparc
    • OS:
      solaris_9

      Description

      Problem
      =======
      JDK 6u1, JDK6u2-b01, JDK7 with these JVM options
      will crash on "Ctrl-\" when heap dumping.
      These JVM option is
      "-verbose:gc -XX:+PrintClassHistogram -XX:+UseSerialGC"
      (for this testcase)

      This is not seen in JDK15011 (ie no problem)


      OS
      ---
      - Solaris 9/10
      - JDK6u1, JDK6u2-b01, JDK7


      CRASH
      -----
      # jdk6_02/bin/java -verbose:gc -XX:+PrintClassHistogram -XX:+UseSerialGC -Xmx256m -agentlib:hprof=heap=dump NoOOM

      * The issue seems happen when all 3 of these options is in
        "-verbose:gc -XX:+PrintClassHistogram -XX:+UseSerialGC"

      NO CRASH
      --------
      jdk6_02/bin/java -Xmx256m -agentlib:hprof=heap=dump NoOOM

      a) When option no present
      b) **** DOES NOT CRASH when RUNNING on JDK 15011 ***


      DISPLAY
      ========
      When "Ctrl-\" is entered the following happens

      [2]: flavor=1, refKind=9, primType=0, object_index=0x50000554, length=-1, next=0x0
      [4]: flavor=1, refKind=9, primType=0, object_index=0x50000650, length=-1, next=0xb00004e7
      [3]: flavor=1, refKind=9, primType=0, object_index=0x5000064f, length=-1, next=0xb00004e6
      [2]: flavor=1, refKind=9, primType=0, object_index=0x50000554, length=-1, next=0x0

      PROBLEM WITH:
      HPROF ERROR: SANITY IN QUESTION: SANITY_ADD_HARE(index,ltable->hare)==(index) [hprof_table.c:928]
      HPROF ERROR: SANITY IN QUESTION: (index) < ltable->next_index [hprof_table.c:931]
      #
      # An unexpected error has been detected by Java Runtime Environment:
      #
      # SIGSEGV (0xb) at pc=0xfe595e60, pid=24153, tid=6
      #
      # Java VM: Java HotSpot(TM) Server VM (1.7.0-ea-b10 mixed mode)
      # Problematic frame:
      # C [libhprof.so+0x5e60]
      #
      # An error report file with more information is saved as hs_err_pid24153.log
      #
      # If you would like to submit a bug report, please visit:
      # http://java.sun.com/webapps/bugreport/crash.jsp
      #
      Abort (core dumped)


      Pstack
      -------
      ----------------- lwp# 6 / thread# 6 --------------------
       ff2c0f90 _lwp_kill (6, 0, ff2a4a98, ffffffff, ff2e8284, 6) + 8
       ff23ff98 abort (2d090, 1, 0, a83f0, ff2eb298, 0) + 110
       fed9f804 ???????? (1, fefb5fd0, 1, fefa0000, 15fd0, 15c00) + ffffffffffb5f97c
       fee80808 ???????? (fefcc550, fffd7488, 1, 0, 0, fefb5fa8) + ffffffffffc40980
       fe957e94 JVM_handle_solaris_signal (b, e7bff488, e7bff1d0, 65c00, 184800, fe595e60) + a58
       ff2bfec8 __sighndlr (b, e7bff488, e7bff1d0, fe957404, 0, 1) + c
       ff2b4ff4 call_user_handler (b, ffbffeff, c, 0, fc150c00, e7bff1d0) + 3b8
       fe595e60 class_get_signature (fe5cc5e0, fe5cc94c, 834, fe5cc118, 362f0, 800) + 3c
       fe5a8800 dump_field (1cd9d0, 1cbc28, 1d, 1d, e7bff638, 4a) + 34
       fe5a8ac8 verify_field (b0000518, 1cd9d0, 1cbc28, 1d, 1d, e7bff6c8) + 7c
       fe5a9e2c dump_instance (1d, 260, b0000518, 1cbc28, 0, fd558) + 8c0
       fe5aa490 reference_dump_instance (1848e8, 50000378, b0000518, fe5cc118, 1910c, 800) + c
       fe5a8034 dump_instance_references (50000378, 1c3fe8, 10, 19f760, 1848e8, 6f) + c
       fe5adf84 table_walk_items (495c8, fe5a8028, 1848e8, 4560, 49648, 14) + 180
       fe5a85f0 object_reference_dump (1848e8, 834, 24000, 23b60, fe5cc118, 800) + 3c
       fe5abbd8 site_heapdump (1848e8, 21000, fe5ab048, fe5cc118, fe5cc94c, fffdef30) + 104






      --------------------
      import java.util.*;
      public class NoOOM
      {
          public static void main(String args[]) {
             Object leakobject = new Object[5000000];
             try {
                HashMap h = new HashMap(10000);
                for (int i=0;i<100;i++) {
                     Object o = new byte[1000000];
                     Object o2 = new NoOOM();
                     h.put(o,o);
                     h.put(o2,o2);
                }
             } catch (Exception e) {}
             while (true) {
                try { Thread.sleep(1000); } catch (Throwable t) {}
             }
          }
      }
      ---------------
      NOTE
      =====
      To be precise actually the problem will not be seen if the GC
      algorithm used is ParallelGC, others like SerialGC and ConcMarkSweep
      seems to exhibit this problem. In the test when the
      GC algo is not set, i believe your test and mind
      defaults to ParallelGC and it did not crash

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                ohair Kelly Ohair (Inactive)
                Reporter:
                cchea Chee-Weng Chea (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: