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)