[
https://issues.apache.org/jira/browse/IMPALA-15376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18118111#comment-18118111
]
ASF subversion and git services commented on IMPALA-15376:
----------------------------------------------------------
Commit efdd0713f37a46aa7161902c7410059a25cdd517 in impala's branch
refs/heads/master from Michael Smith
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=efdd0713f ]
IMPALA-15376: Fix SIGABRT in AnalyticEvalNode::GetNext on empty window_tuples_
AnalyticEvalNode::GetNext() unconditionally called
window_tuples_.front() when deciding whether to transfer the prev
tuple pool to the output batch. window_tuples_ can legitimately be
empty at that point (e.g. right after all window tuples have been
popped, or when prev_pool_last_window_idx_ was recorded as the -1
sentinel), so calling front() on the empty deque is undefined
behavior. Under _GLIBCXX_ASSERTIONS on GCC 15+ (enabled whenever
__OPTIMIZE__ is unset, e.g. -O0/UBSAN/DEBUG_NOOPT builds) this
aborts the process.
Reproduced by a query combining an analytic/window function with an
outer ORDER BY + LIMIT, e.g.:
select * from (
select l_partkey, l_quantity, l_orderkey,
rank() over (partition by l_partkey, l_quantity
order by l_orderkey desc) rk
from lineitem) dt
order by l_partkey, l_quantity, l_orderkey, rk
limit 10
which plans to a local TopNNode pulling rows from AnalyticEvalNode via
GetNext() in TopNNode::Open().
Guard the front() access by short-circuiting when window_tuples_ is
empty, since an empty window_tuples_ means nothing remains that could
still reference prev_tuple_pool_, so it's always safe to transfer.
Change-Id: Ic17c5a6ea4cfada1faf7a1715aa83489c2db7658
Assisted-by: Claude Sonnet 5 (GitHub Copilot)
Reviewed-on: http://gerrit.cloudera.org:8080/24893
Reviewed-by: Impala Public Jenkins <[email protected]>
Tested-by: Impala Public Jenkins <[email protected]>
> Undefined AnalyticEvalNode::GetNext on empty window_tuples_
> -----------------------------------------------------------
>
> Key: IMPALA-15376
> URL: https://issues.apache.org/jira/browse/IMPALA-15376
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
> Reporter: Michael Smith
> Assignee: Michael Smith
> Priority: Major
>
> AnalyticEvalNode::GetNext() unconditionally called window_tuples_.front()
> when deciding whether to transfer the prev tuple pool to the output batch.
> window_tuples_ can legitimately be empty at that point (e.g. right after all
> window tuples have been popped, or when prev_pool_last_window_idx_ was
> recorded as the -1 sentinel), so calling front() on the empty deque is
> undefined behavior.
> Newer Clang versions identify this as undefined in UBSAN builds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
