Data race during STS initialisation.
Categories
(Core :: Networking, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox80 | --- | fixed |
People
(Reporter: jya, Assigned: jya)
References
Details
(Whiteboard: [necko-triaged])
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
This is handling the P5 from bug 1634846 separately as it fits in its own component really.
In bug 1634846; it exposed more frequently an issue happening with the the socket transport service (STS) is starting its event loop.
It does:
nsCOMPtr<nsIThread> thread;
nsresult rv =
NS_NewNamedThread("Socket Thread", getter_AddRefs(thread), this);
if (NS_FAILED(rv)) return rv;
{
MutexAutoLock lock(mLock);
// Install our mThread, protecting against concurrent readers
thread.swap(mThread);
mDirectTaskDispatcher = do_QueryInterface(mThread);
}
So it dispatches itself as first task and then set the value of mThread.
However it could happen that nsSocketTransportService::Run() gets called before mThread is set right after the call to NS_NewNamedThread.
This could cause nsSocketTransportService::IsOnCurrentThread() to incorrectly return false when called from nsSocketTransportService::Run()
Additionally, there's lot of unnecessary locking happening to access members like mThread, mShuttingDown and mInitialized
mThread is modified on the main thread and accessed from any thread. Holding a mutex is necessary but not always done.
Locking is only necessary because we clear the value of mThread on shutdown, but this isn't a requirement.
In all, we can make most of the tests atomic and remove most of the mutex locking in place.
Assignee | ||
Comment 1•4 years ago
|
||
The STS dispatched the first event before setting mThread member. It was possible that the STS::Run() task got started before mThread was set and causing one of the nsISerialEventTarget methods to read mThread/mInitialised/mShuttingDown value as null or zero and they would have returned an error.
We rewrite and simplify the access to mThread such that it's a lockless operation.
ApplyPortRemapPreference assert that it's running on the taskqueue; however if called before initialization, it would have been run on whatever thread called ApplyPortRemap.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 3•4 years ago
|
||
Backed out for causing Bug 1649333
Backout link: https://hg.mozilla.org/integration/autoland/rev/0e0f336c4e3b06a6df9d11d00a1ae695d41e64b7
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=307988570&repo=autoland&lineNumber=8543
Comment 4•4 years ago
|
||
bugherder |
Comment 6•4 years ago
|
||
bugherder |
Assignee | ||
Updated•4 years ago
|
Description
•