java.lang.VerifyError: การคาดหวังเฟรมสแต็กแมปที่เป้าหมายสาขา JDK 1.7

88

หลังจากอัปเกรดเป็น JDK 1.7 ฉันได้รับข้อยกเว้นด้านล่าง:

java.lang.VerifyError: Expecting a stackmap frame at branch target 71 in method com.abc.domain.myPackage.MyClass$JaxbAccessorM_getDescription_setDescription_java_lang_String.get(Ljava/lang/Object;)Ljava/lang/Object; at offset 20
    at java.lang.Class.getDeclaredConstructors0(Native Method)
    at java.lang.Class.privateGetDeclaredConstructors(Class.java:2413)
    at java.lang.Class.getConstructor0(Class.java:2723)
    at java.lang.Class.newInstance0(Class.java:345)
    at java.lang.Class.newInstance(Class.java:327)
    at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.instanciate(OptimizedAccessorFactory.java:184)
    at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:129)
    at com.sun.xml.internal.bind.v2.runtime.reflect.Accessor$GetterSetterReflection.optimize(Accessor.java:384)
    at com.sun.xml.internal.bind.v2.runtime.property.SingleElementLeafProperty.<init>(SingleElementLeafProperty.java:72)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
    at com.sun.xml.internal.bind.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:113)
    at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.<init>(ClassBeanInfoImpl.java:166)
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:494)
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:311)
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:126)
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1148)
    at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:130)
    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:601)
    at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:248)
    at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:235)
    at javax.xml.bind.ContextFinder.find(ContextFinder.java:445)
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:637)
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:584)
    at com.abc.domain.myPackage.MyClass.marshalFacetsTest(MyClass.java:73)
    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:601)
    at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
    at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
    at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
    at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
    at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:128)
    at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
    at org.testng.TestRunner.privateRun(TestRunner.java:767)
    at org.testng.TestRunner.run(TestRunner.java:617)
    at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
    at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
    at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
    at org.testng.SuiteRunner.run(SuiteRunner.java:240)
    at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
    at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
    at org.testng.TestNG.runSuitesSequentially(TestNG.java:1203)
    at org.testng.TestNG.runSuitesLocally(TestNG.java:1128)
    at org.testng.TestNG.run(TestNG.java:1036)
    at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
    at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
    at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
java  jaxb  java-7 
— จอห์น
แหล่งที่มา

คำตอบ:

171

Java 7 แนะนำการตรวจสอบที่เข้มงวดขึ้นและเปลี่ยนรูปแบบคลาสเล็กน้อยเพื่อให้มีสแต็กแม็พที่ใช้ในการตรวจสอบว่าโค้ดถูกต้อง ข้อยกเว้นที่คุณเห็นหมายความว่าบางวิธีไม่มีสแต็กแม็พที่ถูกต้อง

เวอร์ชัน Java หรือเครื่องมือวัด bytecode อาจเป็นโทษได้ โดยปกติหมายความว่าไลบรารีที่แอปพลิเคชันใช้สร้าง bytecode ที่ไม่ถูกต้องซึ่งไม่ผ่านการตรวจสอบที่เข้มงวดขึ้น ดังนั้นไม่มีอะไรอื่นนอกจากรายงานว่าเป็นจุดบกพร่องของไลบรารีที่สามารถทำได้โดยนักพัฒนา

ในการแก้ปัญหาชั่วคราวคุณสามารถเพิ่ม-noverifyอาร์กิวเมนต์ JVM เพื่อปิดใช้งานการยืนยัน ใน Java 7 ยังสามารถใช้-XX:-UseSplitVerifierวิธีการตรวจสอบที่เข้มงวดน้อยกว่าได้ แต่ตัวเลือกนั้นถูกลบออกใน Java 8

— Mirko Adari
แหล่งที่มา
1
แต่ -XX: -UseSplitVerifier แปลว่าอะไร ?? ฉันดูคำอธิบายของ oracle มันบอกว่า "ใช้ตัวตรวจสอบประเภทใหม่กับแอตทริบิวต์ StackMapTable" ฉันไม่ได้รับมัน
— ยอห์น
2
ดังนั้นหากฉันเห็นข้อผิดพลาดนี้: นี่เป็นจุดบกพร่องภายใน JVM หรือรหัสของฉันหรือไม่?
— Bentolor
4
คำตอบนี้ใช้ไม่ได้ในระยะยาวหรืออาจนานกว่านั้นเนื่องจาก Oracle กำลังเลิกใช้งานตัวเลือกนี้ ฉันได้รับผลกระทบจากข้อผิดพลาดนี้ (พร้อมรหัสอื่น ๆ ) และกำลังมองหาวิธีที่จะสร้างสแต็กแมปก่อนหน้านี้
— ZiglioUK
2
สำหรับการทดสอบหน่วยคุณต้องส่งอาร์กิวเมนต์ในปลั๊กอิน surefire สิ่งนี้ได้แก้ไขปัญหาสำหรับคอมไพเลอร์ java 7 และ 8: <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-surefire-plugin </artifactId> <version> 2.18.1 </ version > <configuration> <argLine> -noverify -XX: -UseSplitVerifier </argLine> </configuration> </plugin>
— Antoine Wils
2
ฉันประสบปัญหาเดียวกัน แต่หลังจากเพิ่ม -noverify แล้วมันใช้ได้กับฉันจริงๆขอบคุณ
— Praveen Kumar Mekala
8

ฉันพบปัญหานี้และลองใช้แฟล็ก-noverifyที่ใช้งานได้จริง เป็นเพราะตัวตรวจสอบ bytecode ใหม่ ดังนั้นธงควรใช้งานได้จริง ฉันใช้ JDK 1.7

หมายเหตุ: จะใช้ไม่ได้หากคุณใช้ JDK 1.8

— จรัญราช
แหล่งที่มา
3
สำหรับฉันโดยใช้ค่าสถานะคงที่เพื่อดำเนินการทดสอบหน่วย Android ของเราโดยใช้ JRE 8 เป็นรันไทม์
— ubuntudroid
2
-noverify ใช้งานได้กับฉันบน Java 8 ฉันใช้ gradle สำหรับ Android ดังนั้นฉันจึงต้องใส่แฟล็ก -noverify ตามที่ระบุใน stackoverflow.com/a/37593189/2848676
— Michael Osofsky
คุณตั้งค่า -noverify ไว้ที่ไหน ฉันตั้งค่าเป็น MAVEN_OPTS แต่มันไม่ได้ผลสำหรับฉัน
— dev
@Sara Antunez ในไฟล์ build.gradle ของโมดูลแอปพลิเคชันของคุณในการปิด android ให้เพิ่มสิ่งนี้ android {.... testOptions {unitTests.all {jvmArgs '-noverify'}}}
— GrokkingDroid
2

ความแตกต่างเพียงอย่างเดียวระหว่างไฟล์ที่ทำให้เกิดปัญหาคือไฟล์ที่ 8 ไบต์

CA FE BA พ.ศ. 00 00 00 33 - Java 7

เทียบกับ

CA FE BA พ.ศ. 00 00 00 32 - Java 6

การตั้งค่า-XX:-UseSplitVerifierช่วยแก้ปัญหาได้ อย่างไรก็ตามสาเหตุของปัญหานี้คือhttps://bugs.eclipse.org/bugs/show_bug.cgi?id=339388

— คุนิน
แหล่งที่มา
2

ส่ง-noverifyอาร์กิวเมนต์ JVM ไปยังงานทดสอบของคุณ หากคุณกำลังใช้ gradle build.gradleคุณสามารถมีสิ่งต่างๆเช่น:

test {
  jvmArgs "-noverify"
}
— สิงห์
แหล่งที่มา
0

ข้อผิดพลาดนี้สามารถเกิดขึ้นได้เมื่อคุณใช้ Mockito เพื่อเยาะเย้ยชั้นเรียนสุดท้าย

ลองใช้ Mockito inline หรือ Powermock แทน

— nhoxbypass
แหล่งที่มา
-2

ขออภัยสำหรับการขุด แต่ฉันพบปัญหาเดียวกันและพบวิธีแก้ปัญหาที่ง่ายกว่า

ในตัวเลือกคอมไพเลอร์ Java คุณต้องยกเลิกการเลือก"Preserve unused (never read) local parameters"จึงไม่จำเป็นต้องเปลี่ยนกลับเวอร์ชัน JVM เป้าหมาย

ดูเหมือนว่าจะเป็นข้อบกพร่องใน Eclipe เวอร์ชันเก่า

— scoro
แหล่งที่มา
มันไม่ได้ผลสำหรับฉัน นี่คือส่วนสำคัญของข้อผิดพลาดของฉัน: gist.github.com/ZiglioNZ/bd1d7d424727b3f26c64
— ZiglioUK
3
OP ไม่ได้พูดถึง Eclipse เขาอาจไม่ได้ใช้มันด้วยซ้ำ
— Don Branson
-4

หากคุณสร้างโค้ดด้วยตัวเองปัญหานี้สามารถแก้ไขได้โดยการให้ "-target 1.5" แก่คอมไพเลอร์ java (หรือโดยการตั้งค่าตัวเลือกที่เกี่ยวข้องใน IDE ของคุณหรือการกำหนดค่าบิลด์ของคุณ)

— jrajp2184
แหล่งที่มา
-11

ลิงค์นี้มีประโยชน์ java.lang.VerifyError: คาดหวังเฟรมสแต็กแมป

วิธีที่ง่ายที่สุดคือเปลี่ยน JRE เป็น 6

— yuxiaomin
แหล่งที่มา
7
การดาวน์เกรดเมื่ออาร์กิวเมนต์ JVM ธรรมดาสามารถแก้ไขได้? ฉันสงสัยคำจำกัดความของคุณง่ายๆ
— Visionary Software Solutions
1
ในขณะที่สิ่งนี้อาจตอบคำถามในทางทฤษฎีแต่ควรรวมส่วนสำคัญของคำตอบไว้ที่นี่และระบุลิงก์สำหรับการอ้างอิง
— Joachim Sauer
นี่คือการแก้ปัญหา ดังที่ Joachim กล่าวไว้มันอาจใช้งานได้ แต่ไม่ได้กำหนดปัญหาหรือความช่วยเหลือสำหรับทีมหรือฐานรหัสที่ต้องใช้ Java 7
— Crowie
คำถามที่เชื่อมโยงมีหลายคำตอบ การดาวน์เกรดเป็นเพียงตัวเลือกเดียวในรายการ
— Ogre Psalm33
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.