The attached logfile shows a thread/data race detected by TSan (ThreadSanitizer). * Specific information about this bug I do not understand this report. I think, from the writing side of the race, that we are calling: mGraphImpl->SetCurrentDriver(mNextDriver); in ThreadedDriver::RunThread. That makes sense of the assign_assuming_AddRef call, even though the SetCurrentDriver call is on a different line than what's reported. The reading side of the race, however, is just a call to MediaStreamGraphImpl::Process(), not a read of an nsRefPtr. I'm guessing that the compiler must have inlined Process(), and then that the read must come from calling MediaStreamGraphImpl::CurrentDriver() during Process()? Other theories welcome. * 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

Was this fixed by your recent landings?

It ought to, bug I haven't landed anything yet, it's going through try right now.

Mass change P2->P3 to align with new Mozilla triage process.