JDK-8087342 : Crash in klassItable::initialize_itable_for_interface when running SelectionResolution InvokeInterfaceICCE.java
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2015-06-12
  • Updated: 2017-11-29
  • Resolved: 2015-08-06
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 8 JDK 9
8u152Fixed 9 b79Fixed
Description
In product mode only, InvokeInterfaceICCE.java crashs in klassItable. This is related to, but not caused by 8067480. Additional improvements like those are needed.

Test case:
interface I1 has abstract m
interface I0 extends I1 private m{}
class C2 implements I0 private m{}

Caller: I0: invokeinterace I0.m C2 objectref
expect: resolution finds I0.m private, throws IncompatibleClassChangeError since you need
to call invokespecial to invoke a private method in an interface.

Fastdebug you get the correct behavior.
In product, we get a SEGV.
Comments
In 8067480 we saw a similar problem. See the detailed analysis there. That example demonstrated a problem with method look up finding both static and overpass methods with the same name/signature and only one gets found. The order of which gets found depends on address order in the symbol table so this can be different between product and fastdebug builds. The fix there was to be explicit in finding methods whether to find a static or an overpass method. This logic is needed both during resolution and during vtable initialization in looking for "miranda methods" which are abstract interface methods that do have an implementation in the current class, so they need to be added to the vtable. In the current example, we have a similar problem with finding methods that are private vs. methods that are overpasses. It is possible to have three entries for a given name/signature pair in a local method list - since we can have static, instance, and overpass methods in the same namespace. So the fix is to extend the explicit lookup concept to be aware of special handling for private methods which need to be skipped in some method searches, such as linkResolution and searches for miranda methods. Private methods in interfaces and sometimes in classes are treated as if they were in their own namespace. So the fix was to add the ability to explicitly skip private methods during a search, and to rewrite the is_miranda code to be simpler because of that.
23-06-2015
Testing fix. When the test works, it throws an IncompatibleClassChangeError, so this is an error condition that should be rare in the field, so fixing in 9.
12-06-2015