JDK-8066871 : java.lang.VerifyError: Bad local variable type - local final String
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8u25
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2014-12-08
  • Updated: 2016-09-12
  • Resolved: 2015-01-09
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
8u102Fixed 9 b46Fixed
Related Reports
Duplicate :  
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Windows 7 64bit (Microsoft Windows [6.1.7601])

A DESCRIPTION OF THE PROBLEM :
After migration to java 1.8u25, it's impossible to run method containing local final String, used on setter method of some other class. Result of running such code is: "java.lang.VerifyError: Bad local variable type"

REGRESSION.  Last worked in version 7u72

ADDITIONAL REGRESSION INFORMATION: 
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compiling and running attached code ends with error.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Successful execution.
ACTUAL -
Error.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.VerifyError: Bad local variable type
Exception Details:
  Location:
    FinalLocalStringUsedInSetter.test()V @9: aload_1
  Reason:
    Type top (current frame, locals[1]) is not assignable to reference type
  Current Frame:
    bci: @9
    flags: { }
    locals: { 'FinalLocalStringUsedInSetter', top, top, 'FinalLocalStringUsedInSetter$Tmp' }
    stack: { 'FinalLocalStringUsedInSetter$Tmp' }
  Bytecode:
    0x0000000: bb00 0259 b700 034e 2d2b b600 04b1

        at java.lang.Class.getDeclaredMethods0(Native Method)
        at java.lang.Class.privateGetDeclaredMethods(Class.java:2693)
        at java.lang.Class.privateGetMethodRecursive(Class.java:3040)
        at java.lang.Class.getMethod0(Class.java:3010)
        at java.lang.Class.getMethod(Class.java:1776)
        at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
        at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
[Loaded java.lang.Shutdown from c:\Program Files\Java\jdk1.8.0_25\jre\lib\rt.jar]
[Loaded java.lang.Shutdown$Lock from c:\Program Files\Java\jdk1.8.0_25\jre\lib\rt.jar]


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class FinalLocalStringUsedInSetter {

	static class Tmp {

		private String value;

		public void setValue(String tmpStr) {
			this.value = tmpStr;
		}

	}

	public void test() {

		final String y = "Y";
		final String n = "N";

		Tmp tmp = new Tmp();
		tmp.setValue(true ? y : n);

	}

	public static void main(String[] args) {
		new FinalLocalStringUsedInSetter().test();
	}

}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Remove "final" from local variables.


Comments
As an experiment, I got rid of the call to baseType() - I don't see any impact in jtreg + jck tests. It is not clear to me what motivates this call - The method U() and capture operation must are idempotent with respect to constants as there are no type variable constants or parameterized type constants. So the question is only whether not reaching for the underlying type can have an effect inside the super.check call. This looks unlikely to me, though given my limited exposure to the code base at the moment, this is hard to say for sure. I don't know hg well enough yet to do time travel/archaeology using hg bisect to see exactly why/when this call was introduced. I'll propose two patches one eliminating this call altogether and another retaining this call but making sure the constness of the tree is not allowed to evaporate and we can discuss how to take it forward..
31-12-2014

Another workaround is to compile with -g
31-12-2014

Jan, I am looking for some interesting tickets to work on. If you don't mind I can take over this one and perhaps you can review the patch ?
30-12-2014

The constant info for "y" and "n" in the conditional expression appears to be lost in Resolve.MethodResultInfo.check, by calling Type.baseType(). The current proposal is to store the constant info and restore it at the end of this method.
17-12-2014

This issue is reproducible with JDK 8u25, 8u40 and 9. The test case run fine with JDK 7u72.
08-12-2014