[
https://issues.apache.org/jira/browse/IMPALA-8890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16916045#comment-16916045
]
Sahil Takiar commented on IMPALA-8890:
--------------------------------------
Looks like {{AnalyticEvalNode}} calls
{{input_batch.TransferResourceOwnership(output_batch)}} where {{input_batch}}
is the {{RowBatch}} read from the {{BufferedTupleStream}}.
I looked at {{buffered-tuple-stream-test}} and whether it does this
intentionally or not, it looks like
{{SimpleTupleStreamTest::BigStringReadWrite}} invokes this pattern:
[https://github.com/apache/impala/blob/5fde84a7aba9284004b481b41fe6f23d11527b6f/be/src/runtime/buffered-tuple-stream-test.cc#L1160]
- it adds a row to the stream, reads the row into a {{RowBatch}}, but does not
reset the batch until after adding another row.
So it sounds like it should be okay, IMPALA-8819 should add some coverage to
this pattern as well (and those tests have been running successfully so far),
but I will add an explicit test to {{buffered-tuple-stream-test}}.
> DCHECK(!page->attached_to_output_batch) in SpillableRowBatchQueue::AddBatch
> ----------------------------------------------------------------------------
>
> Key: IMPALA-8890
> URL: https://issues.apache.org/jira/browse/IMPALA-8890
> Project: IMPALA
> Issue Type: Sub-task
> Components: Backend
> Affects Versions: Impala 3.4.0
> Reporter: Sahil Takiar
> Assignee: Sahil Takiar
> Priority: Blocker
> Attachments: impalad.INFO, resolved.txt
>
>
> Full stack:
> {code}
> F0823 13:19:42.262142 60340 buffered-tuple-stream.cc:291]
> 6a4941285b46788d:68021ec600000000] Check failed:
> !page->attached_to_output_batch
> *** Check failure stack trace: ***
> @ 0x4c987cc google::LogMessage::Fail()
> @ 0x4c9a071 google::LogMessage::SendToLog()
> @ 0x4c981a6 google::LogMessage::Flush()
> @ 0x4c9b76d google::LogMessageFatal::~LogMessageFatal()
> @ 0x2917f78 impala::BufferedTupleStream::ExpectedPinCount()
> @ 0x29181ec impala::BufferedTupleStream::UnpinPageIfNeeded()
> @ 0x291b27b impala::BufferedTupleStream::UnpinStream()
> @ 0x297d429 impala::SpillableRowBatchQueue::AddBatch()
> @ 0x25d5537 impala::BufferedPlanRootSink::Send()
> @ 0x207e94c impala::FragmentInstanceState::ExecInternal()
> @ 0x207afac impala::FragmentInstanceState::Exec()
> @ 0x208e854 impala::QueryState::ExecFInstance()
> @ 0x208cb21
> _ZZN6impala10QueryState15StartFInstancesEvENKUlvE_clEv
> @ 0x2090536
> _ZN5boost6detail8function26void_function_obj_invoker0IZN6impala10QueryState15StartFInstancesEvEUlvE_vE6invokeERNS1_15function_bufferE
> @ 0x1e9830b boost::function0<>::operator()()
> @ 0x23e2d38 impala::Thread::SuperviseThread()
> @ 0x23eb0bc boost::_bi::list5<>::operator()<>()
> @ 0x23eafe0 boost::_bi::bind_t<>::operator()()
> @ 0x23eafa3 boost::detail::thread_data<>::run()
> @ 0x3bc1629 thread_proxy
> @ 0x7f920a3786b9 start_thread
> @ 0x7f9206b5741c clone
> {code}
> Happened once while I was running a full table scan of
> {{tpch_parquet.orders}} via JDBC (client was running on another EC2 machine).
> This was running on top of IMPALA-8819 with a fetch size of 32768.
> Attached full logs and mini-dump stack.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
