You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@impala.apache.org by "Michael Ho (JIRA)" <ji...@apache.org> on 2018/03/05 22:18:00 UTC

[jira] [Created] (IMPALA-6609) Some COUNTER_ADD in KrpcDataStreamRecvr() may lead to use-after-free

Michael Ho created IMPALA-6609:
----------------------------------

             Summary: Some COUNTER_ADD in KrpcDataStreamRecvr() may lead to use-after-free
                 Key: IMPALA-6609
                 URL: https://issues.apache.org/jira/browse/IMPALA-6609
             Project: IMPALA
          Issue Type: Bug
          Components: Distributed Exec
    Affects Versions: Impala 3.0, Impala 2.12.0
            Reporter: Michael Ho
            Assignee: Michael Ho


The following line in {{KrpcDataStreamRecvr}} may lead to use-after-free. A {{KrpcDataStreamRecvr}} is co-owned by {{KrpcDataStreamMgr}} and an {{ExchangeNode}}. There is a window in which the {{ExchangeNode}} has already been closed and when the last reference to {{KrpcDataStreamMgr}} goes away. In this window, the {{KrpcDataStreamRecvr}} queues should all have been cancelled and closed but the receiver itself may still reference resources owned by the {{ExchangeNode}}. The general pattern is that once a receiver's queue is cancelled or closed, there should be no more access to its data structures not owned by the receiver or the queue itself. However, there are a couple of places in {{KrpcDataStreamRecvr}} which violate this pattern:

{noformat}
void KrpcDataStreamRecvr::RemoveSender(int sender_id) {
  int use_sender_id = is_merging_ ? sender_id : 0;
  sender_queues_[use_sender_id]->DecrementSenders();
  COUNTER_ADD(num_eos_received_, 1); <<-------
}
{noformat}

In the long run, we really need to re-think this business of co-ownership and simplify the lifecycle management of a {{KrpcDataStreamRecvr}} object.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)