search

89071388 / powermock

Automatically exported from code.google.com/p/powermock
0 stars 0 forks source link

Test generates java.lang.VerifyError: Inconsistent stackmap frames at branch target #355

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
I suspect this may be a manifestation of this issue: 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=339388.  It wasn't clear if this 
is a Java issue, or something that needs to be fixed on a product-by-product 
basis, so I thought I'd bring it to your attention just in case.

What steps will reproduce the problem?
1. Compiling and running my project with Java 1.7.0_01 on Windows  (I tried to 
isolate the problem, but it only appears in the context of the entire project.)

What is the expected output? What do you see instead?

When I run certain tests (described below), I get the following runtime error:
1) 
testOpenWriter_file_string_autoflush_setsEncodings(edu.gvsu.kurmasz.warszawa.io.
OutputHelperTest2)
java.lang.VerifyError: Inconsistent stackmap frames at branch target 134 in 
method edu.gvsu.kurmasz.warszawa.io.OutputHelperTest2$CharsetTes
ter.values()[Ledu/gvsu/kurmasz/warszawa/io/OutputHelperTest2$CharsetTester; at 
offset 126
        at edu.gvsu.kurmasz.warszawa.io.OutputHelperTest2.testOpenWriter_file_string_autoflush_setsEncodings(OutputHelperTest2.java:353)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:66)
        at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runTestMethod(PowerMoc
kJUnit44RunnerDelegateImpl.java:307)
        at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86)
        at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:94)
        at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.executeTest(PowerMockJ
Unit44RunnerDelegateImpl.java:294)
        at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTestInSuper(Pow
erMockJUnit47RunnerDelegateImpl.java:112)
        at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTest(PowerMockJ
Unit47RunnerDelegateImpl.java:73)
        at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runBeforesThenTestThen
Afters(PowerMockJUnit44RunnerDelegateImpl.java:282)
        at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84)
        at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
        at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.invokeTestMethod(PowerMockJUnit44RunnerDelegateImpl
.java:207)
        at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.runMethods(PowerMockJUnit44RunnerDelegateImpl.java:
146)
        at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$1.run(PowerMockJUnit44RunnerDelegateImpl.java:120)
        at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
        at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
        at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.run(PowerMockJUnit44RunnerDelegateImpl.java:118)
        at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.run(JUnit4TestSuiteChunkerImpl.java:102)
        at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.run(AbstractCommonPowerMockRunner.java:53)
        at org.junit.runners.Suite.runChild(Suite.java:128)
        at org.junit.runners.Suite.runChild(Suite.java:24)

What version of the product are you using? On what operating system?
I'm using java 1.7.0_01 on Windows with the following jar files:
cglib-nodep-2.2.jar               junit-4.8.2.jar                   
objenesis-1.2.jar
javassist-3.15.0-GA.jar           mockito-all-1.8.5.jar             
powermock-mockito-1.4.10-full.jar

Please provide any additional information below.
* Everything works fine I compile the project using java 1.6.
* Everything works fine if I run the tests using this flag: 
-XX:-UseSplitVerifier 
* If I take the offending class and its test and move them to a new project, 
the problem disappears (i.e., I can't seem to isolate the problem in a small 
example.)

Thus, I suspect this may be a manifestation of this issue: 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=339388.  It wasn't clear if this 
is a Java issue, or something that needs to be fixed on a product-by-product 
basis.

If it helps, I've also attached a copy of the test file.  The problem seems to 
be related to the enum CharacterTester

Original issue reported on code.google.com by kurm...@gmail.com on 6 Nov 2011 at 2:23

Attachments:

GoogleCodeExporter commented 8 years ago 
Confirmed - VerifyErrors vanished from my setup.

btw: one test fails when building javassist trunk (called "150b" or so)...

Original comment by moldowan.android@googlemail.com on 25 Sep 2012 at 9:17

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Great news! Thanks everyone for helping out.

Original comment by johan.ha...@gmail.com on 26 Sep 2012 at 6:11

GoogleCodeExporter commented 8 years ago 
Yes javassist-3.17.0-GA.jar now works for my PowerMock tests also.

Original comment by desmond.kirrane on 26 Sep 2012 at 11:23

GoogleCodeExporter commented 8 years ago 
Warning --  -XX:-UseSplitVerifier is dangerous and led to spooky errors when 
combined with PowerMock and Java 7.

 '-XX:-UseSplitVerifier' fixed the verification errors, but led to other problems.  JUnit tests that were not using PowerMock were failing badly -- static references were seemingly substituted and replaced (e.g. a singleton changed from the POV of a non-Powermock test).

Building the trunk javassist (javassist-3.17.0-GA.jar) and using that with the 
default Java 7 verifier worked fine.

javassist needs a new release with this change badly.

Original comment by scott.ca...@gmail.com on 29 Sep 2012 at 12:36

GoogleCodeExporter commented 8 years ago 
I'm more or less ready to release a new version of PowerMock but do you think I 
should wait until the next Javassist release before I do so?

Original comment by johan.ha...@gmail.com on 29 Sep 2012 at 10:18

GoogleCodeExporter commented 8 years ago 
I think you should wait as this seems to be a top issue for many powermock 
users.

Original comment by moldowan.android@googlemail.com on 29 Sep 2012 at 10:32

GoogleCodeExporter commented 8 years ago 
If you don't plan to release some new killer features or major bug fixes, you 
should wait for the next Javassist release. Just my 2 cents.

Original comment by i...@kjeld.de on 29 Sep 2012 at 10:55

GoogleCodeExporter commented 8 years ago 
The main new features are probably support for Mockito 1.9-rc1 and that JUnit 
rules finally works for JUnit 4.9+. But maybe it's better to wait just as you 
say.

Original comment by johan.ha...@gmail.com on 29 Sep 2012 at 12:02

GoogleCodeExporter commented 8 years ago 
Hi,

I confirm the bugfix for the testsample of comment 42. But we still get the 
VerifyError, when we test a class extending the SwingWorker-class. The error 
occurs by initializing the inner class of the SwingWorker. I have attached the 
modified example using a swingworker like in our own application.

Original comment by thomas.h...@googlemail.com on 2 Oct 2012 at 9:08

Attachments:

GoogleCodeExporter commented 8 years ago 
Here is the stacktrace:

java.lang.VerifyError: Inconsistent stackmap frames at branch target 53 in 
method 
javax.swing.SwingWorker$SwingWorkerPropertyChangeSupport.<init>(Ljavax/swing/Swi
ngWorker;Ljava/lang/Object;)V at offset 39
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:186)
    at javassist.runtime.Desc.getClassObject(Desc.java:43)
    at javassist.runtime.Desc.getClassType(Desc.java:152)
    at javassist.runtime.Desc.getType(Desc.java:122)
    at javassist.runtime.Desc.getType(Desc.java:78)
    at javax.swing.SwingWorker.<init>(SwingWorker.java:309)
    at powermocktest.SuperClass.<init>(SuperClass.java:5)
    at powermocktest.ClassUnderTest.<init>(ClassUnderTest.java:8)
    at powermocktest.PowerMockTest.test(PowerMockTest.java:18)
    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.junit.internal.runners.TestMethod.invoke(TestMethod.java:66)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:312)
    at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86)
    at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:94)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.executeTest(PowerMockJUnit44RunnerDelegateImpl.java:296)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTestInSuper(PowerMockJUnit47RunnerDelegateImpl.java:112)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTest(PowerMockJUnit47RunnerDelegateImpl.java:73)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runBeforesThenTestThenAfters(PowerMockJUnit44RunnerDelegateImpl.java:284)
    at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84)
    at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.invokeTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:209)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.runMethods(PowerMockJUnit44RunnerDelegateImpl.java:148)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$1.run(PowerMockJUnit44RunnerDelegateImpl.java:122)
    at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
    at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.run(PowerMockJUnit44RunnerDelegateImpl.java:120)
    at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.run(JUnit4TestSuiteChunkerImpl.java:102)
    at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.run(AbstractCommonPowerMockRunner.java:53)
    at org.powermock.modules.junit4.PowerMockRunner.run(PowerMockRunner.java:42)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

Original comment by thomas.h...@googlemail.com on 2 Oct 2012 at 9:09

GoogleCodeExporter commented 8 years ago 
Thomas, you should report that here as well:
https://issues.jboss.org/browse/JASSIST-160

Original comment by moldowan.android@googlemail.com on 4 Oct 2012 at 2:45

GoogleCodeExporter commented 8 years ago 
I saw that.  I will check the new test.  Hope will be fixed before the release.

Original comment by shigeru....@gmail.com on 5 Oct 2012 at 3:57

GoogleCodeExporter commented 8 years ago 
I have fixed this problem.  Can anyone confirm this?  Thanks!

Original comment by shigeru....@gmail.com on 6 Oct 2012 at 2:49

GoogleCodeExporter commented 8 years ago 
Yes, I can confirm the bugfix. Now the sample projects works fine as well as 
the tests in our own project. Now the only step to do is release the javassist 
and modify the maven dependency for powermock to the new version. Than 
everything is fine :). Thanks. Great work.

Original comment by thomas.h...@googlemail.com on 8 Oct 2012 at 12:26

GoogleCodeExporter commented 8 years ago 
Nice, great job! Can't wait for the upcoming javassist release. :)

Original comment by i...@kjeld.de on 8 Oct 2012 at 12:29

GoogleCodeExporter commented 8 years ago 
I've said this numerous times before but thanks a lot everyone for helping out. 
My plan is to release PowerMock as soon as the next version of Javassist is 
released.

Original comment by johan.ha...@gmail.com on 8 Oct 2012 at 12:54

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
I'd like to add another error message that seems to be the result of this same 
bug:

java.lang.VerifyError: Bad type on operand stack in aaload in method 
org.foo.bar.FooBar.<init>()V at offset 101

My test involves mocking construction of a new object using 
PowerMockito.whenNew().  Researching this problem led me here, and applying the 
latest javassist-3.17.0-GA.jar resolved this error in my test.

Original comment by oliverhe...@gmail.com on 12 Oct 2012 at 5:37

GoogleCodeExporter commented 8 years ago 
Thank you for the great work on fixing this issue. I would also like to confirm 
that version 3.17.0-GA fixed all "inconsistent stackmap" issues I had on my 
project with Java 1.7 and Powermock.

Any update on the release date for 3.17.0-GA?

Original comment by ja...@midtgaard-olesen.dk on 15 Oct 2012 at 8:17

GoogleCodeExporter commented 8 years ago 
The trunk of javassit fixed most of our promblems however we are still getting 
some issues.   Any ideas?

Exception in thread "main" java.lang.IllegalStateException: Failed to transform 
class with name xxx.xxxxx.xxxxx.xxxxxx. Reason: null
    at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:207)
    at org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:145)
    at org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:67)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:264)
    at sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:114)
    at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:125)
    at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49)
    at sun.reflect.annotation.AnnotationParser.parseSig(AnnotationParser.java:390)
    at sun.reflect.annotation.AnnotationParser.parseClassValue(AnnotationParser.java:371)
    at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:673)
    at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:480)
    at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:306)
    at sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:241)
    at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:88)
    at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:70)
    at java.lang.Class.initAnnotationsIfNecessary(Class.java:3089)
    at java.lang.Class.getAnnotations(Class.java:3069)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.classAnnotations(PowerMockJUnit44RunnerDelegateImpl.java:165)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.getDescription(PowerMockJUnit44RunnerDelegateImpl.java:157)
    at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.getDescription(JUnit4TestSuiteChunkerImpl.java:172)
    at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.getDescription(AbstractCommonPowerMockRunner.java:47)
    at org.powermock.modules.junit4.PowerMockRunner.run(PowerMockRunner.java:40)
    at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
    at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:520)
    at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1060)
    at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:884)
Caused by: java.lang.NullPointerException
    at javassist.bytecode.stackmap.TypeData.commonSuperClassEx(TypeData.java:400)
    at javassist.bytecode.stackmap.TypeData$TypeVar.fixTypes2(TypeData.java:342)
    at javassist.bytecode.stackmap.TypeData$TypeVar.fixTypes(TypeData.java:325)
    at javassist.bytecode.stackmap.TypeData$TypeVar.dfs(TypeData.java:270)
    at javassist.bytecode.stackmap.MapMaker.fixTypes(MapMaker.java:287)
    at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:140)
    at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:99)
    at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:423)
    at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:405)
    at javassist.expr.ExprEditor.doit(ExprEditor.java:113)
    at javassist.CtClassType.instrument(CtClassType.java:1398)
    at org.powermock.core.transformers.impl.MainMockTransformer.transform(MainMockTransformer.java:75)
    at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:203)
    ... 27 more
and :

java.lang.VerifyError: Stack map does not match the one at exception handler 
2290 in method xxx.xxxxx.xxx.xxxxxxx.xxxxxxxx()Ljava/lang/String; at offset 686
    at java.lang.Class.getDeclaredMethods0(Native Method)
    at java.lang.Class.privateGetDeclaredMethods(Class.java:2442)
    at java.lang.Class.getMethod0(Class.java:2685)
    at java.lang.Class.getMethod(Class.java:1620)
    at org.easymock.internal.ObjectMethodsFilter.<init>(ObjectMethodsFilter.java:55)
    at org.easymock.internal.MocksControl.createMock(MocksControl.java:59)
    at org.powermock.api.easymock.PowerMock.doCreateMock(PowerMock.java:2212)
    at org.powermock.api.easymock.PowerMock.doMock(PowerMock.java:2163)
    at org.powermock.api.easymock.PowerMock.createMock(PowerMock.java:89)
    at xxx.xxxx.xxx.xxxx.xxxxxxxxxxxxxxTest.testxxxxxxxxxx(xxxxxxxxxxxxxxTest.java:93)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:312)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.executeTest(PowerMockJUnit44RunnerDelegateImpl.java:296)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTestInSuper(PowerMockJUnit47RunnerDelegateImpl.java:112)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTest(PowerMockJUnit47RunnerDelegateImpl.java:73)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runBeforesThenTestThenAfters(PowerMockJUnit44RunnerDelegateImpl.java:284)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.invokeTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:209)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.runMethods(PowerMockJUnit44RunnerDelegateImpl.java:148)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$1.run(PowerMockJUnit44RunnerDelegateImpl.java:122)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.run(PowerMockJUnit44RunnerDelegateImpl.java:120)
    at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.run(JUnit4TestSuiteChunkerImpl.java:102)
    at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.run(AbstractCommonPowerMockRunner.java:53)
    at org.powermock.modules.junit4.PowerMockRunner.run(PowerMockRunner.java:42)

Original comment by jbainbr...@gmail.com on 15 Oct 2012 at 3:08

GoogleCodeExporter commented 8 years ago 
I have publicly released Javassist 3.17.0-GA although the bug reported by 
Comment 71 has not been tested.
To investigate this bug, I need the javap dump of the class file VerifyError is 
reported on.

Original comment by shigeru....@gmail.com on 9 Nov 2012 at 2:05

GoogleCodeExporter commented 8 years ago 
Stack map does not match the one at exception handler 2290 in method 
xxx.xxxx.xxx.xxxx.xxxx()Ljava/lang/String; at offset 686
java.lang.VerifyError: Stack map does not match the one at exception handler 
2290 in method com.xxx.xxx.xxxx.xxxxxx()Ljava/lang/String; at offset 686
    at java.lang.Class.getDeclaredMethods0(Native Method)
    at java.lang.Class.privateGetDeclaredMethods(Class.java:2442)
    at java.lang.Class.getMethod0(Class.java:2685)
    at java.lang.Class.getMethod(Class.java:1620)
    at org.easymock.internal.ObjectMethodsFilter.<init>(ObjectMethodsFilter.java:55)
    at org.easymock.internal.MocksControl.createMock(MocksControl.java:59)
    at org.powermock.api.easymock.PowerMock.doCreateMock(PowerMock.java:2212)
    at org.powermock.api.easymock.PowerMock.doMock(PowerMock.java:2163)
    at org.powermock.api.easymock.PowerMock.createMock(PowerMock.java:89)
    at com.xactnet.itr.reports.YearOverYearKeyCompositeITRReportTest.testGetInformationForCorda(YearOverYearKeyCompositeITRReportTest.java:93)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:312)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.executeTest(PowerMockJUnit44RunnerDelegateImpl.java:296)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTestInSuper(PowerMockJUnit47RunnerDelegateImpl.java:112)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTest(PowerMockJUnit47RunnerDelegateImpl.java:73)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runBeforesThenTestThenAfters(PowerMockJUnit44RunnerDelegateImpl.java:284)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.invokeTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:209)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.runMethods(PowerMockJUnit44RunnerDelegateImpl.java:148)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$1.run(PowerMockJUnit44RunnerDelegateImpl.java:122)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.run(PowerMockJUnit44RunnerDelegateImpl.java:120)
    at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.run(JUnit4TestSuiteChunkerImpl.java:102)
    at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.run(AbstractCommonPowerMockRunner.java:53)
    at org.powermock.modules.junit4.PowerMockRunner.run(PowerMockRunner.java:42)

Original comment by jbainbr...@gmail.com on 9 Nov 2012 at 3:33

GoogleCodeExporter commented 8 years ago 
I'm missing the new Javassist release 3.17.0-GA in maven central. Who is 
usually deploying the artifact?

I found a detailed HOWTO on how to publish it:
https://community.jboss.org/wiki/PublishingJavassistReleasesToSonatypePublicRepo
mavenCentral?_sscc=t

Original comment by i...@kjeld.de on 9 Nov 2012 at 4:15

GoogleCodeExporter commented 8 years ago 
So it's released! That's great news. Please keep us posted when it pops up on 
maven central and I'll release PowerMock unless something unexpected happens.

Original comment by johan.ha...@gmail.com on 9 Nov 2012 at 4:30

GoogleCodeExporter commented 8 years ago 
3.17 is live on maven central now. 
http://repo2.maven.org/maven2/org/javassist/javassist/3.17.0-GA/

Anxiously awaiting the next Powermock release!

Original comment by DanFabul...@gmail.com on 14 Nov 2012 at 8:44

GoogleCodeExporter commented 8 years ago 
Cool! Thanks for notifying me. I'm at devoxx right now but hopefully I can find 
some time to release during the weekend.

Original comment by johan.ha...@gmail.com on 14 Nov 2012 at 1:07

GoogleCodeExporter commented 8 years ago 
Hmm I run into "javassist/CtClass.class(javassist:CtClass.class): major version 
51 is newer than 50, the highest major version supported by this compiler" when 
I try to build PowerMock with the 3.17 of Javassist in Java 6 and so Maven 
won't build it. Any ideas?

Original comment by johan.ha...@gmail.com on 14 Nov 2012 at 1:51

GoogleCodeExporter commented 8 years ago 
So it works when I switch to JDK 7. But what exactly does this mean? The goal 
is that PowerMock should support Java 5.

Original comment by johan.ha...@gmail.com on 14 Nov 2012 at 1:56

GoogleCodeExporter commented 8 years ago 
First of all, congratulations on a job well done regarding PowerMock! :)

Bare with me because what will follow is a lot of guesswork. Hope it will help 
you a little bit even so! :)

'Major version 51 is newer than 50' only indicates that the class-file is 
compiled with a Java 7-compiler. That's why it works in JDK7 and not 6.

If I'm guessing right then Javassist needs to publish other jars (using a 
different compiler or specifying the java compatibility version with '-target').

Original comment by lars.pan...@gmail.com on 14 Nov 2012 at 7:02

GoogleCodeExporter commented 8 years ago 
Actually, Javassist are already aware of the problem. See the link below.

https://issues.jboss.org/browse/JASSIST-163

Original comment by lars.pan...@gmail.com on 14 Nov 2012 at 7:33

GoogleCodeExporter commented 8 years ago 
I've filed https://issues.jboss.org/browse/JASSIST-178 on the Java 7 bug, 
linking back to the conversation in JASSIST-163 (JASSIST-163 is not relevant to 
this powermock issue #355 or JASSIST-178, but JASSIST-178 was discussed in 
comments on JASSIST-163.)

Original comment by dan.fabu...@redfin.com on 14 Nov 2012 at 9:24

GoogleCodeExporter commented 8 years ago 
Guess we should wait until a new Javassist binary is relased to Maven central 
then or what do you guys think?

Original comment by johan.ha...@gmail.com on 15 Nov 2012 at 8:19

GoogleCodeExporter commented 8 years ago 
While we wait for the new binaries maybe we could compile the Javassist source 
ourselves so we're not stuck? I mean, we don't know how long we'll have to wait 
for the new binaries in Maven central.

Original comment by lars.pan...@gmail.com on 15 Nov 2012 at 8:33

GoogleCodeExporter commented 8 years ago 
Self compiling is just a workaround. The publishing process of Javassist is 
kind of lame. Takes several days after a new release to publish it in maven 
central and is then "broken". :(

Original comment by i...@kjeld.de on 15 Nov 2012 at 8:39

GoogleCodeExporter commented 8 years ago 
I will release 3.17.1 within a few days, which will be compiled by Java 6 and 
fix another bug.

I agree that the release engineering of Javassist is a kind of lame.  It's a 
long lasting project (more than a decade!) and it is currently maintained 
almost only by me (the project founder) and released through a guy at 
Redhat/JBoss.

Original comment by shigeru....@gmail.com on 19 Nov 2012 at 8:17

GoogleCodeExporter commented 8 years ago 
I think this is totally understandable. PowerMock has been around since 2007 
and I'm more or less in the same situation that you are. It's not easy to get 
everything right by yourself. I think Javassist is an awesome project and 
without it PowerMock probably wouldn't exist.

Did you compile it against Java 6 in releases prior to 3.17? I'm wondering 
since I would really like PowerMock to work for Java >= 5 and not run into the 
'Major version 51 is newer than 50' problem again.

Original comment by johan.ha...@gmail.com on 19 Nov 2012 at 10:30

GoogleCodeExporter commented 8 years ago 
Thanks for your understanding.  When I started the project, I was young and had 
lots of time for coding but nowadays I am getting to be a "the boss"-like 
professor (I'm working for university) who is always busy with administration 
and losing time for coding. :-(

Javassist can be compiled even by Java 4.  So Java 5 is also fine.  One concern 
is that the binary compiled by Java 4 or 5 does not contain stack map tables, 
which will cause a bit slowdown on the Java 6 or 7 VM.

Any inputs?

Original comment by shigeru....@gmail.com on 19 Nov 2012 at 3:33

GoogleCodeExporter commented 8 years ago 
Shigeru, thank you for your hard work on finalising the Javassist 
3.17GA-release! I've been eagerly following a few of the related 
Javassist-issues. Keep up the good work! :)

I would suggest that you keep at least Java 5 compatibility so that most 
Maven-users won't run into version incompatibility problems. But that also 
depends on how severe the performance penalty is?

Original comment by lars.pan...@gmail.com on 19 Nov 2012 at 7:37

GoogleCodeExporter commented 8 years ago 
3.17.1 is live on maven central now; it's now backwards compatible with Java 
1.4. http://repo2.maven.org/maven2/org/javassist/javassist/3.17.1-GA/

Let's do this! :-)

Original comment by DanFabul...@gmail.com on 3 Dec 2012 at 6:19

GoogleCodeExporter commented 8 years ago 
I've released a new version now, it should be available in Maven central soon. 
BIG thanks to everyone for helping out.

Original comment by johan.ha...@gmail.com on 4 Dec 2012 at 12:10

GoogleCodeExporter commented 8 years ago 
Hi, sorry for reviving this thread, but I seem to have gotten into a very 
similar issue.

It only appears when running the full suite of JUnit tests, the individual 
(failed) test runs fine.
I'm using PowerMock 1.5 (with easymock) on JDK 7 along with junit4 in Eclipse.
In the stacktrace below 'ServiceType' is actually an enum, it is not mocked 
itself but there is 1 static mocked: java.sql.DriverManager (other mocked 
objects are related interfaces like Connection and PreparedStatement)

Stacktrace:
Caused by: java.lang.VerifyError: Expecting a stackmap frame at branch target 
10 in method 
javax.xml.parsers.DocumentBuilderFactory.newInstance(Ljava/lang/String;Ljava/lan
g/ClassLoader;)Ljavax/xml/parsers/DocumentBuilderFactory; at offset 0
    at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:854)
    at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:778)
    at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:526)
    at org.apache.log4j.LogManager.<clinit>(LogManager.java:127)
    at org.apache.log4j.Logger.getLogger(Logger.java:117)
    at be.persgroep.akamai.services.ServiceType.<clinit>(ServiceType.java:84)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:186)
    at javassist.runtime.Desc.getClassObject(Desc.java:43)
    at javassist.runtime.Desc.getClazz(Desc.java:52)
    at be.persgroep.akamai.test.ServiceTypeTest.getNonExistingIDInsertError(ServiceTypeTest.java:191)
    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.junit.internal.runners.TestMethod.invoke(TestMethod.java:66)
    at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:312)
    ... 23 more

Original comment by redalert.commander@gmail.com on 8 Jan 2013 at 1:03

GoogleCodeExporter commented 8 years ago 
Interestingly, this occurs when selecting run as - junit test from the context 
menu of the source folder in eclipse. When running from the maven pom file all 
tests are successful.

Original comment by redalert.commander@gmail.com on 8 Jan 2013 at 1:09

GoogleCodeExporter commented 8 years ago 
These are the worst kind of errors and it's almost impossible to know what 
could be the reason for it :( Have you explicitly tried to prepare the 
DocumentBuilderFactory for test? Otherwise you can try to ignore everything in 
the "javax.*" package (by using @PowerMockIgnore).

Original comment by johan.ha...@gmail.com on 8 Jan 2013 at 1:37

GoogleCodeExporter commented 8 years ago 
The only log4j related actions on my behalf are a JVM paramter 
(-Dlog4j.configuration=file) and the usual private static final Logger = ...

I just tried the @PowerMockIgnore annotation, but that seems to create other 
problems.
first I ignored javax.*, which resulted in the same error but on the 
DocumentBuilderFactoryImpl class from xerces in com.sun. Ignoring com.sun as 
well results in a totally different error:
java.lang.LinkageError: loader constraint violation: when resolving method 
"javax.xml.parsers.DocumentBuilder.setErrorHandler(Lorg/xml/sax/ErrorHandler;)V"
 the class loader (instance of org/powermock/core/classloader/MockClassLoader) 
of the current class, org/apache/log4j/xml/DOMConfigurator, and the class 
loader (instance of <bootloader>) for resolved class, 
javax/xml/parsers/DocumentBuilder, have different Class objects for the type 
s.DocumentBuilder.setErrorHandler(Lorg/xml/sax/ErrorHandler;)V used in the 
signature

After that one, another for org.w3c, now I finally got this:
@PowerMockIgnore({"javax.*", "com.sun*", "org.xml.*", "org.w3c.*" })
but it works.

Another test, that's not using PowerMock, still fails with this message:
java.lang.VerifyError: Expecting a stackmap frame at branch target 16 in method 
com.example.xxxx.RealMain.realMain([Ljava/lang/String;Ljava/io/PrintStream;Ljava
/io/PrintStream;)V at offset 6

Original comment by redalert.commander@gmail.com on 8 Jan 2013 at 3:10

GoogleCodeExporter commented 8 years ago 
Perhaps you could try the Java agent approach? 
http://code.google.com/p/powermock/wiki/PowerMockAgent

Original comment by johan.ha...@gmail.com on 8 Jan 2013 at 6:35

GoogleCodeExporter commented 8 years ago 
There is 1 test that fails as soon as I replace 
'@RunWith(PowerMockRunner.class)' with
@Rule
public final PowerMockRule rule = new PowerMockRule();

(inside the class body)

java.lang.VerifyError: Expecting a stackmap frame at branch target 306 in 
method 
com.example.xxxxx.xxxxxx.ServiceType.getXxx(Ljava/lang/String;Ljava/lang/String;
)I at offset 7

Adding this class to @PrepareForTest reveals another, then another, etc. until 
I reach the second one from the com.sun package, I can't add that one due to 
visibility of the class (com.sun.crypto.provider.CipherCore).

I take it that this method of invoking PowerMock would actually work if I fix 
my test, it is doing calls to a webservice which a test shouldn't do (haven't 
mocked these yet).

Thanks for your help.

Original comment by redalert.commander@gmail.com on 9 Jan 2013 at 9:30

GoogleCodeExporter commented 8 years ago 
Small addition to that last comment, the failing test doesn't actually use 
PowerMock yet, it only fails because the classes are already loaded because of 
previous tests.
It would run fine on its own.

Original comment by redalert.commander@gmail.com on 9 Jan 2013 at 9:32

GoogleCodeExporter commented 8 years ago 
I'm also getting similar error:

java.lang.VerifyError: Expecting a stackmap frame at branch target 90
Exception Details:
  Location:
    com/example/Util.<clinit>()V @32: if_acmpeq
  Reason:
    Expected stackmap frame at this location.
  Bytecode:
    0000000: 0000 0000 014b 014c 1303 a1b8 03a3 03bd
    0000010: 006e 1303 a5b8 03a7 b803 a94d 2cb2 03ab
    0000020: a500 3a2c c101 6a99 002b b803 ad13 03ae
    0000030: b803 b013 03b1 b803 b3a7 0007 b803 b5bf
    0000040: 01b6 03b7 b603 b901 b603 bbc0 0023 4ca7
    0000050: 0008 2cc0 0023 4ca7 000b bb00 2359 b703
    0000060: bd4c 2bb3 0018 b1                      
  Exception Handler Table:
    bci [51, 57] => handler: 60

    at java.lang.Class.getDeclaredConstructors0(Native Method)
    at java.lang.Class.privateGetDeclaredConstructors(Class.java:2404)
    at java.lang.Class.getDeclaredConstructors(Class.java:1853)
    at org.mockito.internal.creation.jmock.ClassImposterizer.setConstructorsAccessible(ClassImposterizer.java:75)
    at org.mockito.internal.creation.jmock.ClassImposterizer.imposterise(ClassImposterizer.java:70)
    at org.powermock.api.mockito.internal.mockcreation.MockCreator.createMethodInvocationControl(MockCreator.java:110)
    at org.powermock.api.mockito.internal.mockcreation.MockCreator.mock(MockCreator.java:60)
    at org.powermock.api.mockito.PowerMockito.mockStatic(PowerMockito.java:70)
    at com.example.UtilTest.test(UtilTest.java)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
    at org.powermock.modules.junit4.rule.PowerMockStatement$1.run(PowerMockRule.java:52)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at org.powermock.reflect.internal.WhiteboxImpl.performMethodInvocation(WhiteboxImpl.java:2014)
    at org.powermock.reflect.internal.WhiteboxImpl.doInvokeMethod(WhiteboxImpl.java:885)
    at org.powermock.reflect.internal.WhiteboxImpl.invokeMethod(WhiteboxImpl.java:713)
    at org.powermock.reflect.Whitebox.invokeMethod(Whitebox.java:401)
    at org.powermock.classloading.ClassloaderExecutor.execute(ClassloaderExecutor.java:98)
    at org.powermock.classloading.ClassloaderExecutor.execute(ClassloaderExecutor.java:78)
    at org.powermock.modules.junit4.rule.PowerMockStatement.evaluate(PowerMockRule.java:49)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
    at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)

@PrepareForTest(Util.class)
public class UtilTest {
    @Rule
    public PowerMockRule powerMock = new PowerMockRule();

    @Test
    public void test() {
        mockStatic(Util.class);
...

Env: MacOSX 10.7.5, openjdk-1.7
Deps: powermock-1.5, mockito-1.9.5 and hamcrest-1.3, junit-1.4.10.

Adding -XX:-UseSplitVerifier seems fixes original the issue. But when added to 
be used by maven / surefire as:

        <plugin>
          <artifactId>maven-surefire-plugin</artifactId>
          <version>${surefire-plugin.version}</version>

          <configuration>
            <argLine>-XX:-UseSplitVerifier</argLine>
          </configuration>
        </plugin>

causes random failures in other not related to powermock unit tests.
Sometimes whole suite of tests even passes with success. But it is not reliable.

Original comment by lystoc...@gmail.com on 1 Feb 2013 at 1:29

GoogleCodeExporter commented 8 years ago 
I think you should bring this up on the Javassist issue tracker since it's 
looks to me that the issue is with Javassist.

Original comment by johan.ha...@gmail.com on 1 Feb 2013 at 1:49