JaCoCo execution data are incomplete

[Nils]

Hi,

we have a web application run by Glassfish using four clusters. Using the Glassfish configuration, we have attached JaCoCo as Java agent to each of these clusters. So far everything works as expected: We get four exec-files, each of which contains the execution data for one of our clusters.

Now, our problem is: the data are incomplete. There are methods that were definitely executed but are not recorded as such by JaCoCo. We have verified the execution with the debugger and breakpoints, but JaCoCo does not recognize these methods as executed. Here is some additional info:

- A great deal of the webapp's methods are correctly recognized as executed, others are not. So it seems to work 'partly'. We were not able to identify a pattern.

- We have disabled all others agents that might conflict with JaCoCo.

- JaCoCo is 0.7.7.

- The compiled and runtime version of the classes is the same (no runtime magic that modifies the classes).

- It's not a matter of report generation. We've checked the data via the Java API directly in the exec-files.

- There are no processes or other JVMs spawned that might run without JaCoCo attached.

After some days of debugging, we ran out of ideas what might cause JaCoCo to not record some of our methods. If someone has an idea, we would be very thankful.

Thanks in advance,
Nils

[Evgeny Mandrikov]

Hi,

Granularity of JaCoCo instrumentation - is a class level, not method, so could you please clarify: do you see

classes, where JaCoCo sees some of methods as executed and some as not

or

classes, where no methods executed

?

Could you please provide some screenshot(s) from JaCoCo report ?

[Nils]

You're right, that was a bit misleading.

We are talking about complete classes where JaCoCo sees all methods as not executed (although some were executed).

Unfortunately, I cannot provide screenshots due to disclosure reasons, but if you tell me which information you look for, I try to provide it to you. We have not created a report yet, because the execution data is already incomplete in the exec files.

[Evgeny Mandrikov]

Let's forget about screenshots - this was mainly for the first case.

You can use agent option "classdumpdir" to confirm that those classes are really skipped from instrumentation for some reason - http://www.eclemma.org/jacoco/trunk/doc/agent.html

If they won't be dumped, then they were filtered prior to instrumentation (see https://github.com/jacoco/jacoco/blob/master/org.jacoco.agent.rt/src/org/jacoco/agent/rt/internal/CoverageTransformer.java#L85 ). The only reasons to be filtered ( see https://github.com/jacoco/jacoco/blob/master/org.jacoco.agent.rt/src/org/jacoco/agent/rt/internal/CoverageTransformer.java#L113-L132 ):

• they are explicitly excluded / not included according to your configuration
• their class loader excluded according to your configuration ( see agent option "exclclassloader", which defaults to "sun.reflect.DelegatingClassLoader" )
• their class loader does not preserve source location ( see agent option "inclnolocationclasses", which defaults to "false" )
  
• they are loaded by a bootstrap class loader
  

Hope this will help in investigations to pinpoint root of the problem.

And will be interesting to know results of investigations in any case at least to share them with community for posterity.

--
You received this message because you are subscribed to a topic in the Google Groups "JaCoCo and EclEmma Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jacoco/9UUoA28GvB8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jacoco+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/486db23d-8bdc-4d16-83aa-78ac9744cdd8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nils]

Hi,

just to inform you, the problem was that there was in fact JaCoCo 0.7.6 still enabled in one central location. So essentially we were affected by https://github.com/jacoco/jacoco/pull/397 and did not recognize that all our trace files are broken.

The reason for the files being broken/incomplete is that Glassfish kills every JVM process 120 seconds after sending the shutdown signal. So JaCoCo does not manage to dump the execution data in these two minutes (it writes approx. 250 Kb per minute). I suspect, however, that this is not a JaCoCo problem but a network issue (data are written to a network share).

[Evgeny Mandrikov]

Glad that you found the root of the problem!

I would say that there is indeed no issue on JaCoCo side:

"dumponexit" agent option (defaults to "true") causes dump to be executed as part of JVM shutdown hooks sequence - 

https://docs.oracle.com/javase/7/docs/api/java/lang/Runtime.html#addShutdownHook(java.lang.Thread) , abort of sequence correctly results in corrupted file. 

Procedure of saving is pretty lightweight ( https://github.com/jacoco/jacoco/blob/master/org.jacoco.core/src/org/jacoco/core/data/ExecutionDataWriter.java ) and uses lightweight compression ( https://github.com/jacoco/jacoco/blob/master/org.jacoco.core/src/org/jacoco/core/internal/data/CompactDataOutput.java ). So not sure that it can be made faster and thus you probably indeed face a network issue.

However what you could do is to request JaCoCo dump prior to shutdown using JMX interface named "org.jacoco:type=Runtime" - see agent option "jmx", which defaults to "false".

And thank you for the notification.