[
https://issues.apache.org/jira/browse/KUDU-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16932979#comment-16932979
]
Andrew Wong commented on KUDU-2842:
-----------------------------------
I started looking into it more, and it seems like the first approach would be
somewhat difficult to do, since the codepaths are shared with
GetTabletsLocations, whose call might span multiple tables (and thus, whose
TableMetadataLock acquisition may be repeated).
I'll see about using string copies.
Alternatively, I wonder if we could have the `uuid_to_idx` map use a
StringPiece from the strings in TSInfoPBs. Seems like it'd get around both
drawbacks you mentioned, but I think it might be a good amount of work, given
we currently use ComputeIfAbsent to create the TSInfoPBs.
> 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
> 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)
