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

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