java.lang.VerifyError: Mong đợi một khung stackmap tại mục tiêu nhánh JDK 1.7

88

Sau khi nâng cấp lên JDK 1.7, tôi nhận được ngoại lệ dưới đây:

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 
— John
nguồn

Câu trả lời:

171

Java 7 đã giới thiệu quy trình xác minh chặt chẽ hơn và thay đổi định dạng lớp một chút — để chứa một bản đồ ngăn xếp được sử dụng để xác minh rằng mã là đúng. Ngoại lệ bạn thấy có nghĩa là một số phương thức không có bản đồ ngăn xếp hợp lệ.

Cả hai phiên bản Java hoặc thiết bị bytecode đều có thể là nguyên nhân. Thông thường, điều này có nghĩa là một thư viện được ứng dụng sử dụng tạo ra mã bytecode không hợp lệ không vượt qua được xác minh chặt chẽ hơn. Vì vậy, không có gì khác hơn là báo cáo nó là một lỗi cho thư viện có thể được thực hiện bởi nhà phát triển.

Để giải quyết vấn đề, bạn có thể thêm -noverifyvào các đối số JVM để tắt xác minh. Trong Java 7, cũng có thể sử dụng -XX:-UseSplitVerifierđể sử dụng phương pháp xác minh ít nghiêm ngặt hơn, nhưng tùy chọn đó đã bị loại bỏ trong Java 8.

— Mirko Adari
nguồn
1
Nhưng -XX: -UseSplitVerifier nghĩa là gì ?? Tôi đã xem lời giải thích của oracle, Nó nói "Sử dụng trình kiểm tra kiểu mới với các thuộc tính StackMapTable". Tôi không hiểu.
— John
2
Vì vậy, nếu tôi gặp lỗi này: Đây là lỗi trong JVM hay mã của tôi?
— màu bentolor vào
4
Câu trả lời này không hợp lệ về lâu dài, hoặc có thể lâu hơn nữa, vì Oracle không dùng tùy chọn này. Tôi đang bị ảnh hưởng bởi lỗi này (với các mã khác) và đang tìm kiếm một cách để xây dựng lại fore của stackmaps
— ZiglioUK
2
để kiểm tra đơn vị, bạn phải vượt qua các đối số trong plugin surefire. Điều này đã khắc phục sự cố cho cả trình biên dịch java 7 và 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
tôi đã gặp phải vấn đề tương tự nhưng sau khi thêm -noverify nó thực sự hiệu quả với tôi. Cảm ơn.
— Praveen Kumar Mekala
15

Nếu bạn đang sử dụng java 1.8, hãy xóa XX:-UseSplitVerifiervà sử dụng -noverifytrong thuộc tính JVM của bạn.

— Anand Kumar KK
nguồn
8

Tôi gặp sự cố này và thử sử dụng cờ -noverifythực sự hoạt động. Đó là do trình xác minh bytecode mới. Vì vậy, lá cờ thực sự nên hoạt động. Tôi đang sử dụng JDK 1.7.

Lưu ý: Điều này sẽ không hoạt động nếu bạn đang sử dụng JDK 1.8

— Charan Raj
nguồn
3
Đối với tôi bằng cách sử dụng cờ đã cố định thực hiện Kiểm tra đơn vị Android của chúng tôi bằng cách sử dụng JRE 8 làm thời gian chạy.
— ubuntudroid
2
-noverify cũng làm việc cho tôi trên Java 8. Tôi đang sử dụng gradle dành cho Android và vì vậy tôi đã phải đặt cờ -noverify nơi quy định tại stackoverflow.com/a/37593189/2848676
— Michael Osofsky
bạn đã đặt -noverify ở đâu? Tôi đặt nó là MAVEN_OPTS nhưng nó không hoạt động đối với tôi
— dev
@Sara Antunez, Trong tệp build.gradle của mô-đun ứng dụng của bạn ở dạng đóng android, hãy thêm cái này. android {.... testOptions {{unitTests.all jvmArgs '-noverify'}}}
— GrokkingDroid
2

Chuyển -noverifyđối số JVM cho nhiệm vụ kiểm tra của bạn. Nếu bạn đang sử dụng gradle, build.gradlebạn có thể có một cái gì đó như:

test {
  jvmArgs "-noverify"
}
— Sư Tử
nguồn
0

LỖI này có thể xảy ra khi bạn sử dụng Mockito để mô phỏng các lớp cuối cùng .

Thay vào đó, hãy cân nhắc sử dụng Mockito nội tuyến hoặc Powermock.

— nhoxbypass
nguồn
-1

Xin lỗi vì đã đào, nhưng tôi đã gặp vấn đề tương tự và tìm ra giải pháp đơn giản hơn.

Trong các tùy chọn trình biên dịch Java, bạn cần bỏ chọn "Bảo tồn các biến cục bộ không sử dụng (không bao giờ đọc)" để không cần thay đổi phiên bản JVM đích.

Có vẻ như đây là một lỗi trong các phiên bản Eclipe cũ hơn.

— Scoro
nguồn
nó không làm việc cho tôi. Dưới đây là một ý chính của lỗi của tôi: gist.github.com/ZiglioNZ/bd1d7d424727b3f26c64
— ZiglioUK
3
OP không đề cập đến Eclipse. Anh ta thậm chí có thể không sử dụng nó.
— Don Branson
-3

Nếu bạn đang tự tạo mã, thì vấn đề này có thể được khắc phục bằng cách cung cấp "-target 1.5" cho trình biên dịch java (hoặc bằng cách đặt tùy chọn tương ứng trong IDE hoặc cấu hình xây dựng của bạn).

— jrajp2184
nguồn
-11

liên kết này là hữu ích. java.lang.VerifyError: Mong đợi một khung sơ đồ ngăn xếp

cách đơn giản nhất là thay đổi JRE thành 6.

— yuxiaomin
nguồn
7
hạ cấp khi một đối số JVM đơn giản có thể sửa chữa? Tôi nghi ngờ định nghĩa của bạn về đơn giản.
— Giải pháp phần mềm có tầm nhìn xa,
1
Mặc dù về mặt lý thuyết, điều này có thể trả lời câu hỏi, nhưng tốt hơn hết bạn nên đưa các phần thiết yếu của câu trả lời vào đây và cung cấp liên kết để tham khảo.
— Joachim Sauer
Đây là một công việc xung quanh. Như Joachim đã nói, nó có thể hoạt động - nhưng nó không xác định vấn đề hoặc trợ giúp cho các nhóm hoặc cơ sở mã phải sử dụng Java 7
— Crowie
Có nhiều câu trả lời trong câu hỏi được liên kết. Hạ cấp chỉ là một tùy chọn được liệt kê.
— Ogre Psalm33
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.