Suffer from permanent Different class names for id Exception

[Mario Ackerl]

Hi,

currently we have the issue that 50 percent of our coverage run ends with the exception:

We have a seperate .exec File for every test method/suite ... in the end we merge everything before importing in Sonar. We suffer a lot, when a ran taking 26 hours is useless in the end.

How can we deal with that? 

11:23:30 java.lang.IllegalStateException: Different class names org/eclipse/birt/report/model/api/StyleRuleHandle and org/eclipse/birt/report/model/Ccom/microsoft/sql for id 9d7f8ed69288195e.
11:23:30 	at org.jacoco.core.data.ExecutionData.assertCompatibility(ExecutionData.java:176)
11:23:30 	at org.jacoco.core.data.ExecutionData.merge(ExecutionData.java:144)
11:23:30 	at org.jacoco.core.data.ExecutionData.merge(ExecutionData.java:117)
11:23:30 	at org.jacoco.core.data.ExecutionDataStore.put(ExecutionDataStore.java:53)
11:23:30 	at org.jacoco.core.data.ExecutionDataStore.visitClassExecution(ExecutionDataStore.java:175)
11:23:30 	at com.mountainminds.eclemma.internal.core.MemoryExecutionDataSource.visitClassExecution(MemoryExecutionDataSource.java:56)
11:23:30 	at org.jacoco.core.data.ExecutionDataReader.readExecutionData(ExecutionDataReader.java:149)
11:23:30 	at org.jacoco.core.data.ExecutionDataReader.readBlock(ExecutionDataReader.java:113)
11:23:30 	at org.jacoco.core.data.ExecutionDataReader.read(ExecutionDataReader.java:87)
11:23:30 	at com.mountainminds.eclemma.core.URLExecutionDataSource.accept(URLExecutionDataSource.java:44)
11:23:30 	at com.mountainminds.eclemma.internal.core.CoverageSession.accept(CoverageSession.java:66)
11:23:30 	at com.mountainminds.eclemma.internal.core.SessionManager.mergeSessions(SessionManager.java:177)
11:23:30 	at com.wamas.ide.junit4.view.launch.TestLocationCoverageSession.merge(TestLocationCoverageSession.java:53)

I see the comment: "The purpose of this check is to detect a very unlikely class id collision". Maybe unlikely, but likely enough that we hit one of those errors on two runs?

Kind regards

Mario

[bjk...@gmail.com]

If it is a true collision, then interestingly, ExecutionDataStore could relatively easily use [name,CRC] as the key rather than just CRC, which would make such a collision even less likely. The only real issue is the ExecutionDataStore.get(long) method, which could be deprecated and reimplemented to throw IllegalStateException if there is a conflict, and a new get(long,String) could be added.

[Marc R. Hoffmann]

Hi Mario,

I can't believe that this ever happens. Can you please send me both class files?

Thx,
-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/b3e39c08-c3d4-4ab9-bf27-7ef6664d458b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mario Ackerl]

I would, but I've got a problem. I can not find the second one - the class he is complaining to collide with. Something is strange here ... 

[Mario Ackerl]

I am pretty sure it is happening again in the next days and then I take a closer look - and send you the files.

[Marc R. Hoffmann]

Hi all,

just to follow up here on the public forum:

1. We were not able to find class files with an id clash.
2. The problem stems form corrupted exec files
   

Exec files can be validated by running this example snippet: http://eclemma.org/jacoco/trunk/doc/examples/java/ExecDump.java

Regards,
-marc

[Mario Ackerl]

Thanks for your help Marc.

Regards,

Mario