-
Notifications
You must be signed in to change notification settings - Fork 86
Potential for race condition in signing.java #63
Comments
There are multiple calls to the curl object in this class, in every method its state is reseted. By one hand we can have one object and reuse it in the whole class; by the other hand we can have multiple object instances so that increasing the amount of memory consumed. I can see a "livelock" problem here which is a kind of race condition problem. A Livelock problem happens when two or more threads are trying to complete a task over an object (state in this object to be more accurately) and they modify it altering the assumptions of the other thread on that object, this causes the non-finishing of the task by one thread or an anomalous execution finishing. My advice is calling the SpongeFactory class every time an ICurl object is invoked in the Signing class. |
"iotaledger#63 Potential for race condition in signing.java". The changes are related to a problem of race condition in Signing class when using the object of type ICurl.
…tion_signing_63 Issue: "#63 Potential for race condition in signing.java"
"iotaledger#63 Potential for race condition in signing.java". The changes are related to a problem of race condition in Signing class when using the object of type ICurl.
The signing class keeps and uses an instance of an ICurl, but member functions are not synchronized. See here:
https://github.com/iotaledger/iota.lib.java/blob/fbacc5ae44e246b8361be3586ac6c0d28b6aac2f/jota/src/main/java/jota/utils/Signing.java#L32
For the most minimal change, I suggest to not keep an instance of an ICurl in this class - but, at the very least, change this to a SpongeFactory mode, and create an instance inside each method that uses it.
The text was updated successfully, but these errors were encountered: