ArchiveOrangemail archive

Technical discussion related to the JDK 7 Project


jdk7-dev.openjdk.java.net
(List home) (Recent threads) (60 other Java OpenJDK lists)

Subscription Options

  • RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
  • Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
  • This list contains about 2,333 messages, beginning Jan 2008
  • This list doesn't seem to be active
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no

Expecting a stackmap frame at branch target

Frédéric Camblor 1315828456Mon, 12 Sep 2011 11:54:16 +0000 (UTC)
Hi everyone !

I just migrated to openjdk 7 on my project and, just after the upgrade, most
of my unit test were in failure, throwing following exception :

java.lang.VerifyError: Expecting a stackmap frame at branch target 81
in method fr.fsh.bbeeg.common.config.BBEEGConfiguration.<init>()V at
offset 44


When I go back to jdk 6, every tests are back to green :-)
Have you any hint for solving this problem ?

More inputs about my environnment :
- OS : Linux ubuntu x86_64 (I encounter the same problem on my mac os x
lion)
- Build : Gradle 1.0 milestone 3
- Junit 4.8.2 to run unit tests
- On BBEEGConfiguration constructor, I'm calling a class located in a
private library, built with java source target 1.6 (but heh, openjdk 7 JRE
should be able to run 1.6 classes at runtime heh ?)

Full stack trace is the following :


java.lang.VerifyError: Expecting a stackmap frame at branch target 81
in method fr.fsh.bbeeg.common.config.BBEEGConfiguration.<init>()V at
offset 44
	at fr.fsh.bbeeg.common.config.BBEEGConfigurationTest.shouldAppVersionBeExtractedFromManifest(BBEEGConfigurationTest.java:16)
	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.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
	at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:51)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:63)
	at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:49)
	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.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
	at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
	at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:75)
	at $Proxy3.processTestClass(Unknown Source)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:86)
	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.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
	at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.messaging.remote.internal.MethodInvocationUnmarshallingDispatch.dispatch(MethodInvocationUnmarshallingDispatch.java:48)
	at org.gradle.messaging.dispatch.DiscardOnFailureDispatch.dispatch(DiscardOnFailureDispatch.java:31)
	at org.gradle.messaging.dispatch.AsyncDispatch.dispatchMessages(AsyncDispatch.java:129)
	at org.gradle.messaging.dispatch.AsyncDispatch.access$000(AsyncDispatch.java:33)
	at org.gradle.messaging.dispatch.AsyncDispatch$1.run(AsyncDispatch.java:69)
	at org.gradle.messaging.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:63)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:722)


Frédéric Camblor  <http://fcamblor.wordpress.com/>
<http://www.twitter.com/fcamblor>
Bordeaux JUG <http://bordeauxjug.org/> Board member
Jenkins <http://jenkins-ci.org/> community member & plugin commiter
Alan Bateman 1315832023Mon, 12 Sep 2011 12:53:43 +0000 (UTC)
Frédéric Camblor wrote:
> Hi everyone !
>
> I just migrated to openjdk 7 on my project and, just after the upgrade, most
> of my unit test were in failure, throwing following exception :
>
> java.lang.VerifyError: Expecting a stackmap frame at branch target 81
> in method fr.fsh.bbeeg.common.config.BBEEGConfiguration.<init>()V at
> offset 44
>
>
> When I go back to jdk 6, every tests are back to green :-)
>Use od -x to look at the class file to see which class version it is. 
Class files >= version 51 are verified (exclusively) by the type 
checking verifier whereas with version 50 then if the verification fails 
it falls back to the old type inferencing verifier. If you have 
something modifying the class files then maybe it isn't updating the 
stack map tables and that would explain the error. For your jdk6 test 
runs then try running with -XX:-FailOverToOldVerifier and see if fails too.

-Alan.
Frédéric Camblor 1315841019Mon, 12 Sep 2011 15:23:39 +0000 (UTC)
Hi Alan,

Thanks for you reply, you helped me to point out problem was about cobertura
instrumentation which looks not compatible with Java 7

I'll raise an issue on this topic on their issue tracker :)

Frédéric Camblor  <http://fcamblor.wordpress.com/>
<http://www.twitter.com/fcamblor>
Bordeaux JUG <http://bordeauxjug.org/> Board member
Jenkins <http://jenkins-ci.org/> community member & plugin commiter2011/9/12 Alan Bateman 

> Frédéric Camblor wrote:
>
>> Hi everyone !
>>
>> I just migrated to openjdk 7 on my project and, just after the upgrade,
>> most
>> of my unit test were in failure, throwing following exception :
>>
>> java.lang.VerifyError: Expecting a stackmap frame at branch target 81
>> in method fr.fsh.bbeeg.common.config.**BBEEGConfiguration.<init>()V at
>> offset 44
>>
>>
>> When I go back to jdk 6, every tests are back to green :-)
>>
>>
> Use od -x to look at the class file to see which class version it is. Class
> files >= version 51 are verified (exclusively) by the type checking verifier
> whereas with version 50 then if the verification fails it falls back to the
> old type inferencing verifier. If you have something modifying the class
> files then maybe it isn't updating the stack map tables and that would
> explain the error. For your jdk6 test runs then try running with
> -XX:-FailOverToOldVerifier and see if fails too.
>
> -Alan.
>
Frédéric Camblor 1315947525Tue, 13 Sep 2011 20:58:45 +0000 (UTC)
Alan,

Woudn't there any -XX JVM parameter, on jdk7, allowing to get back jdk6
strategy about stack map tables ?
Or maybe stack map tables _must_ be ok starting from jdk7 (due to class file
specifications for example) ?

Frédéric Camblor  <http://fcamblor.wordpress.com/>
<http://www.twitter.com/fcamblor>
Bordeaux JUG <http://bordeauxjug.org/> Board member
Jenkins <http://jenkins-ci.org/> community member & plugin commiter2011/9/12 Frédéric Camblor 

> Hi Alan,
>
> Thanks for you reply, you helped me to point out problem was about
> cobertura instrumentation which looks not compatible with Java 7
>
> I'll raise an issue on this topic on their issue tracker :)
>
>  Frédéric Camblor  <http://fcamblor.wordpress.com/> <http://www.twitter.com/fcamblor>
> Bordeaux JUG <http://bordeauxjug.org/> Board member
> Jenkins <http://jenkins-ci.org/> community member & plugin commiter
>
>
> 2011/9/12 Alan Bateman 
>
>> Frédéric Camblor wrote:
>>
>>> Hi everyone !
>>>
>>> I just migrated to openjdk 7 on my project and, just after the upgrade,
>>> most
>>> of my unit test were in failure, throwing following exception :
>>>
>>> java.lang.VerifyError: Expecting a stackmap frame at branch target 81
>>> in method fr.fsh.bbeeg.common.config.**BBEEGConfiguration.<init>()V at
>>> offset 44
>>>
>>>
>>> When I go back to jdk 6, every tests are back to green :-)
>>>
>>>
>> Use od -x to look at the class file to see which class version it is.
>> Class files >= version 51 are verified (exclusively) by the type checking
>> verifier whereas with version 50 then if the verification fails it falls
>> back to the old type inferencing verifier. If you have something modifying
>> the class files then maybe it isn't updating the stack map tables and that
>> would explain the error. For your jdk6 test runs then try running with
>> -XX:-FailOverToOldVerifier and see if fails too.
>>
>> -Alan.
>>
>
>
Keith McGuigan 1315948384Tue, 13 Sep 2011 21:13:04 +0000 (UTC)
The latter.  New features in jdk7 require the use of the type-checking  
verifier -- which is what the cobertura instrumentation appears to be  
running afoul of.
Home | About | Privacy