#121 ArrayIndexOutOfBoundsExceptions with jmockit & jacoco agents

[Anonymous]

JaCoCo Java Agent, version 0.5.6.201201232323
Java 1.6.0
Windows XP
JMockit 0.999.13

I'm seeing an ArrayIndexOutOfBoundsException during Jmockit tests while using Jacoco. When both the JaCoCo and JMockit javaagents are configured in the maven surefire plugin, then I get ArrayIndexOutOfBoundsExceptions for no apparent reason while running unit tests. If I remove the JaCoCo javaagent then the tests pass. Likewise, if I remove tests that use JMockit from my unit tests then the remaining tests pass.

This issue was raised on the JMockit page in the last few days. The JMockit developer who looked at the issue said:

"I debugged this problem in the past few days, and it (the ArrayIndexOutOfBoundsException) can be easily reproduced (just run a JUnit+JMockit test suite in a Java IDE with "-javaagent:jacocoagent.jar").

However, I could not find any solution on my end. The exception is thrown by bytecode inserted in the mocked class by the JaCoCo CoverageTransformer. I couldn't figure out what exactly happens. The JaCoCo developers should have a look at this, as it's more likely that they can do something to solve the issue."

You can see that thread here: http://code.google.com/p/jmockit/issues/detail?id=215

Below is the exception stack that I'm seeing:

-------------------------------------------------------------------------------
Test set: com.mycompany.myprogram.MyClassTest
-------------------------------------------------------------------------------
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.281 sec <<< FAILURE!
testNumberOne(com.mycompany.myprogram.MyClassTest) Time elapsed: 0.109 sec <<< FAILURE!
java.lang.AssertionError: Missing invocation of:
com.mycompany.myprogram.DependencyClass#doSomething(com.mycompany.myprogram.DataItem1 d1, com.mycompany.myprogram.DataItem2 d2)
with arguments: data1, data2
on mock instance: com.mycompany.myprogram.DependencyClass@12ce574
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
Caused by: Missing invocation
at com.mycompany.myprogram.DependencyClass.populateCreditRating(DependencyClass.java)
at com.mycompany.myprogram.MyClassTest$8.<init>(MyClassTest.java:118)
at com.mycompany.myprogram.MyClassTest.testNumberOne(MyClassTest.java:116)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.lang.reflect.Method.invoke(Method.java:597)
... 8 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: 78
at com.mycompany.myprogram.DependencyClass.doSomethingElse(DependencyClass.java)
at com.mycompany.myprogram.MyClassTest$8.<init>(MyClassTest.java:123)
... 11 more

[James Flagg]

Just to distinguish this from the existing, closed bug number 3495990, this occurs even _without_ using JMockit Coverage, so it is not simply a case of two coverage tools conflicting. I am from the thread on the JMockit site. It would be great to use eclEmma to measure coverage on tests which utilize JMockit mocked objects, if this is reasonable to do. Thanks.

[Warren G]

I am having same issue. jmockit 0.999.11, using eclipse market place to get latest via update site (3/20/2012), java 1.7.0_03

[Marc R. Hoffmann]

Short update: The problem happens with classes that get re-transformed. In this case internal JaCoCo data structures cached within a class do not get updated to correspond with the new version of the class.

I have prepared a fix for this, should be available within the next days.

[Marc R. Hoffmann]

Fixed in trunk, available with the latest trunk build.