United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4719788 HPROF: java -Xrunhprof:format=b produces malformed binary dumps
JDK-4719788 : HPROF: java -Xrunhprof:format=b produces malformed binary dumps

Details
Type:
Bug
Submit Date:
2002-07-24
Status:
Closed
Updated Date:
2012-10-08
Project Name:
JDK
Resolved Date:
2002-10-26
Component:
hotspot
OS:
solaris_8,generic
Sub-Component:
runtime
CPU:
sparc,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.0
Fixed Versions:
1.4.2 (mantis)

Related Reports
Duplicate:

Sub Tasks

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
PUBLIC COMMENTS

.
                                     
2004-06-10
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);


======================================================================
                                     
2004-06-11
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.
                                     
2004-06-11
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mantis

FIXED IN:
mantis

INTEGRATED IN:
mantis
mantis-b05


                                     
2004-06-14



Hardware and Software, Engineered to Work Together