Provide Context Information when Exception happen in Analyzer or Instrumenter

[marchof]

Hi,

I consistently get the following exception when running Jacoco against my (commercial) project. What can I do to help you correct this bug without sending you my source code? Can you add more logging and have me re-run the operation?

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jacoco:jacoco-maven-plugin:0.6.2.201302030002:report (report) on project server.web: Execution report of goal org.jacoco:jacoco-maven-plugin:0.6.2.201302030002:report failed: 48188
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
    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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution report of goal org.jacoco:jacoco-maven-plugin:0.6.2.201302030002:report failed: 48188
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
    ... 19 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: 48188
    at org.objectweb.asm.ClassReader.readClass(Unknown Source)
    at org.objectweb.asm.ClassReader.accept(Unknown Source)
    at org.objectweb.asm.ClassReader.accept(Unknown Source)
    at org.jacoco.core.analysis.Analyzer.analyzeClass(Analyzer.java:94)
    at org.jacoco.core.analysis.Analyzer.analyzeClass(Analyzer.java:115)
    at org.jacoco.core.analysis.Analyzer.analyzeAll(Analyzer.java:155)
    at org.jacoco.core.analysis.Analyzer.analyzeArchive(Analyzer.java:135)
    at org.jacoco.core.analysis.Analyzer.analyzeAll(Analyzer.java:158)
    at org.jacoco.core.analysis.Analyzer.analyzeAll(Analyzer.java:183)
    at org.jacoco.maven.BundleCreator.createBundle(BundleCreator.java:67)
    at org.jacoco.maven.ReportMojo.createReport(ReportMojo.java:262)
    at org.jacoco.maven.ReportMojo.executeReport(ReportMojo.java:235)
    at org.jacoco.maven.ReportMojo.execute(ReportMojo.java:220)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
    ... 20 more

[marchof]

This typically happens for invalid class files. Do you apply any post processing to your class files? Are you using Java 8 (not yet supported by JaCoCo)?

To track this down you can privately send me a class file which has this problem (source not required).

[cowwoc]

Let's begin with the fact that JaCoCo doesn't report which class file it has the problem with.

I am not using any post processing or Java 8. As far as I know, all class files are being produced by javac 7u21.

How do I find out which class file is at fault? Can you add logging for this if it doesn't already exist?

[marchof]

Unfortunately there is no way to log the class name. Internally JaCoCo works on InputStreams only. If the class file can't be parsed at all we even don't now it's name...

The only way to find the problematic file is to narrow it down with the includes configuration.

[cowwoc]

Marc,

You could log the filename at org.jacoco.core.analysis.Analyzer line 183. Please produce a SNAPSHOT build with this extra log and I will test it for you.

[Godin]

@cowwoc I'm wondering why you can't do build with such modification by yourself? And this might be a good opportunity to contribute to the project (pull-requests exactly for this) ;)

[marchof]

We don't do any logging in the JaCoCo core yet and I don't want to introduce this. Also the proposal of @cowwoc only works for the specific case that a java.io.File instance which actually is a class file is passed to the API. InputStreams and JARs will not get proper logging.

Instead of logging I would rather propose to wrap such exceptions in a exception which provides context information.

[cowwoc]

Guys,

You're making this a lot more complicated than it needs to be. The specific stack-trace I reported uses java.io.File so logging (or throwing an exception) will work just fine. Everyone has a different level of contribution they're able to provide and at this point this is as far as I can go. Please understand, I'm active in many open-source projects and I don't have the mental bandwidth to sink my teeth into another one at this time :)

[marchof]

@cowwoc Sorry for appearing too complicated here. Please also understand that JaCoCo is basically a library used in quite a few integrations. That's why I'm a bit conservative about introducing code which helps in specific situation only and makes the APIs inconsistent.

Any chance that you build a local version with additional logging? Alternatively I can do this for you, in this case you need to install the artifact in your local repo manually.

In parallel I try to find a way to provide more meaningful exceptions.

[Godin]

@cowwoc No need to sink teeth ;) The only purpose of my comment was to highlight the fact that you can quickly build JaCoCo locally ( git clone ... && mvn install ) with logging at org.jacoco.core.analysis.Analyzer line 183 (as proposed by you) to find the class, which causes exception, and which was requested by @marchof in first comment. Right now this is a best way to find root cause of exception, instead of waiting implementation of logging. And if this cause is on JaCoCo side, then maybe it will be fixed even before introduction of logging.

And indeed - sorry, but we are very careful about API changes (what was treated as over-complication by you).

[cowwoc]

The problem was caused by Findbugs referencing XOM 1.0 which references icu4j 2.6.1 which contains an invalid class format: http://icu-project.org/trac/ticket/6505 ... This was fixed in icu4j 2.8.

I worked around the problem by forcing Findbugs to use a newer version of icu4j.

Please convert this issue into a feature request for logging the source (JAR or class path) when an exception is thrown.

[andrioli]

@cowwoc why jacoco is analyzing icu4j 2.6.1 jar/package ? My question is: why your include rules does not limit which classes jacoco should analyze?

[cowwoc]

@andrioli Honestly, I didn't think about it until you mentioned it. Most Jacoco documentation floating around the web didn't mention . I assumed that jacoco was smart enough to only pick up my main project's class files but obviously it can't perform miracles. Logging could have helped a little here too. Currently all I see is:

[jacoco:report]

and that's it.

On a side-note, what's the difference between for prepare-agent and report? I tried only applying to "prepare-agent" but "report" ended up generating reports for other classes not included in "prepare-agent". I was expecting the report to only contain instrumented classes.

[marchof]

@cowwoc The basic idea of JaCoCo is to simply collect execution information for all non-system classes loaded to the VM. At report generation time you decide what the scope of your report should be. In the HTML report there is a link in the top right corner "Sessions". It lists all classes which have been loaded.

[cowwoc]

@marchof is there any value to reporting on non-instrumented classes? If not, shouldn't report's be a subset of prepare-agent's ?

[marchof]

@cowwoc Instrumentation with the JaCoCo agents happens on-the-fly, i.e. only classes which are loaded during test execution get instrumented. In the report you typically want to see all classes under test to detect classes missed at all.

Talking about configuration of Maven goals: Except for specific technical limitations there is no reason to configure any includes/excludes at all for prepare-agent. We could consider using a separate config for the agent.

[buildhive]

Java Code Coverage Tools » jacoco #71 SUCCESS
This pull request looks good
(what's this?)