TSan: data race netwerk/base/nsSocketTransportService2.cpp:1219 UpdatePrefs (race on mTelemetryEnabledPref)

RESOLVED FIXED in Firefox 43

Status

()

defect
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: froydnj, Unassigned)

Tracking

(Blocks 1 bug)

unspecified
mozilla43
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox43 fixed)

Details

(Whiteboard: [tsan])

Attachments

(2 attachments)

Reporter

Description

4 years ago
Posted file TSan stack trace
The attached logfile shows a thread/data race detected by TSan (ThreadSanitizer).

* Specific information about this bug

We are reading mTelemetryEnabledPref from the socket thread and writing to it from the main thread when we get pref information.  There's no synchronization between the two.

I have a patch for this, it's pretty straightforward.

* General information about TSan, data races, etc.

Typically, races reported by TSan are not false positives, but it is possible that the race is benign. Even in this case though, we should try to come up with a fix unless this would cause unacceptable performance issues. Also note that seemingly benign races can possibly be harmful (also depending on the compiler and the architecture) [1][2].

If the bug cannot be fixed, then this bug should be used to either make a compile-time annotation for blacklisting or add an entry to the runtime blacklist.

[1] http://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong
[2] _How to miscompile programs with "benign" data races_: https://www.usenix.org/legacy/events/hotpar11/tech/final_files/Boehm.pdf
Reporter

Comment 1

4 years ago
This variable is written on the main thread (where we can access prefs),
but read on the socket thread on every poll iteration to decide whether
we should record telemetry information.  Making it atomic communicates
our intent to read/write the value on multiple threads without any
locking.  Using relaxed memory consistency is just as efficient as what
we have today, and it does not seem terribly crucial whether the *very
next* poll iteration records telemetry once the pref is updated, or
whether we can eventually get the correct value on the socket thread.
Attachment #8660001 - Flags: review?(mcmanus)
Comment on attachment 8660001 [details] [diff] [review]
make nsSocketTransportService::mTelemetryEnabledPref an atomic variable

Review of attachment 8660001 [details] [diff] [review]:
-----------------------------------------------------------------

relaxed reflects the intention of this (no lock, can lag) exactly - thanks.
Attachment #8660001 - Flags: review?(mcmanus) → review+
https://hg.mozilla.org/mozilla-central/rev/c3b4f091efae
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
You need to log in before you can comment on or make changes to this bug.