1157350 - TSan: data race js/src/gc/Statistics.h:184 count

Status: RESOLVED DUPLICATE of bug 1361401

(Core :: JavaScript: GC, defect)

Description

[Nathan Froyd [:froydnj]]

Attachment: gc-statistics-race.txt

The attached logfile shows a thread/data race detected by TSan (ThreadSanitizer).

* Specific information about this bug

Looks like we can write to the Statistics::count array from multiple threads without any locking.  I guess these statistics are not incredibly important, so we could just implement these with relaxed atomics, perhaps?  Might have to adjust the PodZeroArray call in AutoGCSlice to set the members one by one to make TSan happy with that.

* 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

Comment 1

[Jan de Mooij [:jandem]]

This one still shows up in the shell. Statistics::count is called from Chunk::allocate on both the main thread and a background thread (BackgroundAllocTask).

As suggested in comment 0, we can probably just use relaxed atomics for these counters?

Comment 2

[Terrence Cole [:terrence]]

(In reply to Jan de Mooij [:jandem] from comment #1)
> This one still shows up in the shell. Statistics::count is called from
> Chunk::allocate on both the main thread and a background thread
> (BackgroundAllocTask).
> 
> As suggested in comment 0, we can probably just use relaxed atomics for
> these counters?

Yes, relaxed atomics would be ideal. I thought that we had already fixed this!

Comment 3

[Jon Coppeard (:jonco)]

This got fixed in bug 1361401.