[cribbing from decoder's script, hopefully he won't mind] The attached logfile shows a thread/data race 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 unacceptable 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. I think what's happening here is that we can touch the mTimeout field in SetDelayInternal while we're inserting a timer and reading the mTimeout field from TimerAdditionComparator. This race doesn't seem benign, because it can violate the invariants we want on the sorted list of timers in the timer thread (?). That said, I don't see any immediate way of fixing it, since we can't force TimeStamps to be read atomically. It's also possible that SetDelay() is just a bad API. Somehow, I would not be surprised if this was a small contributor to intermittent oranges... [1] http://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong