Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
Impala 2.6.0
Description
There is a tricky corner case in our resource transfer model with subplans and limits. The problem is that the limit in the subplan may mean that the exec node is reset before it has returned its full output. The resource transfer logic generally attaches resources to batches at specific points in the output, e.g. end of partition, end of block, so it's possible that batches returned before the Reset() may reference resources that have not yet been transferred. It's unclear if we test this scenario consistently or if it's always handled correctly.
One example is this query, reported in IMPALA-5456:
select c_custkey, c_mktsegment, o_orderkey, o_orderdate from customer c, (select o1.o_orderkey, o2.o_orderdate from c.c_orders o1, c.c_orders o2 where o1.o_orderkey = o2.o_orderkey limit 10) v limit 500;
Attachments
Issue Links
- blocks
-
IMPALA-5456 impala crashes in impala::Tuple::DeepCopyVarlenData trying to memcpy a null pointer
- Resolved
- is duplicated by
-
IMPALA-5456 impala crashes in impala::Tuple::DeepCopyVarlenData trying to memcpy a null pointer
- Resolved
- is related to
-
IMPALA-5456 impala crashes in impala::Tuple::DeepCopyVarlenData trying to memcpy a null pointer
- Resolved
-
IMPALA-4179 Remove RowBatch::MarkNeedsDeepCopy() memory management API
- Open