Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8066871

java.lang.VerifyError: Bad local variable type - local final String

    Details

    • Subcomponent:
    • Resolved In Build:
      b46
    • CPU:
      x86_64
    • OS:
      windows_7
    • Verification:
      Verified

      Backports

        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.

          Issue Links

            Activity

            Hide
            pardesha Pardeep Sharma added a comment -
            This issue is reproducible with JDK 8u25, 8u40 and 9. The test case run fine with JDK 7u72.
            Show
            pardesha Pardeep Sharma added a comment - This issue is reproducible with JDK 8u25, 8u40 and 9. The test case run fine with JDK 7u72.
            Hide
            jlahoda Jan Lahoda added a comment -
            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.
            Show
            jlahoda Jan Lahoda added a comment - 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.
            Hide
            sadayapalam Srikanth Adayapalam added a comment -
            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 ?
            Show
            sadayapalam Srikanth Adayapalam added a comment - 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 ?
            Hide
            sadayapalam Srikanth Adayapalam added a comment -
            Another workaround is to compile with -g
            Show
            sadayapalam Srikanth Adayapalam added a comment - Another workaround is to compile with -g
            Hide
            sadayapalam Srikanth Adayapalam added a comment -
            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..
            Show
            sadayapalam Srikanth Adayapalam added a comment - 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..
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6a927a9114c1
            User: mcimadamore
            Date: 2015-01-09 16:03:43 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6a927a9114c1 User: mcimadamore Date: 2015-01-09 16:03:43 +0000
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/6a927a9114c1
            User: lana
            Date: 2015-01-14 20:48:06 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/6a927a9114c1 User: lana Date: 2015-01-14 20:48:06 +0000

              People

              • Assignee:
                sadayapalam Srikanth Adayapalam
                Reporter:
                webbuggrp Webbug Group
              • Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: