The attached logfile shows a thread/data race detected by TSan (ThreadSanitizer). * Specific information about this bug We're writing into AudioInfo::mRate or ::mChannels (hard to say which, since the assignments are on the same line in the source) and then reading out that data on another thread. The writing happens inside a number of locks; I don't know the code well enough to say whether the author(s) thought writing inside locks and reading outside of locks was safe, or whether the locks just happen to be held at the point of the write and they actually have nothing to do with the code in question. * 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