I tried to instrument a jar which was translated from an apk by using dex2jar. Then the error arised.There are some details about command and exception.
java -jar /home/ren/MyProject/tcg-android/jacoco-android/org.jacoco.cli/target/org.jacoco.cli-0.8.1-SNAPSHOT-nodeps.jar instrument mobileqq_android-dex2jar.jar —dest operation_pool/
Exception in thread "main" java.io.IOException: Error while instrumenting /home/ren/.local/share/Trash/files/jacoco-android/instrument/mobileqq_android-dex2j...@abap.class.
$ javap -v -p aaqc.class | grep "major version"major version: 50
Hi,
looks like dex2jar is creating invalid class files. I did a quick sanity check with ASMs CheckClassAdapter and get the following result:
Exception in thread "main" java.lang.RuntimeException: Execution can fall off end of the code <clinit>()V
at org.objectweb.asm.util.CheckMethodAdapter$1.visitEnd(CheckMethodAdapter.java:467)
at org.objectweb.asm.MethodVisitor.visitEnd(MethodVisitor.java:878)
at org.objectweb.asm.util.CheckMethodAdapter.visitEnd(CheckMethodAdapter.java:1038)
at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1130)
at org.objectweb.asm.ClassReader.accept(ClassReader.java:698)
at org.objectweb.asm.ClassReader.accept(ClassReader.java:500)
As mentioned before: JaCoCo requires valid class files as an input.
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/548cedbb-7def-42b1-a355-f27f8d87a522%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and stop receiving emails from it, send an email to jacoco+unsubscribe@googlegroups.com.
It is actually pretty easy to demonstrate that we add frames near probes into classes that have no frames initially - see attachment.
Maybe this shocks ASM during expansion of wide jumps in absence of other frames, causing AIOOBE? There is definitely such expansion during instrumentation of "UiApiPlugin.class" because stack trace contains call of "ClassReader.accept" from "ClassWriter.toByteArray". But so far didn't succeeded with creation/reduction of reproducer for AIOOBE.
Hi Evgeny,
I was as bit confused at the beginning as we have ClassFileVersionsTest which tests for existence of frames.
But after a closer look I realized that this test only checks whether our generated runtime access methods insert frames. Probe insertion may also cause frames. The test case contains no code which causes such additional frames. That's why the test case is probably missing it.
But still confused as we run our integration test suite on Java 5...
I can work on a fix.
Cheers,
-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/fad9941c-eca0-457e-a5b3-dc11cc789db4%40googlegroups.com.
> Marc, how you execute CheckClassAdapter ?
I did it completely wrong: Created a small Java main() but accedentially used SKIP_CODE for the accept method().
Sorry for the noise...
I'll now try to improve ClassFileVersionsTest to demonstrate the problem.
Regards,
-marc
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/21b73862-10db-4c82-a5f5-47483694a3be%40googlegroups.com.
Hi Evgeny,
I was as bit confused at the beginning as we have ClassFileVersionsTest which tests for existence of frames.
But after a closer look I realized that this test only checks whether our generated runtime access methods insert frames. Probe insertion may also cause frames. The test case contains no code which causes such additional frames. That's why the test case is probably missing it.
But still confused as we run our integration test suite on Java 5...
The StackMapTable attribute must be recognized and correctly read by a class file reader if the class file's version number is 50.0 or above and the Java Virtual Machine implementation recognizes class files whose version number is 50.0 or above.
I'll now try to improve ClassFileVersionsTest to demonstrate the problem.
> Maybe better / simpler to add explicit check of absence of frames into all validation tests - e.g. into org.jacoco.core.test.InstrumentingLoader ?
Good idea, I will extract a "FrameCheckAdapter" or so which can be used in both places.
--
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/CAEPFu696MvK0qA4rqXmOUjTccX4PhkOXNFR3uktgyur5-7%3Dqmg%40mail.gmail.com.
Here is a proposed fix:
https://github.com/jacoco/jacoco/pull/667
I didn't yet expand it to other validation tests as they depend on the toolchain JDK.
Cheers,
-marc
On 2018-03-29 12:54, Evgeny Mandrikov wrote:
--
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/CAEPFu696MvK0qA4rqXmOUjTccX4PhkOXNFR3uktgyur5-7%3Dqmg%40mail.gmail.com.
Here is a proposed fix:
https://github.com/jacoco/jacoco/pull/667
I didn't yet expand it to other validation tests as they depend on the toolchain JDK.
So the conclusion is jacoco has a little bug with handling frame right?I notice that jacoco could exclude some classes in execution analysis, However, it could not exclude the classes in instrumentation so that I have to delete the .class manually before instrumentation to avoid this issues. Is there any other more elegant way.