Closed
Bug 967462
Opened 11 years ago
Closed 11 years ago
TSan: data race js/src/../../js/src/vm/Runtime.h:820 runtime
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: decoder, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [tsan])
Attachments
(1 file)
9.68 KB,
text/plain
|
Details |
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
Comment 1•11 years ago
|
||
This looks related to off-main-thread Ion compilation.
Comment 2•11 years ago
|
||
This is about rt->numCompilationThreads.
The compilation thread increments it, AutoLockForCompilation uses it to decide if it should take the lock. Brian, isn't it possible to have the following sequence:
- Trigger off-thread compilation
- Main thread constructs AutoLockForCompilation, numCompilationThreads == 0, no lock.
- Compilation thread increments numCompilationThreads, starts compiling
- Main thread is writing compilation data without the lock.
Flags: needinfo?(bhackett1024)
Comment 4•11 years ago
|
||
Actually the main thread performs all writes to numCompilationThreads, which is consistent with the race reported here. The compilation thread can read numCompilationThreads via AutoLockForCompilation without taking a lock first (the numCompilationThreads test is done to see if a lock is needed at all) which could race the writes done by the main thread. In this case since the increment done by the main thread is on the other side of a fence (the compilation lock is taken when doing the increment and must be released and acquired by a worker before it can start the job) then the worker should see the increment and whatever value it reads should be > 0. Would using atomic operations around this stuff make TSan happier or does this just need to be suppressed?
Flags: needinfo?(bhackett1024)
Comment 5•11 years ago
|
||
(In reply to Brian Hackett (:bhackett) from comment #4)
> Actually the main thread performs all writes to numCompilationThreads, which
> is consistent with the race reported here.
Oops you're right, I misread the report.
> Would using atomic
> operations around this stuff make TSan happier or does this just need to be
> suppressed?
We can probably make numCompilationThreads a mozilla::Atomic and add a comment like comment 4 (only modified on the main thread, WorkerThreadState lock has to be taken).
Reporter | ||
Comment 6•11 years ago
|
||
The field that this race is about was removed at some point, marking as fixed.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Resolution: FIXED → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•