Jacoco throws errors when method body is very large.

[rahul.s...@gmail.com]

I am successfully using Jacoco except one issue. Jacoco throws errors when method body is very large. Is there any limitation on number of lines in a method? If yes can we increase that limit? Unfortunately, there are so many such methods in my project and splitting them is a big and tedious task.

So I am looking for any alternate solution. Any help would be highly appreciated.

[Marc R. Hoffmann]

Hi,

please as a first step update to our latest release 0.7.9. This release
contains a fix specifically for large methods.

If the problem persists, please provide the full stack trace of exception.

Regards,
-marc

[Mirko Friedenhagen]

Another thought: running jacoco injects code for measuring coverage.
* Sample project: https://gitlab.com/mfriedenhagen/jacocosize
* Clone this project and run "mvn clean compile".
* On my machine the size of
target/classes/de/friedenhagen/jacocosize/App.class is 785 bytes.
* Running "mvn clean test-compile" will instrument the file
"statically" instead of on the fly.
* Now the above class has a size of 1028 bytes.
* According to http://stackoverflow.com/a/17422590/49132 the maximal
size of byte code in a Java method is 64K.

Maybe you are hitting this limit when JaCoCo instruments your classes?

Regards
Mirko
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/

> --
> 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/bc44ef5f-eb8c-3278-3503-6bea82bcedbe%40mountainminds.com.
>
> For more options, visit https://groups.google.com/d/optout.

[rahul.s...@gmail.com]

On Thursday, 9 February 2017 15:16:11 UTC-5, rahul.s...@gmail.com wrote:
> I am successfully using Jacoco except one issue. Jacoco throws errors when method body is very large. Is there any limitation on number of lines in a method? If yes can we increase that limit? Unfortunately, there are so many such methods in my project and splitting them is a big and tedious task.
>
> So I am looking for any alternate solution. Any help would be highly appreciated.

Thanks! I tried latest version jacoco-0.7.9 as you said. But it gives same error. As you suggested here is full exception trace. Please let me know your thoughts. Thanks again!!

java.lang.instrument.IllegalClassFormatException: Error while instrumenting class com/comp/xt/svc/Basxmcchglp1C00v02.
INFO | jvm 1 | 2017/02/14 16:30:21 | at org.jacoco.agent.rt.internal_8ff85ea.CoverageTransformer.transform(CoverageTransformer.java:93)
INFO | jvm 1 | 2017/02/14 16:30:21 | at sun.instrument.TransformerManager.transform(TransformerManager.java:188)
INFO | jvm 1 | 2017/02/14 16:30:21 | at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:424)
INFO | jvm 1 | 2017/02/14 16:30:21 | at java.lang.ClassLoader.defineClass1(Native Method)
INFO | jvm 1 | 2017/02/14 16:30:21 | at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
INFO | jvm 1 | 2017/02/14 16:30:21 | at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
INFO | jvm 1 | 2017/02/14 16:30:21 | at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2957)
INFO | jvm 1 | 2017/02/14 16:30:21 | at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1210)
INFO | jvm 1 | 2017/02/14 16:30:21 | at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1690)
INFO | jvm 1 | 2017/02/14 16:30:21 | at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1571)
INFO | jvm 1 | 2017/02/14 16:30:21 | at com.comp.xt.Rvd0x02.mainSubroutine(Rvd0x02.java:26)
INFO | jvm 1 | 2017/02/14 16:30:21 | at hx.mt.util.Process.run(Process.java:13)
INFO | jvm 1 | 2017/02/14 16:30:21 | at hx.mt.util.ProcessInfo.run(ProcessInfo.java:20)
INFO | jvm 1 | 2017/02/14 16:30:21 | at com.comp.xt.Rcd0xf06.mainSubroutine(Rcd0xf06.java:143)
INFO | jvm 1 | 2017/02/14 16:30:21 | at hx.mt.util.Process.run(Process.java:13)
INFO | jvm 1 | 2017/02/14 16:30:21 | at hx.mt.util.ProcessInfo.run(ProcessInfo.java:20)
INFO | jvm 1 | 2017/02/14 16:30:21 | at com.comp.pt.svc.util.Recv203.mainSubroutine(Pmscar203.java:435)
INFO | jvm 1 | 2017/02/14 16:30:21 | at hx.mt.util.Process.run(Process.java:13)
INFO | jvm 1 | 2017/02/14 16:30:21 | at hx.mt.util.ProcessInfo.run(ProcessInfo.java:20)
INFO | jvm 1 | 2017/02/14 16:30:21 | at com.comp.pt.svc.ctrl.Cycle01.mainSubroutine(Pmscoc01.java:1114)
INFO | jvm 1 | 2017/02/14 16:30:21 | at hx.mt.util.Process.run(Process.java:13)
INFO | jvm 1 | 2017/02/14 16:30:21 | at hx.mt.util.ProcessInfo.run(ProcessInfo.java:20)
INFO | jvm 1 | 2017/02/14 16:30:21 | at com.comp.pt.CycleController.StartDaily(Basstrcycl.java:125)
INFO | jvm 1 | 2017/02/14 16:30:21 | at com.comp.pt.custom.CycleController.mainSubroutine(Basstrcycl.java:82)
INFO | jvm 1 | 2017/02/14 16:30:21 | at hx.mt.util.Process.run(Process.java:13)
INFO | jvm 1 | 2017/02/14 16:30:21 | at hx.mt.util.ProcessInfo.run(ProcessInfo.java:20)
INFO | jvm 1 | 2017/02/14 16:30:21 | at hx.mt.util.DynamicCall.legacyInvoke(DynamicCall.java:271)
INFO | jvm 1 | 2017/02/14 16:30:21 | at hx.mt.util.DynamicCall.execute(DynamicCall.java:167)
INFO | jvm 1 | 2017/02/14 16:30:21 | at hx.mt.util.DynamicCall.invoke(DynamicCall.java:577)
INFO | jvm 1 | 2017/02/14 16:30:21 | at hx.mt.task.LegacyCustomTaskWrapper.invoke(LegacyCustomTaskWrapper.java:17)
INFO | jvm 1 | 2017/02/14 16:30:21 | at hx.mt.task.CustomTaskWrapper.run(CustomTaskWrapper.java:117)
INFO | jvm 1 | 2017/02/14 16:30:21 | at com.comp.pt.svc.custom.jobScheduler.QuartzAsyncJob.execute(QuartzAsyncJob.java:44)
INFO | jvm 1 | 2017/02/14 16:30:21 | at org.quartz.core.JobRunShell.run(Unknown Source)
INFO | jvm 1 | 2017/02/14 16:30:21 | at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(Unknown Source)
INFO | jvm 1 | 2017/02/14 16:30:21 | Caused by: java.io.IOException: Error while instrumenting class com/comp/xt/svc/Basxmcchglp1C00v02.
INFO | jvm 1 | 2017/02/14 16:30:21 | at org.jacoco.agent.rt.internal_8ff85ea.core.instr.Instrumenter.instrumentError(Instrumenter.java:166)
INFO | jvm 1 | 2017/02/14 16:30:21 | at org.jacoco.agent.rt.internal_8ff85ea.core.instr.Instrumenter.instrument(Instrumenter.java:117)
INFO | jvm 1 | 2017/02/14 16:30:21 | at org.jacoco.agent.rt.internal_8ff85ea.CoverageTransformer.transform(CoverageTransformer.java:91)
INFO | jvm 1 | 2017/02/14 16:30:21 | ... 33 more
INFO | jvm 1 | 2017/02/14 16:30:21 | Caused by: java.lang.RuntimeException: Method code too large!
INFO | jvm 1 | 2017/02/14 16:30:21 | at org.jacoco.agent.rt.internal_8ff85ea.asm.MethodWriter.getSize(MethodWriter.java:2079)
INFO | jvm 1 | 2017/02/14 16:30:21 | at org.jacoco.agent.rt.internal_8ff85ea.asm.ClassWriter.toByteArray(ClassWriter.java:838)
INFO | jvm 1 | 2017/02/14 16:30:21 | at org.jacoco.agent.rt.internal_8ff85ea.core.instr.Instrumenter.instrument(Instrumenter.java:91)
INFO | jvm 1 | 2017/02/14 16:30:21 | at org.jacoco.agent.rt.internal_8ff85ea.core.instr.Instrumenter.instrument(Instrumenter.java:114)
INFO | jvm 1 | 2017/02/14 16:30:21 | ... 34 more

[rahul.s...@gmail.com]

Thanks! So cant we increase this limit by any setting provided by Jacoco?

[Evgeny Mandrikov]

Hi,

As previously was already said by Mirko: there is a limit on a size of method in Java Virtual Machine - 64K.

Your method is already big, but a bit below this limit.

In order to provide you coverage JaCoCo adds few instructions into the method. And after that method crosses JVM limit.

So all in all - the only options are:

either exclude method from instrumentation and hence from coverage analysis,

either change code of a method to split it on several smaller ones.

Hope this clarifies and helps.

Evgeny

[rahul.s...@gmail.com]

Thank you so much! I have one more question please suggest if I should post this in another thread.

I have used JaCoCo report (jacoco.exec) in SonarQube and Eclipse through EclEmma and noticed that Eclipse shows roughly half coverage of what SonarQube displays. Is there any setting required in Eclipse? As eclipse has .java and .class files both so can that make this difference.

[Evgeny Mandrikov]

On Wednesday, February 15, 2017 at 3:25:00 AM UTC+1, rahul.s...@gmail.com wrote:

Thank you so much! I have one more question please suggest if I should post this in another thread.

 

Yes, it is better to have separate threads for completely separate questions.

 

I have used JaCoCo report (jacoco.exec) in SonarQube and Eclipse through EclEmma and noticed that Eclipse shows roughly half coverage of what SonarQube displays. Is there any setting required in Eclipse? As eclipse has .java and .class files both so can that make this difference.

Bear in mind that

Generation of report requires exact same class files that were used to construct exec file - see http://www.jacoco.org/jacoco/trunk/doc/classids.html

Eclipse uses own compiler (ECJ) to create class files and they are different from classes produced by javac.

EclEmma allows to execute tests with coverage, so actually you don't need to import existing exec file.