VerifyError with JavaSE-1.8

[apr...@tibco.com]

Running the latest jacoco-0.7.7.201606060606 in Eclipse under JavaSE-1.8 (Oracle jdk1.8.0_91), the instrumented AUT classes refuse to load:

java.lang.VerifyError Expecting a stackmap frame at branch target nn

I recall encountering something similar under JavaSE-1.7 as a consequence of JaCoCo apparently injecting incorrect bytecode. I had to run with -XX:-UseSplitVerifier.

To get this running under jdk1.8.x I've had to use the -noverify flag.

* What is the status of JaCoCo - does it support JavaSE-1.8?
* If not, are there any plans to do so?

[Evgeny Mandrikov]

JaCoCo does support Java 8 already for a very long time - see "What Java versions are supported by JaCoCo?" in our FAQ at http://www.eclemma.org/jacoco/trunk/doc/faq.html

Moreover - work on support of Java 9 has been started.

As of today we have very extensive tests targeting various JDKs, also JaCoCo is used by many projects targeting Java 8. And we are not aware of any example that could lead to "java.lang.VerifyError Expecting a stackmap frame at branch target nn" and thus believe that JaCoCo generates valid bytecode.

Also note that as stated in our FAQ: JaCoCo expected to produce valid "stackmap frames" when original is valid.

Hence questions:

Might it be possible that original is invalid, e.g. produced by some other bytecode manipulation tool?

Would it be possible to provide reproducer/example or at least original class file that causes this issue? To get an impression about speed and depth of investigations in presence of proper information - you can have a look for example at https://github.com/jacoco/jacoco/issues/394 and https://github.com/jacoco/jacoco/issues/462

[Adrian Price]

Evgeny, many thanks for the response - I'm encouraged to hear that JaCoCo supports Java 8 and that work on Java 9 is underway. My apologies for not picking this up from the FAQ.

JaCoCo is the only bytecode manipulation tool in use in our continuous integration stack - we're compiling to Java 1.7 compliance using the Eclipse 4.4 Java compiler, and tests are executed as 'JUnit Plug-in Tests' on Eclipse 3.7.2 in an Oracle 1.8 JVM (the final application runtime is actually Java 7, but Selenium Client 3.x seems to require Java 8). I will experiment with compiling using later versions of Eclipse 4.x to compile the classes - perhaps there's a problem there.

Cheers,

Adrian

[Evgeny Mandrikov]

I guess that you use JaCoCo via EclEmma since you said "JUnit Plug-in Tests". And in this case I'm wondering how it can be 0.7.7? Latest EclEmma 2.3.3 uses JaCoCo 0.7.6. To me seems that the only difference between 0.7.6 and 0.7.7 potentially on this subject is about upgrade from ASM 5.0.4 to ASM 5.1, but I don't see nor how this change nor how changes in ASM could affect you. Anyway please confirm what you use?

Not excluded that Eclipse Java Compiler produces something strange, example from past - https://bugs.eclipse.org/bugs/show_bug.cgi?id=171472

And once again - might be possible to investigate this just by sending us single class file with which you face issue.

And as a workaround maybe you can simply exclude this single class from instrumentation.

In any case - keep us posted.

Regards,

Evgeny

[Adrian Price]

Actually, we're not using EclEmma per se; our CI infrastructure launches Eclipse via the 'library.xml' Ant script that comes with the Eclipse Test Framework, which is essentially a means of using Ant to execute JUnit tests within a running Eclipse instance. We're using jacoco-0.7.7.201606060606 and instrumentation is performed dynamically using -javaagent:jacocoagent.jar=destfile=etc....

I'll keep you posted if I learn anything further; thanks again for your responses.

Regards,

--A

[Marc R. Hoffmann]

Hi Adrian,

can you please add the option classdumpdir for the JaCoCo agent? This will dump all classes as seen by the agent. If you send us the problematic class file we can do further analysis.

Regards,
-marc

--
You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jacoco+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/CAL%3DKvBT9SmE7U1nvK7AR5maOodoApLXcMEkxSNYtiCHU2UXwTw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.