JDK-8219443 : SA: TestJmapCoreMetaspace.java fails with ZGC
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2019-02-20
  • Updated: 2020-03-11
  • Resolved: 2020-03-11
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
tbdResolved
Related Reports
Duplicate :  
JDK-8219405 - serviceability/sa/TestJmapCore.java failed with java.io.EOFException
Duplicate :  
JDK-8219559 - sa/TestJmapCoreMetaspace.java still fail with ZGC
Relates :  
JDK-8219405 - serviceability/sa/TestJmapCore.java failed with java.io.EOFException
Relates :  
JDK-8219571 - ProblemList serviceability/sa/TestJmapCoreMetaspace.java
Relates :  
JDK-8220624 - SA: Out of sync with ZGC's internal data structures
Sub Tasks
JDK-8240906 :  
Update ZGC ProblemList for serviceability/sa/TestJmapCoreMetaspace.java - Resolved
Description
Recent changes turned on Hprof from the SA agent, in a best-effort to make it work.

 TestJmapCoreMetaspace.java fails when trying to read a hprof file created while running ZGC.
Comments
Hmm. TestJmapCoreMetaspace.java is problem listed under this CR, so either we need to keep it open or update the problem list. Perhaps it's best to just problem list it under JDK-8220624 like all the other SA/ZGC issues.
11-03-2020
Closing as a duplicate of JDK-8219405 since it was also reported without ZGC. Regarding the following failure mode: No suitable match for type of address 0x00007ff5ffd998c0 A new CR should be filed for it if it is still a reproducible. Note we also have JDK-8220624, which is a more general bug for SA being broken with ZGC.
11-03-2020
The exp.getMessage() will return the exception message or 'null' if no message was set. The only time it could return "" is I guess when "" was set as the exception message. I checked the code, I don't see any place where the exception message was set to "" for IOException or RuntimeException.
22-02-2019
I haven't been able to reproduce this exact problem, but I can reproduce the problem with dead classes. When that happens I get the following error message: No suitable match for type of address 0x00007ff5ffd998c0 Which comes from this stack trace: VirtualBaseConstructor<T>.instantiateWrapperFor(Address) line: 109 Metadata.instantiateWrapperFor(Address) line: 74 java_lang_Class.asKlass(Oop) line: 67 HeapHprofBinWriter.writeClass(Instance) line: 613 AbstractHeapGraphWriter$1.doObj(Oop) line: 82 ObjectHeap.iterateLiveRegions(List, HeapVisitor, ObjectHeap$ObjectFilter) line: 284 ObjectHeap.iterate(HeapVisitor) line: 102 HeapHprofBinWriter(AbstractHeapGraphWriter).write() line: 51 HeapHprofBinWriter.write(String) line: 445 JMap.writeHeapHprofBin(String) line: 182 JMap.run() line: 97 JMap(Tool).startInternal() line: 260 JMap(Tool).start(String[]) line: 223 JMap(Tool).execute(String[]) line: 118 JMap.main(String[]) line: 176 SALauncher.runJMAP(String[]) line: 326 SALauncher.main(String[]) line: 455 But the actual stack trace is swallowed because of: public boolean writeHeapHprofBin(String fileName) { try { HeapGraphWriter hgw = new HeapHprofBinWriter(); hgw.write(fileName); System.out.println("heap written to " + fileName); return true; } catch (IOException | RuntimeException exp) { System.err.println(exp.getMessage()); return false; } } I wonder if exp.getMessage() ever returns "", or if we always have a message here?
21-02-2019
Hmm. If this happened because of dead objects in the heap, then that could theoretically also happen with G1. However, JDK-8219405 was reported recently so maybe it's more likely to be one of my recent patches to the SA. I can't see any exception messages from the SA in the test logs. Either the test swallows the exception, or the SA does (or I'm incorrect in assuming that the SA throws an Exception). It would be good see the stack trace from it.
20-02-2019
Is this only expected to fail with ZGC? I'm wondering if JDK-8219405 is the same bug or not, because it happens without ZGC.
20-02-2019
From test run: java.io.EOFException at java.base/java.io.DataInputStream.readInt(DataInputStream.java:397) at jdk.test.lib.hprof.parser.HprofReader.read(HprofReader.java:206) at jdk.test.lib.hprof.parser.Reader.readFile(Reader.java:91) at jdk.test.lib.hprof.HprofParser.parse(HprofParser.java:85) at jdk.test.lib.hprof.HprofParser.parse(HprofParser.java:54) at TestJmapCore.test(TestJmapCore.java:139) at TestJmapCore.main(TestJmapCore.java:73) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298) at java.base/java.lang.Thread.run(Thread.java:835) When failing the jdk.test.lib.hprof.parser.HprofReader.read function has executed: type = in.readUnsignedByte(); ... in.readInt(); // Timestamp of this record ... long length = in.readInt() & 0xffffffffL; And fails with an EOFException at the last line. The type variable is 12, which is HPROF_HEAP_DUMP. This corresponds to the HeapHprofBinWrite.writeHeapRecordPrologue() in the SA. Which is used when printing heap records. We most likely try to print a dead object. It would be good to catch this failure earlier, when the SA fails while printing the heap dump.
20-02-2019