Again Error while dumping coverage data (code 5013).

[mail.s...@gmail.com]

Hi,

i have several unit tests (about 800) that cause the error "Error while dumping coverage data (code 5013)" when i run code coverage with Eclemma. With Eclemma 2.3.4 (from http://download.eclipselab.org/eclemma/trunk/update) this is the stack trace:
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.DataInputStream.readByte(Unknown Source)
at org.jacoco.core.data.ExecutionDataReader.read(ExecutionDataReader.java:85)
at com.mountainminds.eclemma.internal.core.MemoryExecutionDataSource.readFrom(MemoryExecutionDataSource.java:68)
at com.mountainminds.eclemma.internal.core.launching.AgentServer.run(AgentServer.java:114)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

If i run code coverage on each package seperately, everything works fine. I also tried Eclemma 3.0.0 from the Eclipse marketplace. But i got the same error (with different line numbers in stack trace). I use the Eclipse built-in launcher. It seems that Eclemma has a problem, when it has to examine a larger number of tests.

Regards

[Evgeny Mandrikov]

Hi,

On Monday, September 4, 2017 at 7:56:45 AM UTC+2, mail.s...@gmail.com wrote:

 

With Eclemma 2.3.4 (from http://download.eclipselab.org/eclemma/trunk/update)

Please use officially released version - latest is 3.0.0, and was released after 2.3.3.

 

i have several unit tests (about 800) that cause the error "Error while dumping coverage data (code 5013)" when i run code coverage with Eclemma.

 

this is the stack trace:

java.net.SocketException: Connection reset
        at java.net.SocketInputStream.read(Unknown Source)
        at java.net.SocketInputStream.read(Unknown Source)
        at java.net.SocketInputStream.read(Unknown Source)
        at java.io.DataInputStream.readByte(Unknown Source)
        at org.jacoco.core.data.ExecutionDataReader.read(ExecutionDataReader.java:85)
        at com.mountainminds.eclemma.internal.core.MemoryExecutionDataSource.readFrom(MemoryExecutionDataSource.java:68)
        at com.mountainminds.eclemma.internal.core.launching.AgentServer.run(AgentServer.java:114)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

If i run code coverage on each package seperately, everything works fine. I also tried Eclemma 3.0.0 from the Eclipse marketplace. But i got the same error (with different line numbers in stack trace). I use the Eclipse built-in launcher. It seems that Eclemma has a problem, when it has to examine a larger number of tests.

Just few moments ago I executed EclEmma 3.0.0 in Eclipse Oxygen 4.7.0 on a test suite that contains more than 2000 tests covering more than 500 classes without any problems.

The only known to me example of similar problem: is that one of tests causes main thread to be in interrupted state - see https://github.com/jacoco/eclemma/issues/64 and associated bug in JDK - https://bugs.openjdk.java.net/browse/JDK-8154017

Please check for this and if this is the case, then please fix your code since there is nothing what we can do with such JDK bug.

And if this is not your case and as shown above it doesn't seem to be related to amount of tests, then how we can reproduce your problem?

Regards,

Evgeny

[mail.s...@gmail.com]

Hi Evgeny,

thanks for your reply. Like i wrote before, if i run the tests separately, there's no problem. So this doesn't seem to me, that there's a problem concerning the interrupted state in the test code.

Hmm, yes, to reproduce the problem is not easy. Maybe there's a kind of dependency between some tests. But that's hard to find out. Ok, i will see, if i can get any further information that could be interesting for you.

Regards
Stephan

[michael.deb...@gmail.com]

Hello,

We also have that issue running EclEmma on a large amount of tests. We started to get the issue sporadically around 2200 units test, but as soon as we got over 2500 tests we are getting that issue 100% of the time. I even updated my eclipse from Neon to Oxygen but no luck

Message : Error while dumping coverage data (code 5013).

Stack : java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:209)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.io.DataInputStream.readFully(DataInputStream.java:195)
at java.io.DataInputStream.readLong(DataInputStream.java:416)
at org.jacoco.core.data.ExecutionDataReader.readExecutionData(ExecutionDataReader.java:147)
at org.jacoco.core.data.ExecutionDataReader.readBlock(ExecutionDataReader.java:115)
at org.jacoco.core.runtime.RemoteControlReader.readBlock(RemoteControlReader.java:47)
at org.jacoco.core.data.ExecutionDataReader.read(ExecutionDataReader.java:92)
at org.eclipse.eclemma.internal.core.MemoryExecutionDataSource.readFrom(MemoryExecutionDataSource.java:68)
at org.eclipse.eclemma.internal.core.launching.AgentServer.run(AgentServer.java:114)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)

session data :eclipse.buildId=4.7.0.I20170612-0950
java.version=1.8.0_92
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=fr_CA
Framework arguments: -product org.eclipse.epp.package.jee.product -product org.eclipse.epp.package.jee.product
Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.jee.product -data file:/C:/Users/debellefeuillem/workspace/ -product org.eclipse.epp.package.jee.product


Hope this can help you

[Evgeny Mandrikov]

Hi Michael,

First of all - thank you for this information.

Given that yours number of tests is different from number of tests reported in this thread by Stephan, I strongly believe that there is no strong correlation with number of tests per se. With total amount of data to be processed (classes and their coverage) - maybe, but not with exact number of tests in arbitrary test suite.

Stephan, I guess that you're also using Windows? If so and if this is something related to Windows, then this complicates attempts to reproduce on our side, because me and Marc (active developers of EclEmma and JaCoCo) are daily users of Linux and Mac OS X, but not Windows.

Since you, guys, able to stably reproduce this, then why not give us a hand and investigate this bug using the same principles and tools (debugger, maybe network analyzer such as Wireshark, etc) as any other similar bug in software that you develop? All code of EclEmma and JaCoCo is open and freely available. This will greatly speedup resolution of this problem. And we'll really appreciate such contribution.

Regards,

Evgeny

[Evgeny Mandrikov]

Successfully executed 10000 generated tests for 10000 generated classes (generator in attachment) with EclEmma on Windows 10, Mac OS X and Linux.

As wild guess: connection between JVM with tests and IDE is established at startup, data is written at termination (shutdown hook). Is it possible that something in your environment (OS, firewall) kills connection while it is inactive between opening and writing? How long execution of tests takes?

Regards,

Evgeny

[michael.deb...@gmail.com]

Hello Evgeny,

Thank you for investigating, the tests take about 30 seconds to run.

I'm on Windows 7. I don't know if there any difference from Win 7 to Win 10 in that matter.

At work we have 2 networks 1 with domain and one 1 without so less security.

I tried to switch network, deactivated my Windows firewall, restarted Eclipse Oxygen in order to have the least thing interfering but still getting the error.

[Evgeny Mandrikov]

On Tuesday, September 12, 2017 at 7:08:15 PM UTC+2, michael.deb...@gmail.com wrote:

Thank you for investigating, the tests take about 30 seconds to run.

I even tried tests that take longer than 10 minutes.

 

I'm on Windows 7. I don't know if there any difference from Win 7 to Win 10 in that matter.

No idea if this matters, and I don't have Win 7 to try and not sure if worth it to find one.

I literally ran out of ideas trying to reproduce this for many hours.

 

At work we have 2 networks 1 with domain and one 1 without so less security.

I tried to switch network, deactivated my Windows firewall, restarted Eclipse Oxygen in order to have the least thing interfering but still getting the error.

 

Are you sure you're not victim of previously mentioned JDK bug - https://bugs.openjdk.java.net/browse/JDK-8154017 ?

Can only come back to proposal of debugging on your side - add debug output to JaCoCo writing code, use this version in EclEmma and add debug output to its reading code, use Wireshark to analyze connection to correlate sequences of debug output with it.

[Marc Hoffmann]

Hi,

what I can add here is that at a project we run > 100'000 tests with EclEmma on Windows. The tests run for about 10min. No issues like this so far.

I'm pretty sure this is related to a JVM shutdown problem like the issue Evgeny mentioned.

As a workaround you might block execution in your "last" test and request coverage data from the coverage view manually while the JVM is still running.

Regards,
-marc

--
You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jacoco+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/d476de3e-e265-448a-8cee-3899d0a52735%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

 

[michael.deb...@gmail.com]

Hello Marc and Evgeny

you may be right about the JDK bug.

I updated my JDK just to make sure it wasn't it, still had the problem.

I managed to get the coverage by doing either of those 2 options :

-- Pressing stop button in eclipse near the end of the run
-- Addin a Thread.sleep(100000) in one test which gets interrupted ending up with 1 failing test but allowing me to get the coverage.

so it's probably the racing condition of https://bugs.openjdk.java.net/browse/JDK-8154017 that happenned

[Marc Hoffmann]

> -- Addin a Thread.sleep(100000) in one test which gets interrupted
> ending up with 1 failing test but allowing me to get the coverage.

Here we go: If the Thread.sleep() gets interrupted then your main thread
is in interrupted state! This will trigger the JDK bug.

So I really recommend to investigate why your tests put the main thread
in interrupted state.

Regards,
-marc

[Evgeny Mandrikov]

On Tuesday, September 12, 2017 at 9:19:19 PM UTC+2, michael.deb...@gmail.com wrote:

I updated my JDK just to make sure it wasn't it, still had the problem.

I guess your update was not up to JDK 9 EA, whereas as you can see in https://bugs.openjdk.java.net/browse/JDK-8154017 - bug was fixed for JDK 9 and wasn't backported to 8 ;)

[Michaël De Bellefeuille]

Thank you very much for your time

just found what was wrong, it was on our side at some places we do Thread.currentThread().interrupt(), because the test wasn't in a different thread it ended up messing up the coverage session. 

I'm sorry for bothering you with that issue, because the problem was on our side, but I'm very thankful for your input which helped me a lot finding the problem source and the solution.

--

Michaël De Bellefeuille

[mail.s...@gmail.com]

Hi,

thank you for all your investigation. I just want to inform you, that we solved the problem more or less by accident by using the OpenJDK platform instead of the Oracle JDK.

Regards
Stephan

[Marc Hoffmann]

Thanks for letting us know!

Cheers,
-marc

[Evgeny Mandrikov]

Hi Stephan,

On Wednesday, September 20, 2017 at 2:37:12 PM UTC+2, mail.s...@gmail.com wrote:

thank you for all your investigation. I just want to inform you, that we solved the problem more or less by accident by using the OpenJDK platform instead of the Oracle JDK.

Hard to believe, because there is not much differences between OpenJDK and OracleJDK - you can consider OracleJDK as slightly customized build of OpenJDK done by Oracle. The only major differences are in UI-related components (see https://github.com/AdoptOpenJDK/openjdk-build/wiki/Differences-between-Adopt-OpenJDK-binaries-and-Oracle-JDK-Binaries), which do not play role in this discussion.

In particular https://bugs.openjdk.java.net/browse/JDK-8154017 is present in both of them for versions < 9, and was fixed for both of them for versions >=9. Note that this bug is about race condition - something that is not guaranteed to happen with 100% chance.

Regards,

Evgeny

[mail.s...@gmail.com]

Hi Evgeny,

as far as i know, we use a customized version of the OpenJDK. But unfortunately i have no idea what's different to the normal OpenJDK. I think it's optimized for large memory usage, but i'm not sure. I can only describe, what i see. If i switch from Oracle JRE to OpenJDK all is fine, if i switch back, i run into the mentioned error.

Regards
Stephan