You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "Lars Volker (JIRA)" <ji...@apache.org> on 2019/01/29 21:23:00 UTC
[jira] [Created] (IMPALA-8140) Grouping aggregation with limit
breaks asan build
Lars Volker created IMPALA-8140:
-----------------------------------
Summary: Grouping aggregation with limit breaks asan build
Key: IMPALA-8140
URL: https://issues.apache.org/jira/browse/IMPALA-8140
Project: IMPALA
Issue Type: Bug
Components: Backend
Affects Versions: Impala 3.1.0, Impala 3.2.0
Reporter: Lars Volker
Assignee: Lars Volker
Commit 4af3a7853e9 for IMPALA-7333 breaks the following query on ASAN:
{code:sql}
select count(*) from tpch_parquet.orders o group by o.o_clerk limit 10;
{code}
{noformat}
==30219==ERROR: AddressSanitizer: use-after-poison on address 0x631000c4569c at pc 0x0000020163cc bp 0x7f73a12a5700 sp 0x7f73a12a56f8
READ of size 1 at 0x631000c4569c thread T276
#0 0x20163cb in impala::Tuple::IsNull(impala::NullIndicatorOffset const&) const /tmp/be/src/runtime/tuple.h:241:13
#1 0x280c3d1 in impala::AggFnEvaluator::SerializeOrFinalize(impala::Tuple*, impala::SlotDescriptor const&, impala::Tuple*, void*) /tmp/be/src/exprs/agg-fn-evaluator.cc:393:29
#2 0x2777bc8 in impala::AggFnEvaluator::Finalize(std::vector<impala::AggFnEvaluator*, std::allocator<impala::AggFnEvaluator*> > const&, impala::Tuple*, impala::Tuple*) /tmp/be/src/exprs/agg-fn-evaluator.h:307:15
#3 0x27add96 in impala::GroupingAggregator::CleanupHashTbl(std::vector<impala::AggFnEvaluator*, std::allocator<impala::AggFnEvaluator*> > const&, impala::HashTable::Iterator) /tmp/be/src/exec/grouping-aggregator.cc:351:7
#4 0x27ae2b2 in impala::GroupingAggregator::ClosePartitions() /tmp/be/src/exec/grouping-aggregator.cc:930:5
#5 0x27ae5f4 in impala::GroupingAggregator::Close(impala::RuntimeState*) /tmp/be/src/exec/grouping-aggregator.cc:383:3
#6 0x27637f7 in impala::AggregationNode::Close(impala::RuntimeState*) /tmp/be/src/exec/aggregation-node.cc:139:32
#7 0x206b7e9 in impala::FragmentInstanceState::Close() /tmp/be/src/runtime/fragment-instance-state.cc:368:42
#8 0x2066b1a in impala::FragmentInstanceState::Exec() /tmp/be/src/runtime/fragment-instance-state.cc:99:3
#9 0x2080e12 in impala::QueryState::ExecFInstance(impala::FragmentInstanceState*) /tmp/be/src/runtime/query-state.cc:584:24
#10 0x1d79036 in boost::function0<void>::operator()() const /opt/Impala-Toolchain/boost-1.57.0-p3/include/boost/function/function_template.hpp:766:14
#11 0x24bbe06 in impala::Thread::SuperviseThread(std::string const&, std::string const&, boost::function<void ()>, impala::ThreadDebugInfo const*, impala::Promise<long, (impala::PromiseMode)0>*) /tmp/be/src/util/thread.cc:359:3
#12 0x24c72f8 in void boost::_bi::list5<boost::_bi::value<std::string>, boost::_bi::value<std::string>, boost::_bi::value<boost::function<void ()> >, boost::_bi::value<impala::ThreadDebugInfo*>, boost::_bi::value<impala::Promise<long, (impala::PromiseMode)0>*> >::operator()<void (*)(std::string const&, std::string const&, boost::function<void ()>, impala::ThreadDebugInfo const*, impala::Promise<long, (impala::PromiseMode)0>*), boost::_bi::list0>(boost::_bi::type<void>, void (*&)(std::string const&, std::string const&, boost::function<void ()>, impala::ThreadDebugInfo const*, impala::Promise<long, (impala::PromiseMode)0>*), boost::_bi::list0&, int) /opt/Impala-Toolchain/boost-1.57.0-p3/include/boost/bind/bind.hpp:525:9
#13 0x24c714b in boost::_bi::bind_t<void, void (*)(std::string const&, std::string const&, boost::function<void ()>, impala::ThreadDebugInfo const*, impala::Promise<long, (impala::PromiseMode)0>*), boost::_bi::list5<boost::_bi::value<std::string>, boost::_bi::value<std::string>, boost::_bi::value<boost::function<void ()> >, boost::_bi::value<impala::ThreadDebugInfo*>, boost::_bi::value<impala::Promise<long, (impala::PromiseMode)0>*> > >::operator()() /opt/Impala-Toolchain/boost-1.57.0-p3/include/boost/bind/bind_template.hpp:20:16
#14 0x3c83949 in thread_proxy (/home/lv/i4/be/build/debug/service/impalad+0x3c83949)
#15 0x7f768ce73183 in start_thread /build/eglibc-ripdx6/eglibc-2.19/nptl/pthread_create.c:312
#16 0x7f768c98a03c in clone /build/eglibc-ripdx6/eglibc-2.19/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:111
{noformat}
The problem seems to be that we call {{output_partition_->aggregated_row_stream->Close()}} in be/src/exec/grouping-aggregator.cc:284 when hitting the limit, and then later the tuple creation in {{CleanupHashTbl()}} in be/src/exec/grouping-aggregator.cc:341 reads from poisoned memory.
A similar query does not show the crash:
{code:sql}
select count(*) from functional_parquet.alltypes a group by a.string_col limit 2;
{code}
[~tarmstrong] - Do you have an idea why the query on a much smaller dataset wouldn't crash?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org