Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-30665

JDK 7 (or above) compiled classes cannot be used with Jenkins 1.601 and above

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Duplicate
    • Component/s: core
    • Labels:
    • Environment:
    • Similar Issues:

      Description

      I'm one of the developers for the Lucene plugin. As Lucene libraries are compiled using java 7 (since java 6 is deprecated) this bug causes all releases above 1.600 to be broken for us.

      Some history: in JDK 7 a new "feature" introduced was that the compiler has to keep a stack map. Any code compiled for java 1.6 is run in a compatibility mode, but all code compiled with target 1.7 needs to have this. More can be read here: http://chrononsystems.com/blog/java-7-design-flaw-leads-to-huge-backward-step-for-the-jvm

      What happens is that for some reason, that stack map becomes either corrupt or removed after applying commit https://github.com/jenkinsci/jenkins/commit/89681c20296c5f1c134039d2e24d434e1992437b causing java.lang.VerifyErrors (attached full stack, but excerpt below).

      Just to be clear. This has NOTHING to do with compiling jenkins with java 7. I have not tried that. I'm only interested in how the official builds interact with plugins requiring java 7 (it's because our required dependencies are only compiled for java 7).

      Reproduce:
      I have bisected by
      1) Added the lucene search plugin through normal plugin download
      2) Added a job
      3) Ran it
      4) Search for "user" or something else that is in the build log. Either I see the stack(bad) or the found jobs(good). I actually bisected the patch with the script "test.sh" attached, but it's clearly visible in both console and browser.

      This has been reproduced on other hosts and other jdk's as well.

      Caused by: java.lang.VerifyError: Expecting a stackmap frame at branch target 25
      Exception Details:
      Location:
      org/apache/lucene/util/packed/PackedInts$Format.longCount(III)I @3: ifne
      Reason:
      Expected stackmap frame at this location.
      Bytecode:
      0000000: b200 5e9a 0016 1d9b 0009 1d10 40a4 000c
      0000010: bb00 6059 1db7 0063 bf2a 1b1c 1db6 006e
      0000020: 3704 b200 5e9a 0014 1604 1400 6f94 9b00
      0000030: 0bbb 0060 59b7 0071 bf16 0414 0064 7109
      0000040: 949a 000b 1604 1400 646d 88ac 1604 1400
      0000050: 646d 0a61 88ac

        Attachments

          Issue Links

            Activity

            tobias_ Tobias Olsson created issue -
            tobias_ Tobias Olsson made changes -
            Field Original Value New Value
            Description I'm one of the developers for the Lucene plugin. As Lucene libraries are compiled using java 7 (since java 6 is deprecated) this bug causes all releases above 1.600 to be broken for us.

            Some history: in JDK 7 a new "feature" introduced was that the compiler has to keep a stack map. Any code compiled for java 1.6 is run in a compatibility mode, but all code compiled with target 1.7 needs to have this. More can be read here: [http://chrononsystems.com/blog/java-7-design-flaw-leads-to-huge-backward-step-for-the-jvm]

            What happens is that for some reason, that stack map becomes either corrupt or removed after applying commit [https://github.com/jenkinsci/jenkins/commit/89681c20296c5f1c134039d2e24d434e1992437b ] causing java.lang.VerifyErrors (attached full stack, but excerpt below). I do not understand how any of that code can cause a problem, yet it does.

            Just to be clear. This has NOTHING to do with compiling jenkins with java 7. I have not tried that. I'm only interested in how the official builds interact with plugins requiring java 7 (it's because our required dependencies are only compiled for java 7).

            Reproduce:
            I have bisected by
            1) Added the lucene search plugin through normal plugin download
            2) Added a job
            3) Ran it
            4) Search for "user" or something else that is in the build log. Either I see the stack(bad) or the found jobs(good). I actually bisected the patch with the script "test.sh" attached, but it's clearly visible in both console and browser.

            This has been reproduced on other hosts and other jdk's as well.


            Caused by: java.lang.VerifyError: Expecting a stackmap frame at branch target 25
            Exception Details:
              Location:
                org/apache/lucene/util/packed/PackedInts$Format.longCount(III)I @3: ifne
              Reason:
                Expected stackmap frame at this location.
              Bytecode:
                0000000: b200 5e9a 0016 1d9b 0009 1d10 40a4 000c
                0000010: bb00 6059 1db7 0063 bf2a 1b1c 1db6 006e
                0000020: 3704 b200 5e9a 0014 1604 1400 6f94 9b00
                0000030: 0bbb 0060 59b7 0071 bf16 0414 0064 7109
                0000040: 949a 000b 1604 1400 646d 88ac 1604 1400
                0000050: 646d 0a61 88ac
            I'm one of the developers for the Lucene plugin. As Lucene libraries are compiled using java 7 (since java 6 is deprecated) this bug causes all releases above 1.600 to be broken for us.

            Some history: in JDK 7 a new "feature" introduced was that the compiler has to keep a stack map. Any code compiled for java 1.6 is run in a compatibility mode, but all code compiled with target 1.7 needs to have this. More can be read here: [http://chrononsystems.com/blog/java-7-design-flaw-leads-to-huge-backward-step-for-the-jvm]

            What happens is that for some reason, that stack map becomes either corrupt or removed after applying commit [https://github.com/jenkinsci/jenkins/commit/89681c20296c5f1c134039d2e24d434e1992437b ] causing java.lang.VerifyErrors (attached full stack, but excerpt below).- I do not understand how any of that code can cause a problem, yet it does.-

            Just to be clear. This has NOTHING to do with compiling jenkins with java 7. I have not tried that. I'm only interested in how the official builds interact with plugins requiring java 7 (it's because our required dependencies are only compiled for java 7).

            Reproduce:
            I have bisected by
            1) Added the lucene search plugin through normal plugin download
            2) Added a job
            3) Ran it
            4) Search for "user" or something else that is in the build log. Either I see the stack(bad) or the found jobs(good). I actually bisected the patch with the script "test.sh" attached, but it's clearly visible in both console and browser.

            This has been reproduced on other hosts and other jdk's as well.


            Caused by: java.lang.VerifyError: Expecting a stackmap frame at branch target 25
            Exception Details:
              Location:
                org/apache/lucene/util/packed/PackedInts$Format.longCount(III)I @3: ifne
              Reason:
                Expected stackmap frame at this location.
              Bytecode:
                0000000: b200 5e9a 0016 1d9b 0009 1d10 40a4 000c
                0000010: bb00 6059 1db7 0063 bf2a 1b1c 1db6 006e
                0000020: 3704 b200 5e9a 0014 1604 1400 6f94 9b00
                0000030: 0bbb 0060 59b7 0071 bf16 0414 0064 7109
                0000040: 949a 000b 1604 1400 646d 88ac 1604 1400
                0000050: 646d 0a61 88ac
            Hide
            tobias_ Tobias Olsson added a comment -

            The problem is the @AdaptField which seems to be broken. Removing that annotation makes everything work as it should.

            Show
            tobias_ Tobias Olsson added a comment - The problem is the @AdaptField which seems to be broken. Removing that annotation makes everything work as it should.
            tobias_ Tobias Olsson made changes -
            Description I'm one of the developers for the Lucene plugin. As Lucene libraries are compiled using java 7 (since java 6 is deprecated) this bug causes all releases above 1.600 to be broken for us.

            Some history: in JDK 7 a new "feature" introduced was that the compiler has to keep a stack map. Any code compiled for java 1.6 is run in a compatibility mode, but all code compiled with target 1.7 needs to have this. More can be read here: [http://chrononsystems.com/blog/java-7-design-flaw-leads-to-huge-backward-step-for-the-jvm]

            What happens is that for some reason, that stack map becomes either corrupt or removed after applying commit [https://github.com/jenkinsci/jenkins/commit/89681c20296c5f1c134039d2e24d434e1992437b ] causing java.lang.VerifyErrors (attached full stack, but excerpt below).- I do not understand how any of that code can cause a problem, yet it does.-

            Just to be clear. This has NOTHING to do with compiling jenkins with java 7. I have not tried that. I'm only interested in how the official builds interact with plugins requiring java 7 (it's because our required dependencies are only compiled for java 7).

            Reproduce:
            I have bisected by
            1) Added the lucene search plugin through normal plugin download
            2) Added a job
            3) Ran it
            4) Search for "user" or something else that is in the build log. Either I see the stack(bad) or the found jobs(good). I actually bisected the patch with the script "test.sh" attached, but it's clearly visible in both console and browser.

            This has been reproduced on other hosts and other jdk's as well.


            Caused by: java.lang.VerifyError: Expecting a stackmap frame at branch target 25
            Exception Details:
              Location:
                org/apache/lucene/util/packed/PackedInts$Format.longCount(III)I @3: ifne
              Reason:
                Expected stackmap frame at this location.
              Bytecode:
                0000000: b200 5e9a 0016 1d9b 0009 1d10 40a4 000c
                0000010: bb00 6059 1db7 0063 bf2a 1b1c 1db6 006e
                0000020: 3704 b200 5e9a 0014 1604 1400 6f94 9b00
                0000030: 0bbb 0060 59b7 0071 bf16 0414 0064 7109
                0000040: 949a 000b 1604 1400 646d 88ac 1604 1400
                0000050: 646d 0a61 88ac
            I'm one of the developers for the Lucene plugin. As Lucene libraries are compiled using java 7 (since java 6 is deprecated) this bug causes all releases above 1.600 to be broken for us.

            Some history: in JDK 7 a new "feature" introduced was that the compiler has to keep a stack map. Any code compiled for java 1.6 is run in a compatibility mode, but all code compiled with target 1.7 needs to have this. More can be read here: [http://chrononsystems.com/blog/java-7-design-flaw-leads-to-huge-backward-step-for-the-jvm]

            What happens is that for some reason, that stack map becomes either corrupt or removed after applying commit [https://github.com/jenkinsci/jenkins/commit/89681c20296c5f1c134039d2e24d434e1992437b ] causing java.lang.VerifyErrors (attached full stack, but excerpt below).

            Just to be clear. This has NOTHING to do with compiling jenkins with java 7. I have not tried that. I'm only interested in how the official builds interact with plugins requiring java 7 (it's because our required dependencies are only compiled for java 7).

            Reproduce:
            I have bisected by
            1) Added the lucene search plugin through normal plugin download
            2) Added a job
            3) Ran it
            4) Search for "user" or something else that is in the build log. Either I see the stack(bad) or the found jobs(good). I actually bisected the patch with the script "test.sh" attached, but it's clearly visible in both console and browser.

            This has been reproduced on other hosts and other jdk's as well.


            Caused by: java.lang.VerifyError: Expecting a stackmap frame at branch target 25
            Exception Details:
              Location:
                org/apache/lucene/util/packed/PackedInts$Format.longCount(III)I @3: ifne
              Reason:
                Expected stackmap frame at this location.
              Bytecode:
                0000000: b200 5e9a 0016 1d9b 0009 1d10 40a4 000c
                0000010: bb00 6059 1db7 0063 bf2a 1b1c 1db6 006e
                0000020: 3704 b200 5e9a 0014 1604 1400 6f94 9b00
                0000030: 0bbb 0060 59b7 0071 bf16 0414 0064 7109
                0000040: 949a 000b 1604 1400 646d 88ac 1604 1400
                0000050: 646d 0a61 88ac
            hanabishi Marcus Jacobsson made changes -
            Assignee Kohsuke Kawaguchi [ kohsuke ]
            Hide
            jglick Jesse Glick added a comment -

            Probably JENKINS-28781.

            Show
            jglick Jesse Glick added a comment - Probably JENKINS-28781 .
            jglick Jesse Glick made changes -
            Link This issue duplicates JENKINS-28781 [ JENKINS-28781 ]
            jglick Jesse Glick made changes -
            Resolution Duplicate [ 3 ]
            Status Open [ 1 ] Resolved [ 5 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 165781 ] JNJira + In-Review [ 197813 ]

              People

              Assignee:
              kohsuke Kohsuke Kawaguchi
              Reporter:
              tobias_ Tobias Olsson
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: