Adar Dembo created KUDU-2842:
--------------------------------
Summary: Data race in CatalogManager::GetTableLocations
Key: KUDU-2842
URL: https://issues.apache.org/jira/browse/KUDU-2842
Project: Kudu
Issue Type: Bug
Components: master
Affects Versions: 1.10.0
Reporter: Adar Dembo
Assignee: Will Berkeley
Attachments: test.txt
Saw this on a test run.
I think the problem is that TSInfosDict is reused for all calls to
BuildLocationsForTablet for a particular table, and the map inside it points to
peer UUIDs by reference (i.e. StringPiece) instead of by copy. Thus, when a
given BuildLocationsForTablet call completes, the tablet lock is released and
the catalog manager is free to destroy that tablet's TabletInfo (i.e. via
committing a mutation in ProcessTabletReport). But the very next call to
BuildLocationsForTablet may cause TSInfosDict map keys to be read and compared,
even though the memory backing those keys no longer exists.
Assigning to Will because he committed 586e957f7 but cc'ing [~tlipcon] as he
was the original author of the code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
