JDK-6614052 : jhat fails to read heap dump >2GB
  • Type: Bug
  • Component: core-svc
  • Sub-Component: tools
  • Affected Version: 6u3,7
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2007-10-08
  • Updated: 2012-10-01
  • Resolved: 2007-12-14
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.
JDK 6 JDK 7 Other
6u10 b09Fixed 7Fixed OpenJDK6Fixed
Related Reports
Duplicate :  
JDK-6746422 - jhat exception java.io.IOException: Bad record length
Description
jhat fails reading very large (>2GB) heap dumps:

jhat -debug 1 ...

Read record type 2, length 16 at position 0x337c13
Read record type 2, length 16 at position 0x337c2c
Read record type 12, length -1452344221 at position 0x337c45
java.io.IOException: Bad record length of -1452344221 at byte 0x337c4a of file.
       at com.sun.tools.hat.internal.parser.HprofReader.read(HprofReader.java:192)
       at com.sun.tools.hat.internal.parser.Reader.readFile(Reader.java:79)
       at com.sun.tools.hat.Main.main(Main.java:143) 

This is an overflow: the object (i.e. heap dump) size in the dump file is 2.7GB, which has been read as a signed int.


It is understood that the heap size requirements will be very large for jhat to read such a dump.  A 64-bit JVM will usually be needed.  e.g.  jhat -J-d64 -J-Xmx6g etc...
It turns out that this bug has been seen in nightly testing:

New vm.heapdump failures (from 2008.03.29)
    heapdump/JMapHeap
    heapdump/JMapPerm
    heapdump/OnOOMToFile
    heapdump/OnOOMToPath
        These tests failed due to "IOException: Bad record length of
        -174853360 at byte 0x45c9b06c of file." on Solaris AMD64 Server
        VM (machine intelsdv01).

        Update: JMapHeap and JMapPerm were executed in the 2008.03.30
            nightly on machine vm-v20z-5 and did not reproduce this
            failure mode.

        Update: JMapHeap and OnOOMToPath failed in the 2008.07.03
            nightly with this failure mode. In the same run, JMapPerm
            and OnOOMToFile failed due to 6650690.

        Last failure on 2008.07.03 with Solaris AMD64 Server VM (machine intelsdv01)
        Previous failure on 2008.03.29 with Solaris AMD64 Server VM (machine intelsdv01)


http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2008-03-29/Serv_Baseline/vm/solaris-amd64/server/comp/vm-solaris-amd64_server_comp_vm.heapdump.testlist2008-03-29-22-27-49/analysis.html
http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2008-07-03/Serv_Baseline/vm/solaris-amd64/server/comp/vm-solaris-amd64_server_comp_vm.heapdump.testlist2008-07-03-19-44-52/analysis.html
Comments
EVALUATION http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/dd7969318d7a
08-12-2009
EVALUATION Overflow, 32-bit unsigned value treated as signed.
28-11-2007
SUGGESTED FIX When reading length in src/share/classes/com/sun/tools/hat/internal/parser/HprofReader.java: long length = in.readInt() & 0xffffffffL; ..and other adjustments to record current position as a long.
28-11-2007