JDK-4719788 : HPROF: java -Xrunhprof:format=b produces malformed binary dumps
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_8
  • CPU: generic,sparc
  • Submitted: 2002-07-24
  • Updated: 2012-10-08
  • Resolved: 2002-10-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisFixed
Related Reports
Duplicate :  
JDK-4747238 - HPROF: 1.4 hprof dump doesnt work with HAT
Description
If I try to use the dump with hat, it will fail with an EOFException:
    Read heap sub-record type 34 at position 0x00271311
java.io.EOFException
        at java.io.DataInputStream.readInt(DataInputStream.java:398)
        at hat.parser.HprofReader.readID(HprofReader.java:476)
        at hat.parser.HprofReader.readArray(HprofReader.java:852)
        at hat.parser.HprofReader.readHeapDump(HprofReader.java:432)
        at hat.parser.HprofReader.read(HprofReader.java:222)
        at hat.parser.Reader.readFile(Reader.java:91)
        at hat.Main.main(Main.java:135)

the problem is some garbage randomly inserted into the stream just after
the 0x22 (OBJ_ARRAY) header:
00271300 00 00 11 7C  40 00 11 7B  58 00 12 87  C0 00 12 88 ...|@..{X..��..��
00271310 40 22 01 0B  4C 9B D0 00  00 00 07 00  4D 52 F8 5B @"..L.��.....MR��[
OBJ_ARRAY --^^ ^^-- start of garbage
00271320 5B 43 02 0B  4C 9B D0 00  00 00 10 00  00 03 1E 00 [C..L.��.........
00271330 10 C6 48 00  00 00 00 00  4D 52 F8 00  10 C6 68 00 .��H.....MR��..��h.
                     end of gargabe -----^^ ^^-- continuation of the header
00271340 00 00 01 00  00 00 66 00  10 C6 48 00  10 C6 A8 00 ......f..��H..����.
00271350 10 C9 08 00  10 C9 68 00  10 C9 C8 00  10 CA 28 00 .��...��h..����..��(.
00271360 10 CA 88 00  10 CA E8 00  10 CB 48 00  10 CB A8 00 .��...����..��H..����.
00271370 10 CC 08 00  10 CC 68 00  10 CC C8 00  10 CD 28 00 .��...��h..����..��(.

Note: only some of the OBJ_ARRAY headers are broken, there were several
correct OBJ_ARRAY records in the stream before this failure.
There are also more failures after this point.

I've reproduced the problem on a simple application with both 1.4-b92 and 1.4.1-b12 JDKs. With 1.3.1 JDK it works correctly.
A colleague of mine have also reported it on Linux

I'm usually using hprof with depth=0, that is why there is always
00 00 00 01 stack trace reference in the dumps but I've reproduced the problem
also without depth=0 hprof option
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b05
14-06-2004
EVALUATION Copied from 4747238: ###@###.### 2002-09-13 As usual, Mandy is right! The fix for 4508003 modified the logic used during construction of the HPROF_GC_OBJ_ARRAY_DUMP record type to request a CLASS_LOAD event when needed. The change allows the class name to be displayed in text output format, but it scrambles the output stream in binary output format (format=b). The logic that Mandy changed is only needed in the text output code path so it should be possible to rearrange the code to only make the CLASS_LOAD event request when doing text output as opposed to binary format. While this would solve the immediate HPROF_GC_OBJ_ARRAY_DUMP record corruption problem, it may introduce another problem. The HPROF_GC_OBJ_ARRAY_DUMP record will contain a reference to a class that hasn't been "defined" yet. However, it appears from perusing the hprof output that CLS entries quite often come after objects that refer to them.
11-06-2004
SUGGESTED FIX Name: dd4877 Date: 09/19/2002 daniel.daugherty@Sun 2002-09-19 Here are the context diffs for the suggested fix: ------- src/share/tools/hprof/hprof_heapdump.c ------- *** /tmp/sccs.dSaW0J Thu Sep 19 17:08:48 2002 --- hprof_heapdump.c Thu Sep 19 17:08:28 2002 *************** *** 614,623 **** unsigned int num_elements = hprof_dump_read_u4(); void *class_id = hprof_dump_read_id(); hprof_objmap_t *classmap = hprof_fetch_object_info(class_id); - hprof_class_t *class; unsigned int trace_serial_num = 0; int size = 0; - const char *class_name; if (objmap != NULL) { trace_serial_num = objmap->site->trace_serial_num; --- 614,621 ---- *************** *** 624,636 **** size = objmap->size; } - class = hprof_lookup_class_objmap(classmap); - if (class == NULL || class->name == NULL) { - CALL(RequestEvent)(JVMPI_EVENT_CLASS_LOAD, class_id); - class = hprof_lookup_class_objmap(classmap); - } - class_name = (class == NULL || class->name == NULL) ? "<Unknown>" : class->name->name; - if (output_format == 'b') { hprof_write_id(objmap); hprof_write_u4(trace_serial_num); --- 622,627 ---- *************** *** 637,642 **** --- 628,643 ---- hprof_write_u4(num_elements); hprof_write_id(classmap); } else { + hprof_class_t *class = hprof_lookup_class_objmap(classmap); + const char *class_name; + + if (class == NULL || class->name == NULL) { + CALL(RequestEvent)(JVMPI_EVENT_CLASS_LOAD, class_id); + class = hprof_lookup_class_objmap(classmap); + } + class_name = (class == NULL || class->name == NULL) ? + "<Unknown>" : class->name->name; + hprof_printf("ARR %x (sz=%u, trace=%u, nelems=%u, elem type=%s@%x)\n", objmap, size, trace_serial_num, num_elements, class_name, classmap); ======================================================================
11-06-2004
PUBLIC COMMENTS .
10-06-2004