Re: TSAN false positives with std::call_once

2017-02-14 Thread Todd Lipcon
On Tue, Feb 14, 2017 at 6:22 PM, Adar Dembo wrote: > Any idea why this only surfaced recently? There's a call to > std::call_once in util/logging.cc that's been there for almost a year. > I'm guessing that one is only very rarely called (on crash) and would only be called by multiple threads at

Re: TSAN false positives with std::call_once

2017-02-14 Thread Adar Dembo
Any idea why this only surfaced recently? There's a call to std::call_once in util/logging.cc that's been there for almost a year. In any case, I'm not a huge fan of #2. #1 and #3 both require a patch, but I think #1 is more likely to get noticed (and reverted) upon an LLVM 4.0 upgrade. So I think

Re: TSAN false positives with std::call_once

2017-02-14 Thread Todd Lipcon
BTW, I should add that libstdcxx as included in gcc 4.9.2 (devtoolset on el6) doesn't have this bug, since it just wraps pthread_once. So, it's probably not a _real_ issue since we don't use libc++ for production builds. -Todd On Tue, Feb 14, 2017 at 6:05 PM, Todd Lipcon wrote: > I noticed that

TSAN false positives with std::call_once

2017-02-14 Thread Todd Lipcon
I noticed that a lot of our tests have gotten flaky with a TSAN race reported around SSL initialization. After digging into a bit, I found that our version of libcxx has a bug in std::once where it's using a relaxed load instead of an acquire load to check the flag of whether it has run yet. I wen