RuntimeData not thread safe

[marchof]

Hi guys,

I'm having a problem with RuntimeData and specifically with ExecutionDataStore. The data store has a map: Map<Long, ExecutionData> entries which causes a concurrent access a problem with the following exception:

java.util.ConcurrentModificationException
    at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
    at java.util.HashMap$ValueIterator.next(HashMap.java:1458)
    at org.jacoco.agent.rt.internal_c57fe0e.core.data.ExecutionDataStore.accept(ExecutionDataStore.java:167)
    at org.jacoco.agent.rt.internal_c57fe0e.core.runtime.RuntimeData.collect(RuntimeData.java:87)
    at org.jacoco.agent.rt.internal_c57fe0e.output.MongoDbOutput.writeExecutionData(MongoDbOutput.java:54)
    at org.jacoco.agent.rt.internal_c57fe0e.Agent.shutdown(Agent.java:132)
    at org.jacoco.agent.rt.internal_c57fe0e.Agent$1.run(Agent.java:49)

Note: MongoDbOutput is a custom created MongoDB sink

The RuntimeData has a comment saying that is thread safe. That's not the case anymore since ExecutionDataStore is not thread safe

[bjkail]

RuntimeData looks thread-safe to me. ConcurrentModificationException can also occur if the HashMap is changed while being iterated. Does MongoDbOutput call other RuntimeData methods from the IExecutionDataVisitor/ISessionInfoVisitor that it passes to collect?

[ihr]

Hi,

For a class to be a thread-safe its fields should also be thread-safe. MongoDbOutput uses only one method: RuntimeData#collect.

[marchof]

Good catch! This is actually not a multi-threading-issue but a re-entrance issue. When the provided callbacks itself load new classes the internal ExecutionDataStore can be modified from within the same thread.