Not sure if this is a javassist bug or a powermock one. (or a JVM bug)
I'm running the latest JVM, that has fixed the other VerifyError error
(https://bugs.openjdk.java.net/browse/JDK-8051012)
What steps will reproduce the problem?
1. The attached test file causes a stackmap error
java.lang.VerifyError: Expecting a stackmap frame at branch target 11
It shouldn't
What is the expected output? What do you see instead?
testStackmapBug(stackmapbug.StackmapTest) Time elapsed: 0.107 sec <<< ERROR!
java.lang.VerifyError: Expecting a stackmap frame at branch target 11
Exception Details:
Location:
stackmapbug/StackmapTest$breaksStuff.breaks()V @8: if_acmpeq
Reason:
Expected stackmap frame at this location.
Bytecode:
0x0000000: 2ab6 001a 2ab6 001a a500 03b1
at stackmapbug.StackmapTest.testStackmapBug(StackmapTest.java:13)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.powermock.modules.junit4.rule.PowerMockStatement.evaluate(PowerMockRule.java:63)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
What version of the product are you using? On what operating system?
powermock 1.5.6
linux (fedora 20), with:
java version "1.7.0_71"
OpenJDK Runtime Environment (fedora-2.5.3.0.fc20-x86_64 u71-b14)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
and
openjdk version "1.8.0_25"
OpenJDK Runtime Environment (build 1.8.0_25-b18)
OpenJDK 64-Bit Server VM (build 25.25-b02, mixed mode)
These java versions are meant to have the fix for
https://bugs.openjdk.java.net/browse/JDK-8051012
JDK8 breaks regardless of whether I compile for -target 1.7 or 1.8
Please provide any additional information below.
The trigger seems to be the instantiation of the separate class that uses != on
two objects within an if statement (the original scenario has this in a .equals
method)
using toString() instead of getClass() triggers the same problem, but "foo" !=
"foo" doesn't.
It has to be in a separate class; putting the condition into the @Test method
doesn't cause an issue.
The inner class doesn't make a difference; it was just easier to put everything
in the one file to reproduce.
-noverify works around this
https://github.com/bbaetz/stackmapbug has a full project/pom/etc - just run
'mvn test'
Original issue reported on code.google.com by bbaetz@gmail.com on 22 Oct 2014 at 2:23
Original issue reported on code.google.com by
bbaetz@gmail.comon 22 Oct 2014 at 2:23Attachments: