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

Conflict with jmockit #35

Merged
merged 1 commit into from Mar 24, 2014

Conversation

Projects
None yet
@marchof
Member

marchof commented Mar 23, 2014

An incompatibility with jmockit seems to have been introduced in version 0.5.8 and still exists in 0.6.0 (no problems found with version 0.5.7). Full stacktrace with 0.5.8 below (some class names have been removed). Note: With 0.5.10, the exception is in org.jacoco.agent.rt_kqcpih.CoverageTransformer.transform(CoverageTransformer.java:91)

java.lang.instrument.IllegalClassFormatException: Error while instrumenting class xxxxxxxx.
    at org.jacoco.agent.rt_1r70et.CoverageTransformer.transform(CoverageTransformer.java:94)
    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.RedefinitionEngine.redefineMethods(RedefinitionEngine.java:63)
    at mockit.internal.expectations.mocking.DynamicPartialMocking.redefineTypes(DynamicPartialMocking.java:34)
    at mockit.internal.expectations.RecordAndReplayExecution.applyDynamicPartialMocking(RecordAndReplayExecution.java:203)
    at mockit.internal.expectations.RecordAndReplayExecution.<init>(RecordAndReplayExecution.java:108)
    at mockit.Expectations.<init>(Expectations.java:180)
    at xxxxxxxxxxxxTest$8.<init>(xxxxxxxxxxxTest.java:111)
    at xxxxxxxxx(xxxxxxxxxxTest.java:111)
    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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
    at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
    at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
    at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
    at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
    at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
    at org.testng.TestRunner.privateRun(TestRunner.java:767)
    at org.testng.TestRunner.run(TestRunner.java:617)
    at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
    at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
    at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
    at org.testng.SuiteRunner.run(SuiteRunner.java:240)
    at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
    at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
    at org.testng.TestNG.runSuitesSequentially(TestNG.java:1198)
    at org.testng.TestNG.runSuitesLocally(TestNG.java:1123)
    at org.testng.TestNG.run(TestNG.java:1031)
    at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77)
    at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:159)
    at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:99)
    at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:106)
    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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
    at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
    at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
    at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
@marchof

This comment has been minimized.

Member

marchof commented Oct 24, 2012

Can you please post the part of the stack trace after "Caused by"?

@assylias

This comment has been minimized.

assylias commented Oct 24, 2012

I have managed to reproduce the error with a contrived example:

import mockit.Expectations;
import org.testng.annotations.Test;
import static org.testng.Assert.*;

public class JacocoErrorTest {

    @Test(groups = "unit")
    public void test() throws Exception {
        new Expectations(Utility.class) {
            {
                Utility.getClassFlag();
                result = false;
            }
        };
    }

    static class Utility {
        public static boolean getClassFlag() {
            if (getFalse()) {
                return false;
            }
            return true;
        }

        public static boolean getFalse() {
            return false;
        }
    }
}

The output of Maven is (running mvn test -e - there is no "caused by" section):

java.lang.instrument.IllegalClassFormatException: Error while instrumenting class aaaaaaa/bbbbbbbconnector/JacocoErrorTest$Utility.
at org.jacoco.agent.rt_1r70et.CoverageTransformer.transform(CoverageTransformer.java:94)
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.RedefinitionEngine.redefineMethods(RedefinitionEngine.java:63)
at mockit.internal.expectations.mocking.DynamicPartialMocking.redefineTypes(DynamicPartialMocking.java:34)
at mockit.internal.expectations.RecordAndReplayExecution.applyDynamicPartialMocking(RecordAndReplayExecution.java:203)
at mockit.internal.expectations.RecordAndReplayExecution.<init>(RecordAndReplayExecution.java:108)
at mockit.Expectations.<init>(Expectations.java:180)
at aaaaaaa.bbbbbbbconnector.JacocoErrorTest$1.<init>(JacocoErrorTest.java:30)
at aaaaaaa.bbbbbbbconnector.JacocoErrorTest.test(JacocoErrorTest.java:30)
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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1198)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1123)
at org.testng.TestNG.run(TestNG.java:1031)
at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77)
at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:159)
at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:99)
at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:106)
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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

java.lang.UnsupportedOperationException: class redefinition failed: attempted to change the schema (add/remove fields)
at sun.instrument.InstrumentationImpl.redefineClasses0(Native Method)
at aaaaaaa.bbbbbbbconnector.JacocoErrorTest$1.<init>(JacocoErrorTest.java:30)
at aaaaaaa.bbbbbbbconnector.JacocoErrorTest.test(JacocoErrorTest.java:30)

pom extract:

<dependencies>
    <dependency>
        <groupId>com.googlecode.jmockit</groupId>
        <artifactId>jmockit</artifactId>
        <version>0.999.17</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.10</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.testng</groupId>
        <artifactId>testng</artifactId>
        <version>6.8</version>
        <scope>test</scope>
    </dependency>
</dependencies>

<build>
    <plugins>
        <plugin>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>2.5.1</version>
            <configuration>
                <source>1.7</source>
                <target>1.7</target>
            </configuration>
        </plugin>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.12.4</version>
        </plugin>
        <plugin>
            <groupId>org.jacoco</groupId>
            <artifactId>jacoco-maven-plugin</artifactId>
            <version>0.5.8.201207111220</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>
    </plugins>
</build>
@marchof

This comment has been minimized.

Member

marchof commented Oct 29, 2012

Ok, we've seen this before. What's happening here is that the JMockit agent loads classes and retransforms them before the JaCoCo agent sees them. Afterwards JaCoCo can not perform the required instrumentations any more.

Not much we can do about this, except printing a less prominent error message.

@assylias

This comment has been minimized.

assylias commented Oct 31, 2012

Thank you for your reply. I understand the reason for the issue - but since it was working up to 0.5.7 it might be "fixable".

@marchof

This comment has been minimized.

Member

marchof commented Oct 31, 2012

Ok, as soon as time permits I'll test your reproducer with 0.5.7.

@assylias

This comment has been minimized.

assylias commented Oct 31, 2012

That's great thanks. I am using 0.5.7 for this reason for now, but since it does what I need I am a happy user anyway :-)

@svarcheg

This comment has been minimized.

svarcheg commented Nov 9, 2012

Had same kind of issue, downgrading to 0.5.7 (actually eclemma 2.1.2) solved the issue

@fjakop

This comment has been minimized.

fjakop commented Jan 17, 2013

I have a similar kind of issue with classes instrumented ("enhanced") by Solarmetric Kodo-JDO (now Oracle Kodo I think).

My stacktrace with 0.6.1 is
java.lang.instrument.IllegalClassFormatException: Error while instrumenting class de/my/package//TypA.
at org.jacoco.agent.rt_6l8m50.CoverageTransformer.transform(CoverageTransformer.java:91)
at sun.instrument.TransformerManager.transform(TransformerManager.java:169)
at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
[snip]
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
at org.jacoco.agent.rt_6l8m50.core.internal.instr.FrameTracker.pop(FrameTracker.java:602)
at org.jacoco.agent.rt_6l8m50.core.internal.instr.FrameTracker.visitVarInsn(FrameTracker.java:386)
at org.jacoco.agent.rt_6l8m50.asm.MethodVisitor.visitVarInsn(Unknown Source)
at org.jacoco.agent.rt_6l8m50.asm.MethodVisitor.visitVarInsn(Unknown Source)
at org.jacoco.agent.rt_6l8m50.asm.tree.VarInsnNode.accept(Unknown Source)
at org.jacoco.agent.rt_6l8m50.asm.tree.InsnList.accept(Unknown Source)
at org.jacoco.agent.rt_6l8m50.asm.tree.MethodNode.accept(Unknown Source)
at org.jacoco.agent.rt_6l8m50.core.internal.flow.ClassProbesAdapter$1.visitEnd(ClassProbesAdapter.java:124)
at org.jacoco.agent.rt_6l8m50.asm.ClassReader.b(Unknown Source)
at org.jacoco.agent.rt_6l8m50.asm.ClassReader.accept(Unknown Source)
at org.jacoco.agent.rt_6l8m50.asm.ClassReader.accept(Unknown Source)
at org.jacoco.agent.rt_6l8m50.core.instr.Instrumenter.instrument(Instrumenter.java:69)
at org.jacoco.agent.rt_6l8m50.core.instr.Instrumenter.instrument(Instrumenter.java:82)
at org.jacoco.agent.rt_6l8m50.CoverageTransformer.transform(CoverageTransformer.java:89)
... 44 more

with 0.5.7 this is gone.
Also this only applies, when using the variant with <sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis> and collecting coverage information while "clean install" (tests are executed).

When I use <sonar.dynamicAnalysis>true</sonar.dynamicAnalysis> and run "sonar:sonar" everything is fine even with 0.6.1.

I would highly appreciate a fix. Further information can be supplied, if necessary.

@marchof

This comment has been minimized.

Member

marchof commented Jan 17, 2013

@fjakop This is a different issue. In your case the "Kodo-JDO" creates invalid or missing stackmap information. Please check with this product. I opened a enhancement request #73 to provide a better messages.

@fjakop

This comment has been minimized.

fjakop commented Jan 17, 2013

Ok, your're right that Kodo-JDO may be the root cause of all evil, but jacoco seems to tolerate this up to 0.6.0 according to my recent tests. Perhaps it's possible to tolerate these errors like before?
It is not possible for me to get Oracle to fix these invalid or missing stackmap information. ;-)

@marchof

This comment has been minimized.

Member

marchof commented Jan 17, 2013

@fjakop The reason is that JaCoCo has now full Java7 support (incl. stackmap frames). Probably it is possible to implement fallbacks, but this has now priority for me. Especially as Java 6 is end of life now and Oracle will therefore be forced to fix their own products.

@barclay-reg

This comment has been minimized.

barclay-reg commented Feb 14, 2013

so, for my understanding: jacoco >0.6.1 cannot instrument classes, which are compiled with target 1.6?

@Godin

This comment has been minimized.

Member

Godin commented Feb 14, 2013

@barclay-reg you're wrong - JaCoCo > 0.6.1 is able to instrument Java 1.6 classes (as well as 1.5 and 1.7), but only if they have correct stackmap information.

@marchof

This comment has been minimized.

Member

marchof commented Feb 14, 2013

Some technical details: JaCoCo updates existing stackmap information incrementally. If cannot not re-calculate stackmaps, as this is a quite heavy operation and would require to know the type hierarchy of all referenced types. JaCoCo therefore has no chance to figure out whether the original stackmap information was correct. In some situations the incremental update fails on invalid stackmaps, in this case we now provide a better error message, see #73.

Probably it is possible to implement some fallback strategies to remove stackmaps at all if the incremental update fails. But I don't feel that we should blur JaCoCo with such hacks because other tools create invalid class files. Expecially as Java 6 is end of live now and for Java 7 class files there is no fallback in the verifier any more, i.e. such broken tools will not work on Java 7 class anyways (with or without JaCoCo).

@nateastle

This comment has been minimized.

nateastle commented May 13, 2013

going back to the original issue, has anything been done to see if there was a fix for Jmockit and anything past 5.7? We are having the same issue.

@marchof marchof referenced this pull request Jul 18, 2013

Closed

Deadlock with JMockit #9

@baratali

This comment has been minimized.

baratali commented Jan 30, 2014

UTs hang when I use JMockit and JaCoCo maven plugin. It hangs even if JMockit exists only in class path and no usage in unit tests. Here is my project:

pom.xml:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>test</groupId>
    <artifactId>test</artifactId>
    <version>0.0.1-SNAPSHOT</version>

    <dependencies>
        <dependency>
            <groupId>com.googlecode.jmockit</groupId>
            <artifactId>jmockit</artifactId>
            <version>1.6</version>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.11</version>
        </dependency>
    </dependencies>

    <properties>                           
        <surefireArgLine>-javaagent:"${settings.localRepository}"/org/jacoco/org.jacoco.agent/0.6.4.201312101107/org.jacoco.agent-0.6.4.201312101107-runtime.jar=destfile=${project.baseUri}target/jacoco.exec</surefireArgLine>
    </properties>

    <build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.jacoco</groupId>
                    <artifactId>jacoco-maven-plugin</artifactId>
                    <version>0.6.4.201312101107</version>
                    <executions>
                        <execution>
                            <id>pre-unit-test</id>
                            <goals>
                                <goal>prepare-agent</goal>
                            </goals>
                            <configuration>
                                <destFile>${project.build.directory}/coverage-reports/jacoco-ut.exec</destFile>
                                <propertyName>surefireArgLine</propertyName>
                            </configuration>
                        </execution>
                        <execution>
                            <id>post-unit-test</id>
                            <phase>test</phase>
                            <goals>
                                <goal>report</goal>
                            </goals>
                            <configuration>
                                <dataFile>${project.build.directory}/coverage-reports/jacoco-ut.exec</dataFile>
                                <outputDirectory>${project.reporting.outputDirectory}/jacoco-ut</outputDirectory>
                            </configuration>
                        </execution>
                    </executions>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <configuration>
                        <source>1.5</source>
                        <target>1.5</target>
                    </configuration>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-surefire-plugin</artifactId>
                    <version>2.16</version>
                    <configuration>
                        <argLine>${surefireArgLine}</argLine>
                    </configuration>
                </plugin>
            </plugins>
        </pluginManagement>
    </build>
</project>

Unit test:

import mockit.Mock;
import mockit.MockUp;

import org.junit.Assert;
import org.junit.Test;

public class MyTest {

    @Test
    public void test() {
        new MockUp<MyMock>() {

            @Mock
            public int getValue() {
                return 4;
            }
        };

        MyMock mock = new MyMock();

        Assert.assertEquals(4, mock.getValue());
    }
}

class MyMock {
    public int getValue() {
        return 6;
    }
}
@rliesenfeld

This comment has been minimized.

rliesenfeld commented Mar 21, 2014

Hello. I am the JMockit developer, and I am currently looking into these problems with the JaCoCo + JMockit combination. There is more than one.

One of them is, I believe, in the JaCoCo CoverageTransformer class (latest version, 0.7.1-SNAPSHOT). The problem here is that, when JMockit calls Instrumentation#redefineClasses(<a mocked class>), the CoverageTransformer#transform(...) method is triggered with that same class passed in for the "classBeingRedefined" parameter. So far, so good as this is what java.lang.instrument does normally. Notice that the "classBeingRedefined" will necessarily already have passed through the CoverageTransformer when the class first got loaded by the JVM, as JMockit redefines classes sometime after they have been loaded.

I don't know why JaCoCo is trying to re-transform classes in this kind of situation. Most likely, it should "return null;" whenever it gets called with "classBeingRedefined != null". So, if the JaCoCo developers agree, this would be a trivial fix at line 76 of CoverageTransformer.java.

Alternatively, the problem can be solved by changing a) InstrSupport.java:81 to throw a more specific exception type, and b) CoverageTransformer.java:88 to catch this more specific exception and simply return null.

I will continue investigating other problems (mainly the hang/deadlock that occurs when JMockit tries to load its agent through the Attach API) and report back here, but if the above can be solved it would help a lot.

Thanks

@rliesenfeld

This comment has been minimized.

rliesenfeld commented Mar 21, 2014

Ok, I have news regarding the hang reported in the comment by "baratali" above. I couldn't fully understand what causes the deadlock, since it occurs inside JVM native code (specifically, the sun.misc.Unsafe#ensureClassInitialized(Class) native method). I suppose this method ends up getting called again while a previous call is still executing. This seems to occur only for the org.junit.runners.BlockJUnit4ClassRunner class, when JMockit attempts to redefine it for integration purposes; JaCoCo then attemps to set the "$jacocoData" static field, previously introduced to the class when it went through the CoverageTransformer.

A workaround which avoids the problem is to exclude the JUnit classes from JaCoCo's consideration. I used the following JVM initialization parameter in my testing, excluding both JUnit and TestNG classes: -javaagent:/jacoco-0.7.1/lib/jacocoagent.jar=excludes=junit.:org.junit.:org.testng.*

The good news is that the fix I described in my previous comment also solves this deadlock problem, because then the JUnit classes will be ignored by JaCoCo as they get instrumented by JMockit.

@marchof

This comment has been minimized.

Member

marchof commented Mar 21, 2014

@rliesenfeld Many thanks for getting in touch and analyzing this issue! I will investigate why the classBeingRedefined parameter was is used this way and see whether we can adjust the method as you propose.

@buildhive

This comment has been minimized.

buildhive commented Mar 23, 2014

Java Code Coverage Tools » jacoco #264 FAILURE
Looks like there's a problem with this pull request
(what's this?)

@marchof

This comment has been minimized.

Member

marchof commented Mar 23, 2014

@rliesenfeld I implemented the fixed as proposed by you and attached it to this issue as a pull request. It is also available as a snapshot build from here:

http://download.eclipselab.org/jacoco/preview/jacoco-0.7.1.201403230515.zip

Can you please confirm that the fix works? Thx

@rliesenfeld

This comment has been minimized.

rliesenfeld commented Mar 24, 2014

@marchof Yes, I tested with the attached zip file above, and it works!

Well, almost: once the CoverageTransformer stopped failing on class redefinitions triggered by JMockit, I discovered another problem (an "invalid class schema change" exception). However, I was able to make a few changes to JMockit to deal with this situation. I am still working on the final changes, but they will make it to the next JMockit release (1.8) which will be out next month (around April 20).

So, with these two sets of fixes on both tools, I believe the JaCoCo + JMockit combination should finally work well. Thanks very much!

@marchof

This comment has been minimized.

Member

marchof commented Mar 24, 2014

@rliesenfeld Indeed, JaCoCo adds a static field and a static method to instrumented classes. This would be considered as an "invalid class schema change" if the class has already been loaded before. So I'm going to merge the JaCoCo change.

marchof added a commit that referenced this pull request Mar 24, 2014

@marchof marchof merged commit 13babee into master Mar 24, 2014

1 check passed

default The Travis CI build passed
Details

@marchof marchof deleted the issue-35 branch Mar 24, 2014

@loganmzz

This comment has been minimized.

loganmzz commented Apr 8, 2014

I'm trying to use JMockit+EclEmma (JaCoCo). I have encountered the deadlock problems which has been solved by excluding JMockit & JUnit packages (mockit.:junit.:org.junit.*).
However I still encounter a "java.lang.IllegalStateException: Class XXX is already instrumented." warning. It seems to occur when JMockit "reload" the class to mock it.

In my test case, the warning is exaclty print once for each test methods and for each mocked (or injectable) class (none for interface)

Is current development dealing with this warning ?

@scooper4711

This comment has been minimized.

scooper4711 commented Apr 27, 2014

When can we get a release of Emma with this fix in it?

@rliesenfeld

This comment has been minimized.

rliesenfeld commented Apr 27, 2014

It's available now. See the following pages:

http://www.eclemma.org/jacoco/trunk/doc/changes.html
http://jmockit.googlecode.com/svn/trunk/www/changes.html

On Sun, Apr 27, 2014 at 1:24 PM, Stephen Cooper notifications@github.comwrote:

When can we get a release of Emma with this fix in it?


Reply to this email directly or view it on GitHubhttps://github.com//pull/35#issuecomment-41501056
.

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