JDK-8051012 : Regression in verifier for method call from inside of a branch
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7u65
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64
  • Submitted: 2014-07-17
  • Updated: 2018-11-19
  • Resolved: 2014-08-02
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 7 JDK 8 JDK 9
7u72Fixed 8u20Fixed 9 b28Fixed
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

FULL OS VERSION :
Linux  3.13.0-29-generic #53~precise1-Ubuntu SMP Wed Jun 4 22:06:25 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux


A DESCRIPTION OF THE PROBLEM :
We found the bug with 1.7u65, but it appears also with 1.8u11. 1.7u60 and 1.8u5 don't have the issue. It has been reported by a Groovy user at http://jira.codehaus.org/browse/GROOVY-6951 

The error message is there

Exception in thread "main" java.lang.VerifyError: Bad <init> method call from inside of a branch
Exception Details:
  Location:
    MyGroovyFile.<init>(Ljava/lang/String;)V @93: invokespecial
  Reason:
    Error exists in the bytecode

To be able to make calls to the super constructor for object initialization we have a lookupswitch with the actual invokespecial call in the branch. This seems not to be accepted anymore if stack map frames are activated. 

Disabling the split verifier prevents the error

THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Yes

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes

REGRESSION.  Last worked in version 7u60

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
get Grovy 2.3.4 and execute this program 

public class ConstructorCallA {
    public ConstructorCallA() {
        this(19)               // call another constructor
        println "(1) no argument consructor"
    }

    public ConstructorCallA(String a) {
        println "(2) String value a = $a"
    }

    public ConstructorCallA(int a) {
        this("" + (a*a))       // call another constructor
        println "(3) int value a = $a"
    }
}

println "Testing for a class without call()"
def a1 = new ConstructorCallA("foo")
def a2 = new ConstructorCallA(9)
def a3 = new ConstructorCallA()

by putting it in a text file foo.groovy and execute it with "groovy --indy foo.groovy" (forces the selection of a bytecode level for jdk 1.7 and frames usage)

EXPECTED VERSUS ACTUAL BEHAVIOR :
expected output:

Testing for a class without call()
(2) String value a = foo
(2) String value a = 81
(3) int value a = 9
(2) String value a = 361
(3) int value a = 19
(1) no argument consructor

actual:

fails with VerifyError
ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.VerifyError: Bad <init> method call from inside of a branch
Exception Details:
  Location:
    ConstructorCallA.<init>(I)V @76: invokespecial
  Reason:
    Error exists in the bytecode
  Bytecode:
    0000000: 04bd 0004 5903 125b 1b1b ba00 6800 00ba
    0000010: 006d 0000 5359 10ff 1202 b800 1e2a 5fab
    0000020: 0000 004c 0000 0003 aad3 b1ff 0000 0021
    0000030: 0000 9b75 0000 0033 0013 462e 0000 003c
    0000040: 5f5a 5903 32ba 002c 0000 5f57 b700 2fa7
    0000050: 0026 5f5a 57b7 0031 a700 1d5f 5a59 0332
    0000060: b800 375f 57b7 003a a700 0dbb 003c 5912
    0000070: 3eb7 003f bf57 2abb 0055 5904 bd00 0459
    0000080: 031b b800 1853 05bd 0057 5903 126f 5359
    0000090: 0412 5b53 b700 5eba 0061 0000 57b1     
  Stackmap Table:
    full_frame(@64,{UninitializedThis,Integer},{Object[#76],UninitializedThis})
    full_frame(@82,{UninitializedThis,Integer},{Object[#76],UninitializedThis})
    full_frame(@91,{UninitializedThis,Integer},{Object[#76],UninitializedThis})
    full_frame(@107,{UninitializedThis,Integer},{Object[#76],UninitializedThis})
    full_frame(@117,{Object[#2],Integer},{Object[#76]})

java.lang.VerifyError: Bad <init> method call from inside of a branch
Exception Details:
  Location:
    ConstructorCallA.<init>(I)V @76: invokespecial
  Reason:
    Error exists in the bytecode
  Bytecode:
    0000000: 04bd 0004 5903 125b 1b1b ba00 6800 00ba
    0000010: 006d 0000 5359 10ff 1202 b800 1e2a 5fab
    0000020: 0000 004c 0000 0003 aad3 b1ff 0000 0021
    0000030: 0000 9b75 0000 0033 0013 462e 0000 003c
    0000040: 5f5a 5903 32ba 002c 0000 5f57 b700 2fa7
    0000050: 0026 5f5a 57b7 0031 a700 1d5f 5a59 0332
    0000060: b800 375f 57b7 003a a700 0dbb 003c 5912
    0000070: 3eb7 003f bf57 2abb 0055 5904 bd00 0459
    0000080: 031b b800 1853 05bd 0057 5903 126f 5359
    0000090: 0412 5b53 b700 5eba 0061 0000 57b1     
  Stackmap Table:
    full_frame(@64,{UninitializedThis,Integer},{Object[#76],UninitializedThis})
    full_frame(@82,{UninitializedThis,Integer},{Object[#76],UninitializedThis})
    full_frame(@91,{UninitializedThis,Integer},{Object[#76],UninitializedThis})
    full_frame(@107,{UninitializedThis,Integer},{Object[#76],UninitializedThis})
    full_frame(@117,{Object[#2],Integer},{Object[#76]})

	at java.lang.Class.getDeclaredConstructors0(Native Method)
	at java.lang.Class.privateGetDeclaredConstructors(Class.java:2532)
	at java.lang.Class.getDeclaredConstructors(Class.java:1901)
	at org.codehaus.groovy.reflection.CachedClass$2$1.run(CachedClass.java:69)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.codehaus.groovy.reflection.CachedClass$2.initValue(CachedClass.java:66)
	at org.codehaus.groovy.reflection.CachedClass$2.initValue(CachedClass.java:64)
	at org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:46)
	at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:33)
	at org.codehaus.groovy.reflection.CachedClass.getConstructors(CachedClass.java:263)
	at groovy.lang.MetaClassImpl.<init>(MetaClassImpl.java:190)
	at groovy.lang.MetaClassImpl.<init>(MetaClassImpl.java:194)
	at groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createNormalMetaClass(MetaClassRegistry.java:158)
	at groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createWithCustomLookup(MetaClassRegistry.java:148)
	at groovy.lang.MetaClassRegistry$MetaClassCreationHandle.create(MetaClassRegistry.java:131)
	at org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:238)
	at org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:270)
	at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.getMetaClass(MetaClassRegistryImpl.java:255)
	at org.codehaus.groovy.vmplugin.v7.Selector$InitSelector.getMetaClass(Selector.java:360)
	at org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.setCallSiteTarget(Selector.java:942)
	at org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:211)
	at test.run(test.groovy:1867)
	at groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:258)
	at groovy.lang.GroovyShell.run(GroovyShell.java:502)
	at groovy.lang.GroovyShell.run(GroovyShell.java:491)
	at groovy.ui.GroovyMain.processOnce(GroovyMain.java:650)
	at groovy.ui.GroovyMain.run(GroovyMain.java:381)
	at groovy.ui.GroovyMain.process(GroovyMain.java:367)
	at groovy.ui.GroovyMain.processArgs(GroovyMain.java:126)
	at groovy.ui.GroovyMain.main(GroovyMain.java:106)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
In JDK7 the splitverifier can be disabled, but for JDK8 this is not possible anymore. Otherwise the bytecodelevel must be set low enough to not use stack map frames. If invokedynamic is supposed to be used on JDK8, there is no workaround


Comments
Based on the info above and 8u40 vm nightly results SQE OK to take the fix in PSU14_04
06-08-2014

Critical Request Template - Fix for Release : 7 PSU, 8 - Justification : The bug affected multiple third party vendors who have raised escalations for this to get fixed. - Risk Analysis : The risk is low. The change only affects programs that get verified. There is a slight chance that it may break a few existing illegal programs because it changes verifier stackmap matching for branches. This change was necessary for security reasons. The fix was tested on 8u and 7u with JCK lang, vm, and api/java_lang tests, jtreg hotspot tests, and ute quck tests on JDK 8. Also, the fix was checked into JDK-9 on 2-Aug. Nightly testing has not found problems. - Webrev : See hg changesets above - Testing (done/to-be-done) : Automated test part of the push - Back ports (done/to-be-done) : Fix is already backported to 8u and 7u - FX Impact : -
06-08-2014

The justification for the critical request is that the bug affected multiple third party vendors who have raised escalations for this to get fixed.
06-08-2014

What is a justification for the critical request?
06-08-2014

The corresponding JAssist issue for the PowerMock issue: https://issues.jboss.org/browse/JASSIST-228
05-08-2014

Potentially related PowerMock issue: https://code.google.com/p/powermock/issues/detail?id=505 , presumably related to the issue Winston is seeing above.
05-08-2014

When I use JDK 1.8 U11, several of my test cases that uses EasyMock/PowerMock are broken. JDK 1.8 U5 works fine testIsAuthorFalse(org.eclipse.hudson.FunctionsTest) Time elapsed: 0.07 sec <<< ERROR! java.lang.VerifyError: Bad <init> method call from inside of a branch Exception Details: Location: org/eclipse/hudson/model/User.<init>(Ljava/lang/String;Ljava/lang/String;)V @36: invokespecial Reason: Error exists in the bytecode Bytecode: 0000000: 2a4e 1300 1db8 0023 03bd 0018 1300 25b8 0000010: 0029 b800 2f3a 0519 05b2 0033 a500 0e2a 0000020: 01c0 0035 b700 38a7 0009 2db7 003a 0157 0000030: 2a00 0000 0001 4e01 3a04 1300 3cb8 003f 0000040: 03bd 0018 1300 41b8 0029 b800 443a 0519 0000050: 05b2 0033 a500 3419 05c1 0046 9900 22b8 0000060: 004c 1300 3cb8 003f 1300 1801 b600 52b6 0000070: 0056 01b6 005a c000 1a3a 04a7 000a 1905 0000080: c000 1a3a 04a7 000c bb00 1a59 b700 5b3a 0000090: 0419 04b5 005f 2a2b b500 612a 2cb5 0063 00000a0: 2ab7 0066 b1 Stackmap Table: full_frame(@42,{UninitializedThis,Object[#22],Object[#22],UninitializedThis,Top,Object[#24]},{}) full_frame(@48,{Object[#2],Object[#22],Object[#22],Object[#2],Top,Object[#24]},{}) full_frame(@126,{Object[#2],Object[#22],Object[#22],Null,Null,Object[#24]},{Object[#2]}) full_frame(@133,{Object[#2],Object[#22],Object[#22],Null,Object[#26],Object[#24]},{Object[#2]}) full_frame(@136,{Object[#2],Object[#22],Object[#22],Null,Null,Object[#24]},{Object[#2]}) full_frame(@145,{Object[#2],Object[#22],Object[#22],Null,Object[#26],Object[#24]},{Object[#2]}) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2688) at java.lang.Class.getMethod0(Class.java:2937) at java.lang.Class.getMethod(Class.java:1771) at org.easymock.internal.ObjectMethodsFilter.extractMethod(ObjectMethodsFilter.java:72) at org.easymock.internal.ObjectMethodsFilter.<init>(ObjectMethodsFilter.java:56) at org.easymock.internal.MocksControl.createMock(MocksControl.java:114) at org.easymock.internal.MocksControl.createMock(MocksControl.java:88) at org.easymock.internal.MocksControl.createMock(MocksControl.java:79) at org.powermock.api.easymock.PowerMock.doCreateMock(PowerMock.java:2212) at org.powermock.api.easymock.PowerMock.doMock(PowerMock.java:2163) at org.powermock.api.easymock.PowerMock.mockStatic(PowerMock.java:287) at org.eclipse.hudson.FunctionsTest.testIsAuthorFalse(FunctionsTest.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:68) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:310) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:88) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:96) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.executeTest(PowerMockJUnit44RunnerDelegateImpl.java:294) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTestInSuper(PowerMockJUnit47RunnerDelegateImpl.java:127) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTest(PowerMockJUnit47RunnerDelegateImpl.java:82) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runBeforesThenTestThenAfters(PowerMockJUnit44RunnerDelegateImpl.java:282) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:86) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.invokeTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:207) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.runMethods(PowerMockJUnit44RunnerDelegateImpl.java:146) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$1.run(PowerMockJUnit44RunnerDelegateImpl.java:120) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:33) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:45) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.run(PowerMockJUnit44RunnerDelegateImpl.java:118) at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.run(JUnit4TestSuiteChunkerImpl.java:104) at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.run(AbstractCommonPowerMockRunner.java:53) at org.powermock.modules.junit4.PowerMockRunner.run(PowerMockRunner.java:53) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:119) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:101) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) at com.sun.proxy.$Proxy0.invoke(Unknown Source) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:74) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
25-07-2014

Attached ConstructorCallA.class contributed by Jochen Theodorou
21-07-2014

If possible, could you provide us with a class file containing the constructor that calls super() from inside a lookupswitch branch?
17-07-2014

This issue is similar to JDK-8050485 but is not a duplicate. JDK-8050485 concerns calling super() from inside of a TRY block. This issue concerns calling super() from inside of a branch. The checks for these are done differently in the split verifier.
17-07-2014