You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Andrew Wong (Jira)" <ji...@apache.org> on 2019/09/20 17:00:09 UTC
[jira] [Updated] (KUDU-2842) Data race in
CatalogManager::GetTableLocations
[ 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)