JDK-8174994 : SA: clhsdb printmdo throws WrongTypeException when attached to a process with CDS
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 9,10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2017-02-15
  • Updated: 2020-03-18
  • Resolved: 2018-04-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.
JDK 11
11 b12Fixed
Related Reports
Relates :  
JDK-8241158 - SA TestHeapDumpForInvokeDynamic.java fails when CDS archive is relocated
Relates :  
JDK-8202297 - SA: Test: Consolidate the corefile debugging components of ClhsdbCDSCore.java and TestSAServer.java
Relates :  
JDK-8200162 - Use coredump_filter to dump the MAP_SHARED regions of a CDS archive into a corefile
Relates :  
JDK-8201789 - SA: Consolidate the platform specific libsaproc files
Description
/home/jini/jdk10/hs/build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java  -Xshare:on -cp ~/tests/ HelloAndLoop
Hello -- and Loop
...after attaching to the process through jhsdb
hsdb> printmdo -a
Error: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000000800a34e80
Comments
This also includes a fix for a latent bug on MacOSX, where corefile debugging was failing due to SA trying to read in the incorrect mangled symbol name for "Arguments::SharedArchivePath". Clang seems to have prefixed an extra '_' to change the mangled name from '_ZN9Arguments17SharedArchivePathE' to '__ZN9Arguments17SharedArchivePathE' for MachO files. This fix for this is in src/jdk.hotspot.agent/macosx/native/libsaproc/ps_core.c.
26-04-2018
Ioi, yes. But we might want to also first explore if we have a better solution (JDK-8200162). If the coredump filter mechanism does not work, then we can fallback to #including FileMapheader in both the places.
26-03-2018
Should we move the (common parts of) FileMapHeader to a common include file to be shared between hotspot and SA?
23-03-2018
Some additional modifications are needed to fix this with corefiles. The FileMapHeader structure (from src/hotspot/share/memory/filemap.hpp), which is replicated in SA in ps_core.c, is out of sync with the corresponding definition in src/hotspot/share/memory/filemap.hpp. Fixing this too.
23-03-2018
Making changes to read in the md region (consisting of the c++ vtables) of the CDS archive in SA, and mapping the vtable addresses to the corresponding metadata type (ConstantPool, InstanceKlass, InstanceClassLoaderKlass, InstanceMirrorKlass, InstanceRefKlass, Method, ObjArrayKlass, TypeArrayKlass). This fixes the 'sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address' issue. Now, after fixing this, the following issue (the same as the one in JDK-8174995) is seen: Constant Pool Constant Pool of [class HelloAndLoop @0x0000000840060040] @0x00007f99d9548068 sun.jvm.hotspot.utilities.AssertionFailure: illegal code 236 at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) at jdk.hotspot.agent/sun.jvm.hotspot.interpreter.Bytecodes.check(Bytecodes.java:338) at jdk.hotspot.agent/sun.jvm.hotspot.interpreter.Bytecodes.javaCode(Bytecodes.java:380) at jdk.hotspot.agent/sun.jvm.hotspot.interpreter.BytecodeStream.next(BytecodeStream.java:78) at jdk.hotspot.agent/sun.jvm.hotspot.interpreter.BytecodeDisassembler.decode(BytecodeDisassembler.java:11 at jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTML(HTMLGenerator.java:659) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$19$1.visit(CommandProcessor.java:901) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.classesDo(ClassLoaderData.java:102) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderDataGraph.classesDo(ClassLoaderDataGraph.java:8 at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$19.doit(CommandProcessor.java:894) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1983) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1953) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1833) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:191) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:439) sun.jvm.hotspot.utilities.AssertionFailure: Failure occurred at bci 0 in method java.lang.Void.<init>() at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) at jdk.hotspot.agent/sun.jvm.hotspot.interpreter.BytecodeStream.next(BytecodeStream.java:81) at jdk.hotspot.agent/sun.jvm.hotspot.interpreter.BytecodeDisassembler.decode(BytecodeDisassembler.java:11 at jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTML(HTMLGenerator.java:659) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$19$1.visit(CommandProcessor.java:901) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.classesDo(ClassLoaderData.java:102) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderDataGraph.classesDo(ClassLoaderDataGraph.java:8 at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$19.doit(CommandProcessor.java:894) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1983) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1953) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1833) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:191)
21-03-2018
With printall, Constant Pool Constant Pool of [class HelloAndLoop @0x0000000840060030] @0x00007fa46c7df058 sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000000800411f70 at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:109) at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:73) at jdk.hotspot.agent/sun.jvm.hotspot.utilities.KlassArray.getAt(KlassArray.java:62) at jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.getKlassAt(ConstantPool.java:329) at jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.getFieldOrMethodKlassRefAt(ConstantPool.java:345) at jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.getFieldRefAt(ConstantPool.java:363) at jdk.hotspot.agent/sun.jvm.hotspot.interpreter.BytecodeGetPut.getField(BytecodeGetPut.java:50) at jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator$1.visit(HTMLGenerator.java:719) at jdk.hotspot.agent/sun.jvm.hotspot.interpreter.BytecodeDisassembler.decode(BytecodeDisassembler.java:156) at jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTML(HTMLGenerator.java:659) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$19$1.visit(CommandProcessor.java:899) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.classesDo(ClassLoaderData.java:102) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderDataGraph.classesDo(ClassLoaderDataGraph.java:84) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$19.doit(CommandProcessor.java:892) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1966) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1936) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1816) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:191) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:439) sun.jvm.hotspot.types.WrongTypeException : No suitable match for type of address 0x0000000800411f70 Error: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000000800260508 ==================================================================== When an SA process deals with a process with Xshare:on, it throws the WrongTypeException with various clhsdb commands. The reason is that many times, SA tries to map an address to a hotspot C++ type by comparing the vtable address to the vtable address values of known types. With CDS, since the vtables are copied over for the Metadata classes, the vtable addresses themselves don't match (though of course, the contents will), and SA errors out. ===================================================================
22-02-2018
Issue observed with scanoops also when attached to a process with CDS
14-02-2018