New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide Context Information when Exception happen in Analyzer or Instrumenter #104

Merged
merged 1 commit into from May 27, 2013

Conversation

Projects
None yet
5 participants
@marchof
Member

marchof commented May 27, 2013

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 comment has been minimized.

Show comment
Hide comment
@marchof

marchof May 19, 2013

Member

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).

Member

marchof commented May 19, 2013

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

This comment has been minimized.

Show comment
Hide comment
@cowwoc

cowwoc May 19, 2013

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?

cowwoc commented May 19, 2013

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

This comment has been minimized.

Show comment
Hide comment
@marchof

marchof May 19, 2013

Member

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.

Member

marchof commented May 19, 2013

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

This comment has been minimized.

Show comment
Hide comment
@cowwoc

cowwoc May 19, 2013

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.

cowwoc commented May 19, 2013

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

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin May 20, 2013

Member

@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) ;)

Member

Godin commented May 20, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@marchof

marchof May 20, 2013

Member

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.

Member

marchof commented May 20, 2013

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

This comment has been minimized.

Show comment
Hide comment
@cowwoc

cowwoc May 20, 2013

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 :)

cowwoc commented May 20, 2013

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

This comment has been minimized.

Show comment
Hide comment
@marchof

marchof May 20, 2013

Member

@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.

Member

marchof commented May 20, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin May 20, 2013

Member

@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).

Member

Godin commented May 20, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@cowwoc

cowwoc May 24, 2013

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.

cowwoc commented May 24, 2013

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

This comment has been minimized.

Show comment
Hide comment
@andrioli

andrioli May 24, 2013

Contributor

@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?

Contributor

andrioli commented May 24, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@cowwoc

cowwoc May 24, 2013

@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.

cowwoc commented May 24, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@marchof

marchof May 25, 2013

Member

@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.

Member

marchof commented May 25, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@cowwoc

cowwoc May 25, 2013

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

cowwoc commented May 25, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@marchof

marchof May 25, 2013

Member

@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.

Member

marchof commented May 25, 2013

@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.

Context information for error messages.
Analyzer and Instrumenter now expect a resource name parameter to
provide better messages in case of internal errors.
@buildhive

This comment has been minimized.

Show comment
Hide comment
@buildhive

buildhive commented May 27, 2013

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

marchof added a commit that referenced this pull request May 27, 2013

Merge pull request #104 from jacoco/issue-104
Provide context information when exceptions happen in Analyzer or Instrumenter

@marchof marchof merged commit c1936b5 into master May 27, 2013

1 check passed

default The Travis CI build passed
Details

@marchof marchof deleted the issue-104 branch May 27, 2013

@jacoco jacoco locked and limited conversation to collaborators Jan 11, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.