JDK-8164783 : SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2016-08-25
  • Updated: 2018-01-17
  • Resolved: 2016-11-03
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 9
9 b146Fixed
Related Reports
Relates :  
JDK-8015848 - SA: ClassWriter have to support JSR292
Relates :  
JDK-8169232 - SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1
Description
The 'printall' command often throws the following assertion failure. (this is with a slowdebug version).

hsdb> printall
sun.jvm.hotspot.utilities.AssertionFailure: Corrupted constant pool
        at sun.jvm.hotspot.utilities.Assert.that(jdk.hotspot.agent/Assert.java:32)
        at sun.jvm.hotspot.oops.ConstantPool.getFieldOrMethodAt(jdk.hotspot.agent/ConstantPool.java:209
)
        at sun.jvm.hotspot.oops.ConstantPool.getFieldOrMethodKlassRefAt(jdk.hotspot.agent/ConstantPool.
java:336)
        at sun.jvm.hotspot.oops.ConstantPool.getMethodRefAt(jdk.hotspot.agent/ConstantPool.java:343)
        at sun.jvm.hotspot.interpreter.BytecodeInvoke.getInvokedMethod(jdk.hotspot.agent/BytecodeInvoke
.java:73)
        at sun.jvm.hotspot.ui.classbrowser.HTMLGenerator$1.visit(jdk.hotspot.agent/HTMLGenerator.java:6
96)
        at sun.jvm.hotspot.interpreter.BytecodeDisassembler.decode(jdk.hotspot.agent/BytecodeDisassembl
er.java:156)
        at sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTML(jdk.hotspot.agent/HTMLGenerator.java:6
51)
        at sun.jvm.hotspot.CommandProcessor$19$1.visit(jdk.hotspot.agent/CommandProcessor.java:898)
        at sun.jvm.hotspot.memory.SystemDictionary$2.visit(jdk.hotspot.agent/SystemDictionary.java:179)

        at sun.jvm.hotspot.memory.Dictionary.classesDo(jdk.hotspot.agent/Dictionary.java:68)
        at sun.jvm.hotspot.memory.SystemDictionary.classesDo(jdk.hotspot.agent/SystemDictionary.java:19
0)
        at sun.jvm.hotspot.memory.SystemDictionary.allClassesDo(jdk.hotspot.agent/SystemDictionary.java
:183)
        at sun.jvm.hotspot.CommandProcessor$19.doit(jdk.hotspot.agent/CommandProcessor.java:891)
        at sun.jvm.hotspot.CommandProcessor.executeCommand(jdk.hotspot.agent/CommandProcessor.java:1963
)
        at sun.jvm.hotspot.CommandProcessor.executeCommand(jdk.hotspot.agent/CommandProcessor.java:1933
)
        at sun.jvm.hotspot.CommandProcessor.run(jdk.hotspot.agent/CommandProcessor.java:1813)
        at sun.jvm.hotspot.CLHSDB.run(jdk.hotspot.agent/CLHSDB.java:99)
Comments
The failure is seen when we try to print out invokedynamic bytecodes since these are incorrectly handled (for the most part handled like other invoke* bytecodes) while printing out the bytecodes in a method. This is being corrected to give out a 'javap' like output of mentioning the name and method type associated with the invokedynamic bytecode. An example output is as below: Bytecode line bci bytecode 32 0 invokedynamic #2(33) [Name and Type run:()Ljava.lang.Runnable;]
31-10-2016