Recent changes to bugs

#103 EclEmma 2.0 can't handle test fragments

Marc R. Hoffmann — Mon, 27 May 2013 08:47:51 -0000

status: pending --> closed-works-for-me
Group: --> Version 2.1.4

dead lock accrue.

Anonymous — Thu, 13 Dec 2012 07:17:32 -0000

Dead lock accrue. AppClassLoader tries to load class form ExtClassLoader and ExtClassLoader try to load class from AppClassLoader.
In my configuration AppClassLoader is excluded. So dead lock should not accrue. Is there any workaround

<jacoco:coverage enabled="@{test.coverage}" destfile="${coverage.File}" includes="com.xxx.tool.*:com.xxx.ci.*:com.nomagic.cts.*:com.xxx.common.*"
excludes="org.*:java.*:com.xxx.rcpf.*:com.xxx.registration.*:sun.*:javax.*:com.oracle.*:com.sun.*" exclclassloader="sun.misc.Launcher$AppClassLoader:sun.reflect.DelegatingClassLoader">

Most our class is loaded by ExtClassLoader.

"pool-tool-thread-1:Loading..." prio=10 tid=0x00007fde1c070800 nid=0x63e7 waiting for monitor entry [0x00007fde1a77f000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.jacoco.agent.rt_mlrowg.CoverageTransformer.transform(CoverageTransformer.java:78)
at sun.instrument.TransformerManager.transform(TransformerManager.java:169)
at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at sun.misc.Launcher$ExtClassLoader.findClass(Launcher.java:229)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
- locked <0x00000000b58a44a0> (a sun.misc.Launcher$ExtClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at com.xxx.tool.persistence.ci.d.j.<init>(j.java:151)
at com.xxx.tool.persistence.ci.d.d.doCreateProject(d.java:76)
at com.xxx.ci.persistence.spi.local.LocalProjectOpenUtil.createProject(LocalProjectOpenUtil.java:84)
at com.xxx.ci.persistence.spi.local.LocalProjectOpenUtil.doOpenProject(LocalProjectOpenUtil.java:53)
at com.xxx.ci.persistence.spi.local.LocalProjectRepository.doOpenProject(LocalProjectRepository.java:92)
at com.xxx.ci.persistence.spi.ProjectOpenUtil.doOpenProject(ProjectOpenUtil.java:50)
at com.xxx.ci.persistence.spi.ProjectOpenUtil.openProject(ProjectOpenUtil.java:34)
at com.xxx.ci.persistence.spi.DefaultProjectRepository.openProject(DefaultProjectRepository.java:218)
at com.xxx.tool.persistence.ProjectLoadService.loadStorage(ProjectLoadService.java:310)
at com.xxx.tool.persistence.ProjectLoadService.load(ProjectLoadService.java:203)
at com.xxx.tool.persistence.ProjectLoadService.load(ProjectLoadService.java:163)
at com.xxx.tool.persistence.ProjectLoadService.loadAndHandleErrors(ProjectLoadService.java:54)
at com.xxx.tool.persistence.ProjectLoadService$1.execute(ProjectLoadService.java:109)
at com.xxx.task.Task.construct(Task.java:188)
at com.xxx.task.SwingWorker$3.call(SwingWorker.java:227)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at com.xxx.task.SwingWorker$SwingWorkerFuture.run(SwingWorker.java:573)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at com.xxx.task.PooledThread.run(PooledThread.java:64)

"Thread-20" prio=10 tid=0x00007fde5dbdf800 nid=0x63e6 waiting for monitor entry [0x00007fde2a372000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.ClassLoader.loadClass(ClassLoader.java:291)
- waiting to lock <0x00000000b58a44a0> (a sun.misc.Launcher$ExtClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
- locked <0x00000000b58a4458> (a sun.misc.Launcher$AppClassLoader)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
- locked <0x00000000b58a4458> (a sun.misc.Launcher$AppClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.beans.Introspector.instantiate(Introspector.java:1470)
at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
at java.beans.Introspector.<init>(Introspector.java:380)
at java.beans.Introspector.getBeanInfo(Introspector.java:167)
at org.apache.axis.utils.BeanUtils$1.run(BeanUtils.java:92)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.axis.utils.BeanUtils.getPropertyDescriptors(BeanUtils.java:73)
at org.apache.axis.utils.BeanUtils.getPd(BeanUtils.java:63)
at org.apache.axis.description.TypeDesc.makePropertyDescriptors(TypeDesc.java:460)
- locked <0x00000000fed08428> (a org.apache.axis.description.TypeDesc)
at org.apache.axis.description.TypeDesc.getPropertyDescriptors(TypeDesc.java:439)
at org.apache.axis.encoding.ser.BeanSerializerFactory.init(BeanSerializerFactory.java:56)
at org.apache.axis.encoding.ser.BeanSerializerFactory.<init>(BeanSerializerFactory.java:42)
at org.apache.axis.encoding.ser.BaseSerializerFactory.createFactory(BaseSerializerFactory.java:235)
at org.apache.axis.client.Call.registerTypeMapping(Call.java:2315)
at com.xxx.registration.user.Registration_serviceSoapBindingStub.createCall(Unknown Source)
- locked <0x00000000feda1040> (a com.xxx.registration.user.Registration_serviceSoapBindingStub)
at com.xxx.registration.user.Registration_serviceSoapBindingStub.checkActivation(Unknown Source)
at com.xxx.rcpf.product.c.a.n.w(n.java:405)
at com.xxx.rcpf.product.p$0.run(p$0.java:360)
at java.lang.Thread.run(Thread.java:662)

Found one Java-level deadlock:

"pool-MagicDraw-thread-1:Loading...":
waiting to lock monitor 0x00007fde4c0359e0 (object 0x00000000b58a4458, a sun.misc.Launcher$AppClassLoader),
which is held by "Thread-20"
"Thread-20":
waiting to lock monitor 0x00007fde4c035a88 (object 0x00000000b58a44a0, a sun.misc.Launcher$ExtClassLoader),
which is held by "pool-tool-thread-1:Loading..."

Coverage report wrongly reporting 100% coverage

Eduardo Simioni — Wed, 28 Nov 2012 17:18:49 -0000

When the coverage on a project is very high, but still a few branches are not covered, EclEmma reports 100% coverage. I had 2 instructions missed in 5649 and it reported the module as 100% covered.
Probably this is due to some rounding, but in this case I would rather have a round down instead of a round up. If it had reported 99.9% I would've noticed much earlier that something was not covered.

Version: EclEmma 2.2.0.201210261515

infinite wait on EclEmma "Loading..." after JUnit tests run

Jeslie Chermak — Fri, 21 Sep 2012 01:58:03 -0000

I was running Eclipse Juno (Build id: 20120614-1722) with EclEmma 2.1.4.201208011137 and Eclipse EGit 2.0.0.201206130900 (among other plug-ins). I have 100 JUnit-based tests that take about 1 second to run. Getting code coverage based on that run takes less than an additional second. Normally ...

1) I ran the tests w/coverage and looked at the results.
2) I exited Eclipse
3) I moved the test data files
4) I "informed" git about the changes and did a "git commit"
5) I restarted Eclipse
BOOM
6) I can still run the JUnit tests, but _no_ coverage data! I get an infinite wait on the "Loading..." message in the "Coverage" tab.

There is nothing in the "Problems" tab. Based on another (related) EclEmma bug (recorded on the Eclipse website), I checked the .log file and found the (attached) log fragment. It seems that the moved data files are messing up EclEmma.

WORKAROUND:
Doing an F5 (Refresh) on the "Package Explorer" tab resolves the problem. (Nothing else, including Eclipse restarts, seems to work.)

-- Configuration Details --
Product: Eclipse 1.5.0.20120131-1544 (org.eclipse.epp.package.jee.product)
Installed Features:
org.eclipse.platform 4.2.0.v20120608-135145-9JF7BHV8FyMteji0Oi_ePMz0xuZ8TVo7lV0z0ecb
[reply] [-] Comment 1

jacoco:report behaves poorly when jacoco.exec missing

Jesse Glick — Thu, 30 Aug 2012 19:14:33 -0000

I want to run my Maven project's tests under JaCoCo, so I add to build/plugins:

<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.5.9.201207300726</version>
<executions>
<execution>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>report</id>
<phase>prepare-package</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>

This works but for one issue. If I am doing a build without tests:

$ mvn -DskipTests clean package

then the report goal prints a big messy stack trace:

[jacoco:report]
Unable to read execution data file .../target/jacoco.exec: .../target/jacoco.exec (No such file or directory)
java.io.FileNotFoundException: .../target/jacoco.exec (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:138)
at org.jacoco.maven.ReportMojo.loadExecutionData(ReportMojo.java:251)
at org.jacoco.maven.ReportMojo.executeReport(ReportMojo.java:228)
at org.jacoco.maven.ReportMojo.execute(ReportMojo.java:217)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
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)

If jacoco.exec is missing, it should just assume that tests were not run at all, and print a one-line warning.

I tried to work around this by enabling the plugin only in a profile with

<activation>
<property>
<name>!skipTests</name>
</property>
</activation>

but this is worse: JaCoCo is incorrectly disabled when running with -DskipTests=false. http://jira.codehaus.org/browse/MNG-3328 makes it hard to work around this - you have to create two profiles.

Conflict with other Java agents

Anonymous — Tue, 21 Aug 2012 17:44:20 -0000

Using JaCoCo 0.5.10 and JMockit 0.999.16, a deadlock occurs when the JaCoCo CoverageTransformer receives a class being redefined by JMockit.

The following (partial) thread dump shows what happens at runtime, just after the deadlock:

"Attach Listener" daemon prio=10 tid=0x0076cc00 nid=0x618 in Object.wait() [0x00eee000]
java.lang.Thread.State: RUNNABLE
at sun.misc.Unsafe.ensureClassInitialized(Native Method)
at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:43)
at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:140)
at java.lang.reflect.Field.acquireFieldAccessor(Field.java:949)
at java.lang.reflect.Field.getFieldAccessor(Field.java:930)
at java.lang.reflect.Field.set(Field.java:680)
at org.jacoco.agent.rt_cdwjjf.core.runtime.AbstractRuntime.disconnect(AbstractRuntime.java:90)
at org.jacoco.agent.rt_cdwjjf.CoverageTransformer.transform(CoverageTransformer.java:90)
at sun.instrument.TransformerManager.transform(TransformerManager.java:188)
at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:424)
at sun.instrument.InstrumentationImpl.redefineClasses0(Native Method)
at sun.instrument.InstrumentationImpl.redefineClasses(InstrumentationImpl.java:170)
at mockit.internal.startup.Startup.redefineMethods(Startup.java:124)
at mockit.internal.startup.Startup.redefineMethods(Startup.java:118)
at mockit.internal.annotations.MockClassSetup.applyClassModifications(MockClassSetup.java:162)
at mockit.internal.annotations.MockClassSetup.redefineMethodsInClassHierarchy(MockClassSetup.java:128)
at mockit.internal.annotations.MockClassSetup.redefineMethods(MockClassSetup.java:117)
at mockit.internal.annotations.MockClassSetup.setUpStartupMock(MockClassSetup.java:111)
at mockit.internal.startup.JMockitInitialization.setUpInternalStartupMock(JMockitInitialization.java:56)
at mockit.internal.startup.JMockitInitialization.loadInternalStartupMocksForJUnitIntegration(JMockitInitialization.java:48)
at mockit.internal.startup.JMockitInitialization.initialize(JMockitInitialization.java:26)
at mockit.internal.startup.Startup.initialize(Startup.java:68)
at mockit.internal.startup.Startup.agentmain(Startup.java:62)
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 sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:382)
at sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:407)

"main" prio=6 tid=0x0034c000 nid=0x10d0 runnable [0x0069e000]
java.lang.Thread.State: RUNNABLE
at sun.tools.attach.WindowsVirtualMachine.connectPipe(Native Method)
at sun.tools.attach.WindowsVirtualMachine.execute(WindowsVirtualMachine.java:100)
at sun.tools.attach.HotSpotVirtualMachine.loadAgentLibrary(HotSpotVirtualMachine.java:58)
at sun.tools.attach.HotSpotVirtualMachine.loadAgentLibrary(HotSpotVirtualMachine.java:79)
at sun.tools.attach.HotSpotVirtualMachine.loadAgent(HotSpotVirtualMachine.java:103)
at mockit.internal.startup.JDK6AgentLoader.loadAgentAndDetachFromThisVM(JDK6AgentLoader.java:117)
at mockit.internal.startup.JDK6AgentLoader.loadAgent(JDK6AgentLoader.java:61)
at mockit.internal.startup.AgentInitialization.initializeAccordingToJDKVersion(AgentInitialization.java:21)
at mockit.internal.startup.Startup.initializeIfNeeded(Startup.java:98)
at mockit.internal.startup.Startup.initializeIfPossible(Startup.java:112)
at org.junit.runner.Runner.<clinit>(Runner.java:22)
at ... (other JUnit and IDE-specific entries)

The attached zip file should allow you to reproduce it (I used IntelliJ IDEA, but should work with Eclipse too, provided you add "-javaagent:jacocoagent.jar" to the JVM command line). For more details, see the original issue in the JMockit project: http://code.google.com/p/jmockit/issues/detail?id=239

This can only be solved on JaCoCo's side, I suspect, but I am willing to make changes to JMockit if needed. Let me know you need anything more. Thanks.

Maven Report goal fails on missing classes directory

Jens — Thu, 16 Aug 2012 21:40:39 -0000

Version 0.5.9
Maven 3.0.4

The maven plugins fails, if the project contains only test classes and there fore the folder target/classes is missing.

Suggestion to quick fix the problem: check if the folder exists

IBundleCoverage createBundle() throws IOException {
final CoverageBuilder builder = new CoverageBuilder();
final Analyzer analyzer = new Analyzer(executionDataStore, builder);
final File classesDir = new File(getProject().getBuild()
.getOutputDirectory());

if( classDir.exists() == true ) {
final List<File> filesToAnalyze = getFilesToAnalyze(classesDir);

if( filesToAnalyze.size() != 0 ) {
for (final File file : filesToAnalyze) {
analyzer.analyzeAll(file);
}
} else {
log().info("no classes found to added for analyse");
}
} else {
log().info("no output folder found and noclassed added for analyse");
}

return builder.getBundle(getProject().getName());
}

I'm not sure if this will fix the problem in generell, because I do not know what happens if the CovarageBuilder contains no classes.

Kind Regards,

Jens

Surefire java.endorsed.dirs causes no jacoco.exec

Steven P. Goldsmith — Fri, 10 Aug 2012 17:00:58 -0000

maven-surefire-plugin with <argLine>-Djava.endorsed.dirs="${endorsed.dir}"</argLine> causes no jacoco.exec to be generated. I used the java.endorsed.dirs mechanism, so my tests can run with the latest Jax-WS jars. Below is the configuration:

<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.5.9.201207300726</version>
<executions>
<execution>
<id>prepare-agent</id>
<phase>process-test-resources</phase>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
</executions>
</plugin>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12.1</version>
<configuration>

<argLine>-Djava.endorsed.dirs="${endorsed.dir}"</argLine>
<includes>
<include>**/*Test.java</include>
</includes>
<skipTests>${tests.skip}</skipTests>
</configuration>
</plugin>

Crashing bug

Derek — Wed, 01 Aug 2012 16:22:20 -0000

With the last 2 releases (so starting in 0.5.8) we've been hitting a crashing bug in which garbage collection operations seem to cause a crash of the JVM. This only seems to occur with coverage enabled (so not when running under the debugger or normally). This also does not reproduce with versions of JaCoCo prior to the last 2. Sorry I don't have more information - I'm trying to narrow down some repro steps but this bug only reproduces for one of our larger tests suites so that would be a lot of code to get running. I've tried playing around with the memory settings and even with a lot of perm-gen and heap memory the issue still reproduces. I've also tried Java 6 and 7 and both reproduce the issue as well.

Session export fails on common source folder postfixes

Anonymous — Thu, 26 Jul 2012 17:53:01 -0000

When using a project with multiple source folders where the last section of the path name is identical, session export produces erroneous results. An example project would be a standard maven module with source folders
src/main/java
src/test/java
The session view will list both folders, but when exporting the group names will be shortened to "java" for both source folders. This produces various bugs:

When using html export, the project view lists two source folders, both named "java", where one has the coverage values for src/main/java and the other for src/test/java. however, since both are exported into a folder subfolder named java, the source folder view you get is the same in both cases, since the first exported overview index file is overwritten by the second one. Effectively, the data for one of the source folders becomes inaccessible.

When using html as zipped file, the export will even fail, because the zip exporter throws an exception when a second project/java/index.html file is attempted to be packaged into the zip file.

For XML export, the same thing occurs where the xml file contains two <group name="java"> elements for the project, i'm not sure if this causes any problems anywhere, but it certainly isn't healthy. I would expect similar behavior for exported JaCoCo exec files.

I tested this on 2.1.1, but could not verify it with 2.1.3, because i can't start my test suite as coverage run with that version anymore, no clue why that is but it's most certainly unrelated. I assume the issue still occurs in 2.1.3 as i didn't find any issues on that topic until now. I don't think my system specs are of any relevance for this issue, but just in case, i'm running java7u2 64bit under win7 64bit and am using the eclemma plugin with Indigo SR2.

As a workaround, the source folder filter can be set to only include src/main/java and create one session and export it, and then src/test/java and create a second session and export it. But i feel, rather than replacing some/source/dir by dir, it might be better to either leave it at some/source/dir, or - if for file format reasons this is not possible - make it some_source_dir or something similar instead.