Bug #7898
openThread sanitizer reports race on JSlot::nextFid_ (and will likely report one in WObject as well: nextObjId_)
0%
Description
Because increment is not atomic, the same id may occur twice. It is however impossible that the same id occurs twice in one WApplication if the application lock is acquired when WObjects and JSlots are generated. This would mean that there will only possibly be the same id across different instances of WApplication, which would mean this concurrency is "safe".
Another issue: nextFid_ is an int, which could in theory overflow (which is undefined behavior for signed integers).
We could either make it so this warning is suppressed, or fix it in a way that's guaranteed to be safe, like an atomic integer, which of course does have a performance cost.
Updated by Bruce Toll about 4 years ago
I think that the static "seq" value used in WApplication::addExposedResource may have a similar issue.
A few months back, I was working on a patch that maintained independent rand values for each application session. That is, the first exposed private resource of an application session would always get the same rand value. A secondary advantage of this approach was that it avoids leaking information about how often the resource has been used. A similar approach might be possible for nextFid_. The nextObjId_ can't be maintained in the WApplication, but perhaps it could be associated with the WebSession? Not sure of the pros and cons, but I thought it couldn't hurt to leave a comment for your consideration.