bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

TSan: data race js/src/../../js/src/shell/js.cpp:2990 CancelExecution

RESOLVED FIXED in Firefox 43

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: decoder, Assigned: froydnj)

Tracking

(Blocks: 1 bug)

Trunk
mozilla43
x86_64
Linux
Points:
---

Firefox Tracking Flags

(firefox43 fixed)

Details

(Whiteboard: [tsan])

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Created attachment 8370098 [details]
Logfile with TSan trace

The attached logfile shows a thread/data race (mozilla-central revision 44ba69cacd7e) detected by TSan (ThreadSanitizer).

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 inacceptable performance issues. Also note that seemingly benign races can possibly be harmful (also depending on the compiler and the architecture) [1].

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
This one is for the shell's gTimedOut global. We can just make that a mozilla::Atomic I think, just like JSRuntime::interrupt.
(In reply to Christian Holler (:decoder) from comment #1)
> I think this is the same problem as in bug 967544, but racing for
> gTimeoutFunc instead of gTimedOut. gTimeoutFunc is a JS::Value, how would we
> solve that issue here?

gTimeoutFunc Value is either a NullValue() or ObjectValue(), so I think you could make it a JSObject* instead (and use nullptr instead of NullValue()). Does that help?
Assignee: general → nobody
(Assignee)

Comment 3

3 years ago
Still happening; I'm going to fix this, as it makes TSan testing with the shell unpleasant.  Also, less use of |volatile| in the codebase can't be a bad thing.
Assignee: nobody → nfroyd
(Assignee)

Comment 4

3 years ago
Created attachment 8644675 [details] [diff] [review]
make gServiceInterrupt Atomic

|volatile| doesn't guarantee inter-thread safety.  Atomic<> does.

Atomic<> also makes TSan much happier.
Attachment #8644675 - Flags: review?(jwalden+bmo)

Updated

3 years ago
Attachment #8644675 - Flags: review?(jwalden+bmo) → review+
https://hg.mozilla.org/mozilla-central/rev/007b21fc06a3
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox43: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
You need to log in before you can comment on or make changes to this bug.