[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