Hello, my name is Bhargava Manja, and I'm an employee at Runtime
Verification, a company that develops tools for formal verification. We are
testing out our race detector on open source projects, and we get a lot of
results on the Freenet node software. I wanted to run one of the race
conditions by you guys, as I'm not sure if it is serious or
inconsequential. In general, the tool is picking up on a lot of unprotected
concurrent reads and writes on data originating from threads scheduled by
your PooledExecutor class. The first is on the pubKey field in
RequestSender.java. The output of our tool is -
Data race on field freenet.node.RequestSender.pubKey: {{{
Concurrent write in thread T83 (locks held: {})
----> at freenet.node.RequestSender.<init>(RequestSender.java:174)
at freenet.node.Node.makeRequestSender(Node.java:3991)
at freenet.node.NodeClientCore.asyncGet(NodeClientCore.java:1109)
at freenet.node.NodeClientCore.asyncGet(NodeClientCore.java:933)
at
freenet.node.SendableGetRequestSender.send(SendableGetRequestSender.java:52)
at freenet.client.async.ChosenBlock.send(ChosenBlock.java:70)
at
freenet.node.RequestStarter$SenderThread.run(RequestStarter.java:274)
at
freenet.support.PooledExecutor$MyThread.realRun(PooledExecutor.java:188)
at freenet.support.io.NativeThread.run(NativeThread.java:129)
T83 is created by T25
at freenet.support.PooledExecutor.execute(PooledExecutor.java:113)
Concurrent read in thread T189 (locks held: {})
----> at freenet.node.RequestSender.realRun(RequestSender.java:232)
at freenet.node.RequestSender.realRun(RequestSender.java:231)
at freenet.node.RequestSender.run(RequestSender.java:213)
at
freenet.support.PooledExecutor$MyThread.realRun(PooledExecutor.java:188)
at freenet.support.io.NativeThread.run(NativeThread.java:129)
T189 is created by T25
at freenet.support.PooledExecutor.execute(PooledExecutor.java:113)
}}}
This is saying that there is a race between two threads, one that
constructs a RequestSender and another that calls Run. Construction of
objects in Java is not atomic, so this may present an issue if reordered.
However, I am not sure if the way PooledExecutor works prevents this (for
example, by using some sort of locked queue), so I wanted some input. The
other races are similar, in that they involve the concurrent access of the
same objects. We want to see if our tool is reporting false positives or
"technical" race conditions, as we haven't instrumented Java's concurrency
classes. Does any of this seem serious at all? Thanks for the input.
--Bhargava
_______________________________________________
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
