JDK-8169232 : SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64
  • Submitted: 2016-11-04
  • Updated: 2018-01-17
  • Resolved: 2016-11-23
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 b150Fixed
Related Reports
Relates :  
JDK-8174798 - Mis-merge left serviceability/sa/TestCpoolForInvokeDynamic.java ignored
Relates :  
JDK-8169698 - SA: Check and fix cases of potential data loss due to 'long' to 'int' truncation with calls to minus()
Relates :  
JDK-8164783 - SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure
Sub Tasks
JDK-8169597 :  
Quarantine TestCpoolForInvokeDynamic.java until JDK-8169232 is solved - Resolved
Description
Following is the stack trace from the nightly failure: 

Constant Pool
Constant Pool of [public class LingeredAppWithInvokeDynamic @0x00000007c0060ab0] @0x00007f3433c01090
sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1
	at sun.jvm.hotspot.oops.InstanceKlass.findMethod(jdk.hotspot.agent@9-internal/InstanceKlass.java:1013)
	at sun.jvm.hotspot.oops.InstanceKlass.findMethod(jdk.hotspot.agent@9-internal/InstanceKlass.java:861)
	at sun.jvm.hotspot.oops.ConstantPool.getMethodRefAt(jdk.hotspot.agent@9-internal/ConstantPool.java:347)
	at sun.jvm.hotspot.interpreter.BytecodeInvoke.getInvokedMethod(jdk.hotspot.agent@9-internal/BytecodeInvoke.java:73)
	at sun.jvm.hotspot.ui.classbrowser.HTMLGenerator$1.visit(jdk.hotspot.agent@9-internal/HTMLGenerator.java:699)
	at sun.jvm.hotspot.interpreter.BytecodeDisassembler.decode(jdk.hotspot.agent@9-internal/BytecodeDisassembler.java:156)
	at sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTML(jdk.hotspot.agent@9-internal/HTMLGenerator.java:651)
	at TestCpoolForInvokeDynamic.printBytecodes(TestCpoolForInvokeDynamic.java:83)
	at TestCpoolForInvokeDynamic.main(TestCpoolForInvokeDynamic.java:143)
sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 2
	at sun.jvm.hotspot.oops.InstanceKlass.findMethod(jdk.hotspot.agent@9-internal/InstanceKlass.java:1013)
	at sun.jvm.hotspot.oops.InstanceKlass.findMethod(jdk.hotspot.agent@9-internal/InstanceKlass.java:861)
	at sun.jvm.hotspot.oops.ConstantPool.getMethodRefAt(jdk.hotspot.agent@9-internal/ConstantPool.java:347)
	at sun.jvm.hotspot.interpreter.BytecodeInvoke.getInvokedMethod(jdk.hotspot.agent@9-internal/BytecodeInvoke.java:73)
	at sun.jvm.hotspot.ui.classbrowser.HTMLGenerator$1.visit(jdk.hotspot.agent@9-internal/HTMLGenerator.java:699)
	at sun.jvm.hotspot.interpreter.BytecodeDisassembler.decode(jdk.hotspot.agent@9-internal/BytecodeDisassembler.java:156)
	at sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTML(jdk.hotspot.agent@9-internal/HTMLGenerator.java:651)
	at TestCpoolForInvokeDynamic.printBytecodes(TestCpoolForInvokeDynamic.java:83)
	at TestCpoolForInvokeDynamic.main(TestCpoolForInvokeDynamic.java:143)
Comments
The issue has been observed only on Linux x64. About 800 runs of the test on Linux x64 post the fix proposed above did not cause a test failure. Making changes to unquarantine the test TestCpoolForInvokeDynamic.java also. Created JDK-8169698 to check and deal with other possible data loss issues due to truncation and casts to smaller data types because of calls to the method minus() in platform specific Address classes.
16-11-2016
This test (introduced with JDK-8164783) seems to expose an issue with the binary search used in findMethod() in InstanceKlass.java. One possibility for this issue could be that the "minus()" method in LinuxAddress.java returns a 'long', which gets truncated when cast to an 'int' in the "fastCompare()" method in Symbol.java. 199 public long minus(Address arg) { 200 if (arg == null) { 201 return addr; 202 } 203 return addr - ((LinuxAddress) arg).addr; 204 } ... 142 public int fastCompare(Symbol other) { 143 return (int) addr.minus(other.addr); 144 }
16-11-2016
Changing the following to avoid potential data loss: 1. the return value type for fastCompare to return 'long' 2. the type of the local variable 'res' to 'long' from 'int' This could possibly fix this issue.
16-11-2016
Unable to reproduce the issue even after about 200 runs on my x64 Linux machine. (fastdebug)
10-11-2016
This looks like an integration blocker to me. Was the bug caused by JDK-8164783?
10-11-2016