[
https://issues.apache.org/jira/browse/KUDU-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Wong updated KUDU-2842:
------------------------------
Code Review: https://gerrit.cloudera.org/c/14263/
> 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: Andrew Wong
> Priority: Blocker
> 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
(v8.3.4#803005)
