[cfe-dev] TSan reports a race on vtable access (Clang/7)

Oleg Smolsky via cfe-dev cfe-dev at lists.llvm.org
Thu Mar 14 12:18:41 PDT 2019


Yes, that's similar. I have just looked at the code gen and the vtable 
re-assignment races. Thanks a lot!

Oleg.

On 2019-03-14 12:09, Kostya Serebryany wrote:
> I think this case is described in 
> https://github.com/google/sanitizers/wiki/ThreadSanitizerPopularDataRaces#data-race-on-vptr
>
> On Thu, Mar 14, 2019 at 9:23 AM Oleg Smolsky <oleg at cohesity.com 
> <mailto:oleg at cohesity.com>> wrote:
>
>     I've hit a funky TSan warning: "data race on vptr (ctor/dtor vs
>     virtual
>     call) in StartImpl()". I fail to see a race as the object is
>     constructed
>     in the main thread and then a worker thread is started:
>
>     struct Client : public ClientInterface {
>        Client() {
>          auto op = new Op{this};
>          thread_ = std::thread([op] { op->StartImpl(); });
>        }
>        ...
>     };
>
>     void Op::StartImpl() {
>        std::cout << "This is a race: " << owner_->VirtualFunction() <<
>     "\n";
>     }
>
>     struct TestClient : public Client {};
>
>     int main(int argc, char **argv) {
>        TestClient().Wait();
>        return 0;
>     }
>
>     The full report with a minimal/complete repro is here:
>     https://github.com/google/sanitizers/issues/1063
>
>     What am I missing? Does TSan miss the fact that all data stores
>     happen
>     before the worker thread is started? Or is this about the vtable
>     pointer
>     which is adjusted during the object's construction in the main thread?
>
>     Thanks!
>     Oleg.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190314/86094b55/attachment.html>


More information about the cfe-dev mailing list