PITest: JavaLaunchHelper is implemented in both

Question

Recently I started using PITest for Mutation Testing. Post building my project using maven when I run the command mvn org.pitest:pitest-maven:mutationCoverage I get this error bunch of times:

-stderr  : objc[2787]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/bin/java and /Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be ustderr  : sed. Which one is undefined.

Sometimes the error is followed by

PIT >> WARNING : Slave exited abnormally due to MEMORY_ERROR

or PIT >> WARNING : Slave exited abnormally due to TIMED_OUT

I use OsX version 10.10.4 and Java 8 (jdk1.8.0_74).

Any fix/ work-around for this?

Answer 1

Don't worry about this;

-stderr : objc[2787]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/bin/java and /Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be ustderr : sed. Which one is undefined.

This is just for information that there are two implementations of JavaLauncherHelper and the message tells you that one of the two will use std-err output stream but it is undetermined which one of the two. It is a known isse, see also this question

The other two are a result of what PIT is doing: it's modifying the byte code and it may happen that this not just affects the output of an operation (detected by a test) but actually affects the runtime behavior. For example if boundaries of a loop get changed that way, that the loop runs endlessly. Pit is capable of detecting this and prints out an error. Mutations detected by either a memory error or a timeout error can be considered as "killed". But you should check each of those individually as they could be false positives, too.

PIT >> WARNING : Slave exited abnormally due to MEMORY_ERROR means the modified code produces more or larger objects so the forked jvm runs out of memory. Imagine a loop like this

while(a < b){
   list.add(new Object());
   a++;
}

And the a++ gets altered to a-- . The loop may eventually end, but it's more likely you run out of memory before that.

From the documentation

A memory error might occur as a result of a mutation that increases the amount of memory used by the system, or may be the result of the additional memory overhead required to repeatedly run your tests in the presence of mutations. If you see a large number of memory errors consider configuring more heap and permgen space for the tests.

The timeout issue is similar to this, the reason coud be either, that you run an infinite loop or that system thinks you run an infinite loop, ie when the system is too slow to compute the altered code. If you experience a lot of timeouts you should consider increasing the timeout value. But be carefull, as this may impact the overall execution time.

From the FAQ

Timeouts when running mutation tests are caused by one of two things

• 1 A mutation that causes an infinite loop
• 2 PIT thinking an infinite loop has occured but being wrong

In order to detect infinite loops PIT measures the normal execution time of each test without any mutations present. When the test is run in the presence of a mutation PIT checks that the test doesn't run for any longer than normal time * x + y

Unfortunately the real world is more complex than this. Test times can vary due to the order in which the tests are run. The first test in a class may have a execution time much higher than the others as the JVM will need to load the classes required for that test. This can be particularly pronounced in code that uses XML binding frameworks such as jaxb where classloading may take several seconds.

When PIT runs the tests against a mutation the order of the tests will be different. Tests that previously took miliseconds may now take seconds as they now carry the overhead of classloading. PIT may therefore incorrectly flag the mutation as causing an infinite loop.

An fix for this issue may be developed in a future version of PIT. In the meantime if you encounter a large number of timeouts, try increasing y in the equations above to a large value with –timeoutConst (timeoutConstant in maven).