search

bsugitayasa / powermock

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

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

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 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 9 years ago 
Hi, 

Thanks for your detailed error report. It seems to me that 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=339388 indicates a problem with 
ASM for Java7. ASM is the byte-code manipulation framework that they seem to 
use but PowerMock uses (mostly) Javassist. So this seems leads me to suspect 
that this is actually a problem with Javassist and not with PowerMock itself. 
Perhaps you could file this bug at the Javassist bug tracker as well and see 
what they have to say?

/Johan

Original comment by johan.ha...@gmail.com on 8 Nov 2011 at 7:23

GoogleCodeExporter commented 9 years ago 
This is happening only when we mock Static methods.  We are using powermock & 
Easymock.  Easy Mock has updated its code to be 1.7 compatible. We are pretty 
much stuck using 1.6 jdk because we don't want to lose our current tests a few 
thousand test are broken only when use 1.7 with a similar error.

Original comment by jbainbr...@gmail.com on 5 Jan 2012 at 3:31

GoogleCodeExporter commented 9 years ago 
java.lang.VerifyError: Bad type on operand stack in method 
com.xXXX.XXXXX.XXXXX.XXXXXXX(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/Str
ing; at offset 182 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.mockStatic(PowerMock.java:287) at 
com.xactnet.credentials.ServiceAreaTest.testSetContractorId(ServiceAreaTest.java
:61) at 
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$Po
werMockJUnit44MethodRunner.runTestMethod(PowerMockJUnit44RunnerDelegateImpl.java
:312) at 
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$Po
werMockJUnit44MethodRunner.executeTest(PowerMockJUnit44RunnerDelegateImpl.java:2
96) at 
org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$Po
werMockJUnit47MethodRunner.executeTestInSuper(PowerMockJUnit47RunnerDelegateImpl
.java:112) at 
org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$Po
werMockJUnit47MethodRunner.executeTest(PowerMockJUnit47RunnerDelegateImpl.java:7
3) at 
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$Po
werMockJUnit44MethodRunner.runBeforesThenTestThenAfters(PowerMockJUnit44RunnerDe
legateImpl.java:284) at 
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.in
vokeTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:209) at 
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.ru
nMethods(PowerMockJUnit44RunnerDelegateImpl.java:148) at 
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$1.
run(PowerMockJUnit44RunnerDelegateImpl.java:122) at 
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.ru
n(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)

This is with the latest powermock 1-5-2012

Powermock 1.4.11 javassist 3.150-GA  cglib-nodep-2.2.2.   objenesis 1.2  
easymock 3.1.jar

Original comment by jbainbr...@gmail.com on 5 Jan 2012 at 4:03

GoogleCodeExporter commented 9 years ago 
The issue is most likely caused by Javassist which we use for byte-code 
manipulation. Javassist is not JDK 7 compliant yet afaik. As soon a new version 
of Javassist is released I'll bring it in to PowerMock.

Original comment by johan.ha...@gmail.com on 5 Jan 2012 at 5:23

GoogleCodeExporter commented 9 years ago 
That would be great.

Original comment by jbainbr...@gmail.com on 17 Jan 2012 at 10:14

GoogleCodeExporter commented 9 years ago 
I filed a bug with Javassist, since their forums look dead. 
https://issues.jboss.org/browse/JASSIST-153

Original comment by plor...@gmail.com on 13 Feb 2012 at 8:19

GoogleCodeExporter commented 9 years ago 
The bug I entered in the javassist JIRA was closed, but a new one opened with 
what I'm guessing is a better description, etc.

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

The maintainer noted the following: 
--------------------------------------------------------------------------------
----
If a Java7 application on top of Javassist only uses the high-level API (only 
javassist.*
classes), Javassist must be responsible for properly updating stack map tables.
However, Javassist does not update a stack map table in some situation.

For an application directly using a lower-level API (javassist.bytecode.* 
classes),
updating a stack map table is the responsibility of the application.
--------------------------------------------------------------------------------
----

I don't know if powermock does use the javassist.bytecode.* classes directly, 
but that's something to be aware of if it does.

It looks the javassist maintainer has already made a code fix and targeted the 
fix for the 3.16.0 release.

Original comment by plor...@gmail.com on 15 Feb 2012 at 2:55

GoogleCodeExporter commented 9 years ago 
I think we're using the bytecode namespace to remove final modifiers from inner 
classes. Not sure if this is causing any trouble.

Original comment by johan.ha...@gmail.com on 15 Feb 2012 at 3:25

GoogleCodeExporter commented 9 years ago 
Javassist 3.16.0 has been released

Original comment by plor...@gmail.com on 19 Feb 2012 at 2:41

GoogleCodeExporter commented 9 years ago 
Great. I'll update the dependency in trunk. Could anyone try if there's any 
difference when you change to the new version av Javassist?

Original comment by johan.ha...@gmail.com on 19 Feb 2012 at 5:14

GoogleCodeExporter commented 9 years ago 
Doesn't look like it's available in maven central yet.

Original comment by johan.ha...@gmail.com on 19 Feb 2012 at 5:19

GoogleCodeExporter commented 9 years ago 
Using powermock 1.4.11 and mockito 1.9.0 over here.

Tried it by excluding javassist 3.15.0-GA dependency from the powermock 
dependency in the pom.xml and instead explicitly adding a 3.16.0-GA dependency. 
But still got the same exception: java.lang.VerifyError: Inconsistent stackmap 
frames at branch target 1193 in method ... at offset 1182.

Original comment by stefan.t...@gmail.com on 20 Feb 2012 at 12:15

GoogleCodeExporter commented 9 years ago 
same here.  The 3.16.0-GA doesn't solve the problem

Original comment by jbainbr...@gmail.com on 21 Feb 2012 at 5:13

GoogleCodeExporter commented 9 years ago 
Are you both using Java 7 or do you see this in Java 6 as well?

Original comment by johan.ha...@gmail.com on 21 Feb 2012 at 8:30

GoogleCodeExporter commented 9 years ago 
just Java 7

Original comment by jbainbr...@gmail.com on 21 Feb 2012 at 8:33

GoogleCodeExporter commented 9 years ago 
Same here: Has occurred when we switched to Java 7 (7u3), Java6 worked 
perfectly.

Original comment by stefan.t...@gmail.com on 21 Feb 2012 at 8:58

GoogleCodeExporter commented 9 years ago 
Alright. Do you get the error when running "OutputHelperTest" that's attached 
here? Perhaps we could file a Javassist bug with more details so they can 
resolve it. It could of course also be PowerMock's but since it works fine in 
Java 6 I suspect Javassist.

Original comment by johan.ha...@gmail.com on 22 Feb 2012 at 7:21

GoogleCodeExporter commented 9 years ago 
Found the attachment OutputHelperTest (attached to issue description), but 
where do I find OutputHelper (class under test)?

Original comment by stefan.t...@gmail.com on 22 Feb 2012 at 8:18

GoogleCodeExporter commented 9 years ago 
OutputHelper and OutputHelperTest are part of this project:  
https://github.com/kurmasz/Warszawa

Original comment by kurm...@gmail.com on 22 Feb 2012 at 2:12

GoogleCodeExporter commented 9 years ago 
For a workaround you can add the JVM flag -XX:-UseSplitVerifier to turn off the 
split verifier, which is what javassist is ultimately breaking.

http://stackoverflow.com/questions/7970622/java-7-jvm-verifyerror-in-eclipse

Verified on an in-house app with a substantially similar problem and setup to 
this one.

Original comment by danno.fe...@gmail.com on 2 Mar 2012 at 8:09

GoogleCodeExporter commented 9 years ago 
Thanks for sharing!

Original comment by johan.ha...@gmail.com on 2 Mar 2012 at 9:26

GoogleCodeExporter commented 9 years ago 
There's a new version of Javassist now, 3.16.1.GA, does it make any difference?

Original comment by johan.ha...@gmail.com on 9 Mar 2012 at 7:38

GoogleCodeExporter commented 9 years ago 
I'm having the same VerifyError over here.

I haven't tried Javassist in 3.16.0-GA for myself yet but I somehow doubt that 
Shigeru's fix works when looking at his patch:

https://source.jboss.org/changelog/Javassist?cs=613

The "runtest" target in build.xml got a new JVM arg 
"-XX:-FailOverToOldVerifier" which is probably not what you want to have when 
trying to prove that your code works in Java 7...

Original comment by etile.ba...@googlemail.com on 11 Mar 2012 at 1:44

GoogleCodeExporter commented 9 years ago 
The 3.16.0-GA doesn't fix the issue however the -XX:-UseSplitVerifier does work 
for us.

Original comment by jbainbr...@gmail.com on 15 Mar 2012 at 5:07

GoogleCodeExporter commented 9 years ago 
Same here: javassist 3.16.1-GA does not solve the problem, but if I run the 
test with -XX:-UseSplitVerifier it works fine.

Original comment by stefan.t...@gmail.com on 16 Mar 2012 at 1:03

GoogleCodeExporter commented 9 years ago 
Ok, thanks for sharing.

Original comment by johan.ha...@gmail.com on 16 Mar 2012 at 1:06

GoogleCodeExporter commented 9 years ago 
We have the same problem here.

* Running with Java 7 (update 3) the error occurs
* Running with Java 7 (update 3) with the option -XX:-UseSplitVerifier no error 
occurs
* Running with Java 6 (update 30) no error occurs (flag not needed)

Original comment by florian....@gmail.com on 3 Apr 2012 at 9:02

GoogleCodeExporter commented 9 years ago 
After revisiting this issue I stumbled upon my comment which is kind of 
senseless. Shigeru's mentioned fix 
(https://source.jboss.org/changelog/Javassist?cs=613) does prove in his tests 
that the code works under Java 7.

He's using "-XX:-FailOverToOldVerifier". Note the dash before 
FailOverToOldVerifier. This option prevents a failover to the olf verifier.

Shigeru mentions that "It is a specification that an application using a 
lower-level API must explicitly update a stack map table." The lower-level API 
is defined in javassist.bytecode.* (the higher-level API in javassist.*).

Since I have no clue about byte code manipulation, I just checked out the 
project and grepped for classes using javassist.bytecode.*. This is what I 
found:

% find . -name '*.java' | xargs grep -Hin javassist.bytecode
./core/src/main/java/org/powermock/core/transformers/impl/MainMockTransformer.ja
va:19:import javassist.bytecode.AttributeInfo;
./core/src/main/java/org/powermock/core/transformers/impl/MainMockTransformer.ja
va:20:import javassist.bytecode.ClassFile;
./core/src/main/java/org/powermock/core/transformers/impl/MainMockTransformer.ja
va:21:import javassist.bytecode.DuplicateMemberException;
./core/src/main/java/org/powermock/core/transformers/impl/MainMockTransformer.ja
va:22:import javassist.bytecode.InnerClassesAttribute;

Maybe this is the code in PowerMock that is not updating the stack map tables 
properly?

Original comment by etile.ba...@googlemail.com on 15 May 2012 at 8:55

GoogleCodeExporter commented 9 years ago 
Thanks for your comments. PowerMock is indeed using the lower-level API but not 
that much. Most of that stuff was provided as a patch to an issue some two 
years ago. Personally I'm not well-round with this lower-level API and the code 
seems to have worked at least up until Java 7. If anyone have any experience 
with this please help out!

Original comment by johan.ha...@gmail.com on 16 May 2012 at 7:29

GoogleCodeExporter commented 9 years ago 
Any updates? We are considering to remove powermock from our tests because of 
this problem.

Java6 EOL is coming closer and closer...

Original comment by moldowan.android@googlemail.com on 1 Jun 2012 at 12:49

GoogleCodeExporter commented 9 years ago 
I'm sorry to hear that but PowerMock is a one-man project and I would really 
need help from the community to fix this since I have so much to do and very 
little time. So why not contribute if it's so important for you?

Original comment by johan.ha...@gmail.com on 1 Jun 2012 at 1:06

GoogleCodeExporter commented 9 years ago 
Can you point me to a description of what this "patch to an issue some two 
years ago" was meant for?

Original comment by moldowan.android@googlemail.com on 1 Jun 2012 at 1:14

GoogleCodeExporter commented 9 years ago 
My guess is that the problem is in the "removeFinalModifierFromClass" method in 
the MainMockTransformer class since that's the only place I can remember where 
the lower-level byte-code API is used. It's used only for removing the final 
modifier of inner classes. To verify this you could try to remove everything 
below and including "ClassFile classFile = clazz.getClassFile2();" and build 
PowerMock (Skip tests and skip javadoc with "-Dmaven.javadoc.skip=true" because 
javadoc generation takes forever). It would be really great if we can close in 
on the issue a little bit.

Original comment by johan.ha...@gmail.com on 1 Jun 2012 at 1:23

GoogleCodeExporter commented 9 years ago 
I found this snippet in a tutorial:

-------------------------------
If you modify a class file for the J2ME execution environment, you must perform 
preverification. Preverifying is basically producing stack maps, which is 
similar to stack map tables introduced into J2SE at JDK 1.6. Javassist 
maintains the stack maps for J2ME only if 
javassist.bytecode.MethodInfo.doPreverify is true.

You can also manually produce a stack map for a modified method. For a given 
method represented by a CtMethod object m, you can produce a stack map by 
calling the following methods:

m.getMethodInfo().rebuildStackMapForME(cpool);
-----------------------

Apparently Java 7 made preverification mandatory. So do we just need to add 
something like that call to the end of the method that removes finals?

Original comment by plor...@gmail.com on 1 Jun 2012 at 1:29

GoogleCodeExporter commented 9 years ago 
It's definitively worth a shot. Can someone who experiences this issue try it 
out?

Original comment by johan.ha...@gmail.com on 1 Jun 2012 at 1:49

GoogleCodeExporter commented 9 years ago 
Don't think it'll work since that on the method-level only and the code is 
updating a class.

Original comment by johan.ha...@gmail.com on 1 Jun 2012 at 2:09

GoogleCodeExporter commented 9 years ago 
I found some tests in the powermock suite that fail with verify errors when run 
with Java 7. One is related to enums fails, but passes when I comment out the 
contents of PowerMockExpressionEditor#edit(FieldAccess f). Another fails but 
passes when I comment out the contents of 
PowerMockExpressionEditor#edit(ConstructorCall c).

I don't know if they're failing due to bugs in the Eclipse compiler or if 
they're failing due to bugs in javassist. Neither of them involve the bytecode 
package, though, so it seems unlikely that these issues are related to 
powermock bugs.

Tests I used were: MainMockTransformerTest and 
StringConstructorWorksWhenExtendingTestCase.

Original comment by plor...@gmail.com on 1 Jun 2012 at 9:32

GoogleCodeExporter commented 9 years ago 
Is there anyway to extract enough info on this provide Javassist with a bug 
report? Could anyone help out with this?

Original comment by johan.ha...@gmail.com on 12 Jun 2012 at 8:14

GoogleCodeExporter commented 9 years ago 
If you don't need Java 7 features, you can set the source and target options to 
Java 1.6, which gets around the problem. You will still be able to compile on 
Java 7, but it will treat the class as a Java 6 class, which apparently means 
that this behaviour won't show up.

Obviously, if you need Java 1.7 language features (e.g. switch on String) then 
this is a no-go. Hope that helps some of until this is fixed...

Original comment by nzipsi@gmail.com on 27 Jun 2012 at 2:58

GoogleCodeExporter commented 9 years ago 
I ran into this problem today as I tried to move to Java 7. I found another 
workaround for the problem by using -source 1.7 and -target 1.6 parameters for 
the compiler, meaning that 1.7 source code is accepted, and 1.6-compatible 
output is generated. I haven't tested this extensively, but this might help 
some of you currently needing a solution...

Original comment by da...@hartveld.com on 15 Jul 2012 at 3:45

GoogleCodeExporter commented 9 years ago 
Note that this does not seem to work with the openjdk compiler ("javac: source 
release 1.7 requires target release 1.7"). It does seem to work with the 
eclipse compiler.

Original comment by da...@hartveld.com on 15 Jul 2012 at 4:03

GoogleCodeExporter commented 9 years ago 
There is already quite a bug about the issue (at least it seems to be) reported 
against the newest javassist version 3.16.1-GA. See 
https://issues.jboss.org/browse/JASSIST-160
Until now there is no much activity concerning this bug. But it is reproducible 
and seems to target exactly the issue we have with power mock. At least the 
code, where we get the error looks very similar to the code provided in the bug.
Somewhere in the latest releases of javassist they introduced rebuildStackMap 
method everywhere, where any byte code manipulation is done. I debugged 
PowerMock code invoked in our test case, where we get the problem, and every 
byte code manipulation done by PowerMock is catched by javassist and 
rebuildStackMap is called appropriately. I did not find any powermock code 
bypassing rebuildStackMap. At least not for our test case. So it seems that 
javassist has problems with building the stack map.
Our test case is as simple as possible. We are giving an empty class 
ClassUnderTest to @PrepareForTest annotation. ClassUnderTest extends an empty 
class SuperClass. That's it. If we try to instantiate ClassUnderTest in a test 
method, it fails with the exception all of you already know. If we remove 
"extends" from ClassUnderTest, everything works fine.

Original comment by sergiy.b...@googlemail.com on 31 Jul 2012 at 2:49

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks for the investigation and for sharing your conclusions. Perhaps the 
Javassist folks would be interested in knowing this as well?

Original comment by johan.ha...@gmail.com on 31 Jul 2012 at 5:54

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Great news! Thanks for sharing.

Original comment by johan.ha...@gmail.com on 16 Sep 2012 at 7:22

GoogleCodeExporter commented 9 years ago 
Running the powermock-test.zip example (thanks to sergiy) with javassist 
3.17.0-GA (svn revision 655) and powermock 1.4.12 the verify error still exists:

java.lang.VerifyError: Inconsistent stackmap frames at branch target 44 in 
method ClassUnderTest.<init>()V at offset 35

Anybody has the same experience?

Original comment by torsten....@googlemail.com on 19 Sep 2012 at 1:05

GoogleCodeExporter commented 9 years ago 
I can try reproduce on my side but I cannot find javassist 3.17.0-GA. Doesn't 
seem to be available yet:

http://sourceforge.net/projects/jboss/files/Javassist/

Original comment by desmond.kirrane on 19 Sep 2012 at 2:59

GoogleCodeExporter commented 9 years ago 
Hi Desmond,

we have built this version from the subversion repository (svn co 
http://anonsvn.jboss.org/repos/javassist/trunk javassist; cd javassist; mvn 
clean install)

Original comment by torsten....@googlemail.com on 19 Sep 2012 at 3:21

GoogleCodeExporter commented 9 years ago 
Yes same problem my side. Doesn't seem to fix my tests either.

Original comment by desmond.kirrane on 19 Sep 2012 at 4:12

GoogleCodeExporter commented 9 years ago 
Hi,

I fixed this issue.  Download the snapshot and try it.

Original comment by shigeru....@gmail.com on 24 Sep 2012 at 2:48