[ https://issues.apache.org/jira/browse/IMPALA-8140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757639#comment-16757639 ]
ASF subversion and git services commented on IMPALA-8140: --------------------------------------------------------- Commit 6214d2d81236695a9e606634dbeebdbbbccf3847 in impala's branch refs/heads/master from Lars Volker [ https://gitbox.apache.org/repos/asf?p=impala.git;h=6214d2d ] IMPALA-8140: Fix use-after-poison in grouping aggregator IMPALA-7333 changed the memory transfer semantics to move memory when attaching it to the output batch instead of copying it. This caused a use-after-poison when the cleaning up the hash tables during the call to Close(). To fix this, we now clean up the hash table before closing the output row stream. Testing: added a test to aggregation.test Change-Id: Id23cd1e2fc5e003e3c9e3503436621a76d49559d Reviewed-on: http://gerrit.cloudera.org:8080/12298 Reviewed-by: Impala Public Jenkins <impala-public-jenk...@cloudera.com> Tested-by: Impala Public Jenkins <impala-public-jenk...@cloudera.com> > 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 > Priority: Blocker > Labels: asan, crash > > 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-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org