java_lang_VerifyError_Expecting_a_stackmap_frame_at_branch_target问题的解决

2018年02月10日 99 字 教程整理


问题报错: java.lang.VerifyError: Inconsistent stackmap frames at branch target ...

考虑目前主流的J2EE框架的优点,决定利用假期时间将OA系统原有的Struts2框架(Maven+Spring/Struts2/Mybatis3)迁移至SpringMVC框架(Maven+Spring/SPringMVC/Mybatis3)。
将接口按照SpringMVC进行必要的简单调整后,在eclipse中启动项目却始终不能正常运行程序。而利用Maven命令打包之后传送至云服务器,则可以正常部署和访问网站。

根据本地开发环境和远程服务器上的不同表现,可以判定程序及配置文件本身应该没有问题,出现报错的主要原因,应该是在两个服务器上的开发和运行环境有所区别。

本地eclipse环境运行的报错代码如下:

Exception Details:
  Location:
cn/wonhigh/retail/gms/web/controller/ItemInvoicingReportController.getMxList(Ljavax/servlet/http/HttpServletRequest;Lorg/springframework/ui/Model;)Ljava/util/Map; @81: aload_1
  Reason:
Type top (current frame, locals[9]) is not assignable to 'java/lang/String' (stack map, locals[9])
  Current Frame:
bci: @73
flags: { }
locals: { 'cn/wonhigh/retail/gms/web/controller/ItemInvoicingReportController', 'javax/servlet/http/HttpServletRequest', 'org/springframework/ui/Model', 'java/lang/String', 'java/lang/Throwable', 'java/lang/Throwable', 'cn/wonhigh/retail/mdm/api/util/CacheContext', top, 'java/util/Map' }
stack: { integer }
  Stackmap Frame:
bci: @81
flags: { }
locals: { 'cn/wonhigh/retail/gms/web/controller/ItemInvoicingReportController', 'javax/servlet/http/HttpServletRequest', 'org/springframework/ui/Model', 'java/lang/String', 'java/lang/Throwable', 'java/lang/Throwable', 'cn/wonhigh/retail/mdm/api/util/CacheContext', top, 'java/util/Map', 'java/lang/String' }
stack: { }
  Bytecode:
0000000: 1100 0457 2b12 7cb9 007e 0200 1233 b800
0000010: 844e 013a 0401 3a05 bb00 8a59 b700 8c3a
0000020: 062d 128d b600 8f99 004f 2a2b 2c19 06b6
0000030: 0093 3a08 1906 c600 0819 06b6 0097 2b12
0000040: 9ab9 007e 0200 b800 9c99 0008 1233 a700
0000050: 0e2b 129a b900 7e02 00b8 00a2 3a09 1909
0000060: b800 a69a 0010 2bb9 00a9 0100 1909 b900
0000070: ad02 0019 08b0 2a2b 2c19 06b6 00b2 3a08
0000080: 1906 c600 0819 06b6 0097 2b12 9ab9 007e
0000090: 0200 b800 9c99 0008 1233 a700 0e2b 129a
00000a0: b900 7e02 00b8 00a2 3a09 1909 b800 a69a
00000b0: 0010 2bb9 00a9 0100 1909 b900 ad02 0019
00000c0: 08b0 3a04 1906 c600 0819 06b6 0097 1904
00000d0: bf3a 0519 04c7 000a 1905 3a04 a700 1419
00000e0: 0419 05b8 037d 9900 0a19 0419 05b6 00b5
00000f0: 1904 bf3a 0419 04bf 3a04 bb00 2e59 1904
0000100: b700 bbbf 3a07 2b12 9ab9 007e 0200 b800
0000110: 9c99 0008 1233 a700 0e2b 129a b900 7e02
0000120: 00b8 00a2 3a09 1909 b800 a69a 0010 2bb9
0000130: 00a9 0100 1909 b900 ad02 0019 07bf
  Exception Handler Table:
bci [33, 52] => handler: 194
bci [62, 128] => handler: 194
bci [138, 194] => handler: 194
bci [24, 209] => handler: 209
bci [18, 62] => handler: 243
bci [118, 138] => handler: 243
bci [194, 243] => handler: 243
bci [18, 62] => handler: 248
bci [118, 138] => handler: 248
bci [194, 243] => handler: 248
bci [18, 62] => handler: 260
bci [118, 138] => handler: 260
bci [194, 260] => handler: 260
  Stackmap Table:
full_frame(@62,{Object[#1],Object[#127],Object[#106],Object[#88],Object[#182],Object[#182],Object[#138],Top,Object[#194]},{})
append_frame(@81,Object[#88])
same_locals_1_stack_item_frame(@92,Object[#88])
chop_frame(@115,1)
chop_frame(@118,2)
append_frame(@138,Top,Object[#194])
append_frame(@157,Object[#88])
same_locals_1_stack_item_frame(@168,Object[#88])
chop_frame(@191,1)
full_frame(@194,{Object[#1],Object[#127],Object[#106],Object[#88],Object[#182],Object[#182],Object[#138]},{Object[#182]})
chop_frame(@206,1)
same_locals_1_stack_item_frame(@209,Object[#182])
same_frame(@223)
same_frame(@240)
full_frame(@243,{Object[#1],Object[#127],Object[#106],Object[#88]},{Object[#46]})
same_locals_1_stack_item_frame(@248,Object[#80])
same_locals_1_stack_item_frame(@260,Object[#182])
full_frame(@281,{Object[#1],Object[#127],Object[#106],Object[#88],Top,Top,Top,Object[#182]},{})
same_locals_1_stack_item_frame(@292,Object[#88])
same_frame(@315)
 
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1455)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:607)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:925)
at org.springframework.context.support.AbstractApplicationContext.__refresh(AbstractApplicationContext.java:472)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java)
at org.springframework.web.servlet.FrameworkServlet.configureAndRefreshWebApplicationContext(FrameworkServlet.java:631)
at org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:588)
at org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:645)
at org.springframework.web.servlet.FrameworkServlet.initWebApplicationContext(FrameworkServlet.java:508)
at org.springframework.web.servlet.FrameworkServlet.initServletBean(FrameworkServlet.java:449)
at org.springframework.web.servlet.HttpServletBean.init(HttpServletBean.java:133)
at javax.servlet.GenericServlet.init(GenericServlet.java:158)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1284)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5231)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5518)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1575)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1565)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.VerifyError: Inconsistent stackmap frames at branch target 81
Exception Details:
  Location:
cn/wonhigh/retail/gms/web/controller/ItemInvoicingReportController.getMxList(Ljavax/servlet/http/HttpServletRequest;Lorg/springframework/ui/Model;)Ljava/util/Map; @81: aload_1
  Reason:
Type top (current frame, locals[9]) is not assignable to 'java/lang/String' (stack map, locals[9])
  Current Frame:
bci: @73
flags: { }
locals: { 'cn/wonhigh/retail/gms/web/controller/ItemInvoicingReportController', 'javax/servlet/http/HttpServletRequest', 'org/springframework/ui/Model', 'java/lang/String', 'java/lang/Throwable', 'java/lang/Throwable', 'cn/wonhigh/retail/mdm/api/util/CacheContext', top, 'java/util/Map' }

此问题在stackoverFlow上找到了答案,先把原文贴出来再简要的解释下:

0.1. 参考资料

  1. http://stackoverflow.com/questions/12774672/java-7-inconsistent-stackmap-frames-need-help-understanding-why-solution-wor
  2. http://stackoverflow.com/questions/7970622/java-7-jvm-verifyerror-in-eclipse
  3. https://bugs.eclipse.org/bugs/show_bug.cgi?id=353467
  4. https://bugs.eclipse.org/bugs/show_bug.cgi?id=353467#c3
  5. http://stackoverflow.com/questions/8079504/akka-actors-fails-verifyerror-inconsistent-stackmap-frames-at-branch-target
  6. http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

0.2. 问题分析

Stackoverflow上分析的大意是jdk7,java验证更严格了,所以会报错。

具体原因分析:
报异常的方法内使用了Java 7的新特性:自动资源释放,类似于try(){},即在try后面跟一括号,在括号里面对一些资源赋值,try里面的代码块执行完毕之后会自动释放try后面的括号中声明的资源。
Java 7 会使用新的Class类型校验器,新的类型校验器将老的校验器分为两步:

  1. 类型推断
  2. 类型校验

新的类型校验器通过在javac编译时嵌入类型信息到bytecode中,省略了类型推断这一步,从而提升了classloader的性能。  

Classload顺序(供参考):load -> verify -> prepare -> resove -> init

  

   -XX:+UseSplitVerifier

    `Enables splitting of the verification process. By default, this option was enabled in the previous releases, and verification was split into two phases: type referencing (performed by the compiler) and type checking (performed by the JVM runtime). This option was deprecated in JDK 8, and verification is now split by default without a way to disable it.`

***As of Java 7, compiled bytecode has to contain additional StackMapTable attributes. These help the verifier inside the JVM to check that classes are soundly constructed, at class loading time. Earlier versions of Java are more lenient, falling back on the slower verification without attributes.

Tools that modify the original compiled bytecode (ProGuard right after the compilation, AOP frameworks right before the execution,…) need to update the attributes consistently with the modified code. If they fail to do so, you’ll get the error message “Inconsistent stackmap frames”.

ProGuard should perform this preverification fine; I’m not aware of any problems with it. If you still see the error without applying ProGuard, the problem must lie with the DI or AOP.***

0.3. 解决方案

0.3.1. 降低JDK版本

如,改成JDK6,但这种方法不推荐。

0.3.2. 修改Eclipe-Vm argument参数

在eclipse 选择 Windows -> Preferences -> Installed JREs.

然后选择默认的jre环境,点击edit,在Default Vm argument 添加一个参数:

  • 如果是jdk7:请填写:-XX:-UseSplitVerifier
  • 如果是jdk8:请填写:-noverify

如图示:

0.3.3. 修改Eclipse-jvm运行参数,不配置为默认参数

这种方法本质上和上一种方法相同,只是把jvm运行参数不配置为默认参数,而是在每个run configuration 里配置,具体如下:

0.4. 附: Stackoverflow 检索到的解决办法

Right now, when I try to persist an object in Google App Engine, I’m facing the error “Java.lang.VerifyError: Expecting a stackmap frame at branch target“. I’m using JDK 7 and it seems like the problem lies with this JDK.

After googling a bit, I found that there seems to be two solutions to fix this problem.

Solution 1: Change to JDK 6
As simple as is, change your JDK to version 6 and you won’t be bugged by this exception anymore. Well, in my case, I have to use JDK 7. So, moving on to the solution 2.

Solution 2: Configure JVM
Go to Windows -> Preferences -> Installed JREs. Select the default JVM and click edit. Then add this parameter as VM argument “-XX:-UseSplitVerifier” as seen below.

As a workaround you can add -noverify to the JVM arguments in order to disable verification. In Java 7 it was also possible to use -XX:-UseSplitVerifier to use the less strict verification method, but that option was removed in Java 8.