[jira] [Commented] (KUDU-2842) Data race in CatalogManager::GetTableLocations

["Andrew Wong (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KUDU-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16932937#comment-16932937 ] 

Andrew Wong commented on KUDU-2842:
-----------------------------------

A couple thoughts, though haven't thought too in depth about it yet.

* Could we pass the TabletMetadataLock and TableMetadataLocks around with the TSInfosDict to ensure the locks are held through the duration of the usage of TSInfosDict?
* Alternatively, we could do away with StringPiece here and go with copied strings, though we'd be ballooning the memory usage of GetTableLocations quite a bit.

> 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)