Uploaded image for project: 'IMPALA'
  1. IMPALA
  2. IMPALA-4285

Parquet scanner with MT_DOP > 0 crashes when materializing no slots.

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: Impala 2.8.0
    • Fix Version/s: Impala 2.8.0
    • Component/s: Backend
    • Labels:

      Description

      Repro:

      set mt_dop=1;
      compute stats compute stats functional_parquet.alltypes
      

      Stack:

      #0  0x00007fd1ac08b425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
      #1  0x00007fd1ac08eb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
      #2  0x00007fd1ae1daac5 in os::abort(bool) () from /home/abehm/jdk1.7.0_25/jre/lib/amd64/server/libjvm.so
      #3  0x00007fd1ae33a137 in VMError::report_and_die() () from /home/abehm/jdk1.7.0_25/jre/lib/amd64/server/libjvm.so
      #4  0x00007fd1ae1de5e0 in JVM_handle_linux_signal () from /home/abehm/jdk1.7.0_25/jre/lib/amd64/server/libjvm.so
      #5  <signal handler called>
      #6  0x0000000001641264 in impala::RowBatch::row_byte_size (this=0x0) at /home/abehm/impala/be/src/runtime/row-batch.h:201
      #7  0x000000000167a3e5 in impala::HdfsScanner::next_row (this=0xb16cd00, r=0xc240000)
          at /home/abehm/impala/be/src/exec/hdfs-scanner.h:467
      #8  0x00000000017b21a4 in impala::HdfsScanner::WriteEmptyTuples (this=0xb16cd00, context=0xa038f80, row=0xc240000, num_tuples=300)
          at /home/abehm/impala/be/src/exec/hdfs-scanner.cc:269
      #9  0x000000000169ecf5 in impala::HdfsParquetScanner::GetNextInternal (this=0xb16cd00, row_batch=0xb231320)
          at /home/abehm/impala/be/src/exec/hdfs-parquet-scanner.cc:342
      #10 0x0000000001674c47 in impala::HdfsScanner::GetNext (this=0xb16cd00, row_batch=0xb231320)
          at /home/abehm/impala/be/src/exec/hdfs-scanner.h:132
      #11 0x0000000001674605 in impala::HdfsScanNodeMt::GetNext (this=0xc52cf00, state=0xb0fe900, row_batch=0xb231320, eos=0x97ef949)
          at /home/abehm/impala/be/src/exec/hdfs-scan-node-mt.cc:93
      #12 0x0000000001718657 in impala::PartitionedAggregationNode::GetRowsStreaming (this=0x97ef680, state=0xb0fe900, out_batch=0xb233ba0)
          at /home/abehm/impala/be/src/exec/partitioned-aggregation-node.cc:549
      #13 0x00000000017166e1 in impala::PartitionedAggregationNode::GetNextInternal (this=0x97ef680, state=0xb0fe900, row_batch=0xb233ba0, 
          eos=0x7e27cb1) at /home/abehm/impala/be/src/exec/partitioned-aggregation-node.cc:451
      #14 0x0000000001715adf in impala::PartitionedAggregationNode::GetNext (this=0x97ef680, state=0xb0fe900, row_batch=0xb233ba0, 
          eos=0x7e27cb1) at /home/abehm/impala/be/src/exec/partitioned-aggregation-node.cc:377
      #15 0x000000000198a2ec in impala::PlanFragmentExecutor::OpenInternal (this=0x7e27b88)
          at /home/abehm/impala/be/src/runtime/plan-fragment-executor.cc:309
      #16 0x0000000001989d9a in impala::PlanFragmentExecutor::Open (this=0x7e27b88)
          at /home/abehm/impala/be/src/runtime/plan-fragment-executor.cc:274
      #17 0x0000000001504dec in impala::FragmentMgr::FragmentExecState::Exec (this=0x7e27800)
          at /home/abehm/impala/be/src/service/fragment-exec-state.cc:58
      #18 0x00000000014fc57d in impala::FragmentMgr::FragmentThread (this=0xbf4adc0, fragment_instance_id=...)
          at /home/abehm/impala/be/src/service/fragment-mgr.cc:88
      #19 0x0000000001500330 in boost::_mfi::mf1<void, impala::FragmentMgr, impala::TUniqueId>::operator() (this=0xac006f0, p=0xbf4adc0, 
          a1=...) at /home/abehm/impala/toolchain/boost-1.57.0/include/boost/bind/mem_fn_template.hpp:165
      #20 0x00000000015000ed in boost::_bi::list2<boost::_bi::value<impala::FragmentMgr*>, boost::_bi::value<impala::TUniqueId> >::operator()<boost::_mfi::mf1<void, impala::FragmentMgr, impala::TUniqueId>, boost::_bi::list0> (this=0xac00700, f=..., a=...)
          at /home/abehm/impala/toolchain/boost-1.57.0/include/boost/bind/bind.hpp:313
      #21 0x00000000014ffa17 in boost::_bi::bind_t<void, boost::_mfi::mf1<void, impala::FragmentMgr, impala::TUniqueId>, boost::_bi::list2<boost::_bi::value<impala::FragmentMgr*>, boost::_bi::value<impala::TUniqueId> > >::operator() (this=0xac006f0)
          at /home/abehm/impala/toolchain/boost-1.57.0/include/boost/bind/bind_template.hpp:20
      ...
      

        Activity

        Hide
        alex.behm Alexander Behm added a comment -

        The problem is not specific to compute stats, but to count queries run on Parquet with MT_DOP > 1.

        Show
        alex.behm Alexander Behm added a comment - The problem is not specific to compute stats, but to count queries run on Parquet with MT_DOP > 1.
        Hide
        alex.behm Alexander Behm added a comment -

        commit ff6b450ad380ce840e18875a89d9cf98058277a3
        Author: Alex Behm <alex.behm@cloudera.com>
        Date: Wed Oct 19 23:27:14 2016 -0700

        IMPALA-4285/IMPALA-4286: Fixes for Parquet scanner with MT_DOP > 0.

        IMPALA-4258: The problem was that there was a reference to
        HdfsScanner::batch_ hidden inside WriteEmptyTuples(). The batch_
        reference is NULL when the scanner is run with MT_DOP > 1.

        IMPALA-4286: When there are no scan ranges HdfsScanNodeBase::Open()
        exits early without initializing the reader context. This lead to
        a DCHECK in IoMgr::GetNextRange() called from HdfsScanNodeMt.
        The fix is to remove that unnecessary short-circuit Open().

        I combined these two bugfixes because the new basic test covers
        both cases.

        Testing: Added a new test_mt_dop.py test. A private code/hdfs
        run passed.

        Change-Id: I79c0f6fd2aeb4bc6fa5f87219a485194fef2db1b
        Reviewed-on: http://gerrit.cloudera.org:8080/4767
        Reviewed-by: Alex Behm <alex.behm@cloudera.com>
        Tested-by: Internal Jenkins

        Show
        alex.behm Alexander Behm added a comment - commit ff6b450ad380ce840e18875a89d9cf98058277a3 Author: Alex Behm <alex.behm@cloudera.com> Date: Wed Oct 19 23:27:14 2016 -0700 IMPALA-4285 / IMPALA-4286 : Fixes for Parquet scanner with MT_DOP > 0. IMPALA-4258 : The problem was that there was a reference to HdfsScanner::batch_ hidden inside WriteEmptyTuples(). The batch_ reference is NULL when the scanner is run with MT_DOP > 1. IMPALA-4286 : When there are no scan ranges HdfsScanNodeBase::Open() exits early without initializing the reader context. This lead to a DCHECK in IoMgr::GetNextRange() called from HdfsScanNodeMt. The fix is to remove that unnecessary short-circuit Open(). I combined these two bugfixes because the new basic test covers both cases. Testing: Added a new test_mt_dop.py test. A private code/hdfs run passed. Change-Id: I79c0f6fd2aeb4bc6fa5f87219a485194fef2db1b Reviewed-on: http://gerrit.cloudera.org:8080/4767 Reviewed-by: Alex Behm <alex.behm@cloudera.com> Tested-by: Internal Jenkins

          People

          • Assignee:
            alex.behm Alexander Behm
            Reporter:
            alex.behm Alexander Behm
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development