JDK-8171084 : heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • Submitted: 2016-12-12
  • Updated: 2018-01-17
  • Resolved: 2017-01-30
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 10 JDK 9
10Fixed 9 b157Fixed
Related Reports
Relates :  
JDK-8173053 - SA heapdumper discrepancies
Relates :  
JDK-8176557 - serviceability/sa/TestJmapCore.java fails with java.lang.RuntimeException: Heap segment size overflow.
Relates :  
JDK-8144732 - VM_HeapDumper hits assert with bad dump_len
Description
[2016-12-11T02:11:39.49] /export/home/aginfra/sandbox/results/ResultDir/JMapHeapCore/run.sh: line 30: 47154 Abort                   (core dumped) ${JAVA} ${JAVA_OPTS} heapdump.share.EatMemory -core
[2016-12-11T02:11:39.50] Found core file: core.47154
[2016-12-11T02:11:40.17] Attaching to core core.47154 from executable /export/home/aginfra/CommonData/TEST_JAVA_HOME/bin/java, please wait...
[2016-12-11T02:11:40.72] Debugger attached successfully.
[2016-12-11T02:11:40.72] Server compiler detected.
[2016-12-11T02:11:40.72] JVM version is 9-internal+0-2016-12-09-161408.jesper.dev-hs-merge
[2016-12-11T02:15:01.38] Exception in thread "main" java.lang.RuntimeException: Heap segment size overflow.
[2016-12-11T02:15:01.38] 	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.fillInHeapRecordLength(HeapHprofBinWriter.java:496)
[2016-12-11T02:15:01.38] 	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeHeapRecordEpilogue(HeapHprofBinWriter.java:480)
[2016-12-11T02:15:01.38] 	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.AbstractHeapGraphWriter$1.doObj(AbstractHeapGraphWriter.java:101)
[2016-12-11T02:15:01.38] 	at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterateLiveRegions(ObjectHeap.java:354)
[2016-12-11T02:15:01.38] 	at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterate(ObjectHeap.java:172)
[2016-12-11T02:15:01.38] 	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.AbstractHeapGraphWriter.write(AbstractHeapGraphWriter.java:51)
[2016-12-11T02:15:01.38] 	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:433)
[2016-12-11T02:15:01.38] 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:182)
[2016-12-11T02:15:01.38] 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:97)
[2016-12-11T02:15:01.38] 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260)
[2016-12-11T02:15:01.38] 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:223)
[2016-12-11T02:15:01.38] 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
[2016-12-11T02:15:01.39] 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:176)
[2016-12-11T02:15:01.39] 	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:326)
[2016-12-11T02:15:01.39] 	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:455)
[2016-12-11T02:15:03.76] jmap exited with exit status 1
[2016-12-11T02:15:03.76] TEST FAILED
[2016-12-11T02:16:11.67] # Test level exit status: 1
Comments
The size of the heap dump record is not checked to see if it fits into a 32 bit value while dumping an array. (It is possibly not checked while dumping other records too). In this case, the current size of the record along with the size of the array would exceed 4GB. The solution (similar to that of JDK-8144732) is to create a new record and to truncate the array to fit into the size of a 32 bit value if required. Some other minor changes being done as a part of this fix include: 1. Fixing an incorrect length overflow check for SA_ALTROOT. 2. Modifying SA to also not create heap dumps with HPROF header value 1.0.1 (to be in line with the dumps created by hotspot). 3. Create an extra heap record if needed before writing the thread records so that currentSegmentStart is set correctly before the size of the record is calculated.
02-02-2017
The crash has nothing to do with the failure, the real failure is: [2016-12-11T02:15:01.38] Exception in thread "main" java.lang.RuntimeException: Heap segment size overflow. [2016-12-11T02:15:01.38] at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.fillInHeapRecordLength(HeapHprofBinWriter.java:496) [2016-12-11T02:15:01.38] at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeHeapRecordEpilogue(HeapHprofBinWriter.java:480) [2016-12-11T02:15:01.38] at jdk.hotspot.agent/sun.jvm.hotspot.utilities.AbstractHeapGraphWriter$1.doObj(AbstractHeapGraphWriter.java:101) [2016-12-11T02:15:01.38] at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterateLiveRegions(ObjectHeap.java:354) [2016-12-11T02:15:01.38] at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterate(ObjectHeap.java:172) [2016-12-11T02:15:01.38] at jdk.hotspot.agent/sun.jvm.hotspot.utilities.AbstractHeapGraphWriter.write(AbstractHeapGraphWriter.java:51) [2016-12-11T02:15:01.38] at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:433) [2016-12-11T02:15:01.38] at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:182) [2016-12-11T02:15:01.38] at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:97) [2016-12-11T02:15:01.38] at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) [2016-12-11T02:15:01.38] at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:223) [2016-12-11T02:15:01.38] at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) [2016-12-11T02:15:01.39] at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:176) [2016-12-11T02:15:01.39] at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:326) [2016-12-11T02:15:01.39] at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:455) [2016-12-11T02:15:03.76] jmap exited with exit status 1
12-12-2016
The issue seems to be Solaris specific, all crashes happened on that platform. The stack does not contain compiled code: C [libc.so.1+0xe9a3c] __lwp_wait+0x8;; __lwp_wait+0x8 C [libc.so.1+0xe0c98] _thrp_join+0x44;; _thrp_join+0x44 C [libc.so.1+0xe0e04] thr_join+0x1c;; thr_join+0x1c C [libjli.so+0xaa18] ContinueInNewThread0+0x38;; ContinueInNewThread0+0x38 C [libjli.so+0x8a8c] ContinueInNewThread+0x9c;; ContinueInNewThread+0x9c C [libjli.so+0xaaa4] JVMInit+0x34;; JVMInit+0x34 C [libjli.so+0x469c] JLI_Launch+0x2ac;; JLI_Launch+0x2ac C [java+0xe5c] main+0x15c;; main+0x15c It looks similar to JDK-8150653. The crashes occurred with -Xcomp/-Xmixed/-XX:TieredStopAtLevel=1 and there's no evidence that this is a JIT compiler issue. I'm re-assigning this to serviceability for further investigation because they own the test.
12-12-2016