Closed Bug 1648898 Opened 4 years ago Closed 4 years ago

Data race during STS initialisation.

Categories

(Core :: Networking, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla80
Tracking Status
firefox80 --- fixed

People

(Reporter: jya, Assigned: jya)

References

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

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.

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.

Severity: -- → S3
Status: NEW → ASSIGNED
Priority: -- → P2
Whiteboard: [necko-triaged]
Attachment #9159858 - Attachment description: Bug 1648898 - Fix data race on STS loop start. r?valentin,honza → Bug 1648898 - Fix data race on STS loop start. r?valentin,mayhemer
Pushed by jyavenard@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f16199c7d45e Fix data race on STS loop start. r=mayhemer
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla80
Pushed by jyavenard@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ce326495d23b Fix data race on STS loop start. r=mayhemer
Flags: needinfo?(jyavenard)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: