Baymine opened a new pull request, #66034:
URL: https://github.com/apache/doris/pull/66034
### What problem does this PR solve?
Issue Number: close #66033
Problem Summary:
`VExplodeBitmapTableFunction::get_value` computed the number of rows to emit
with `max_step = std::min(max_step, (int)(_cur_size - _cur_offset));`. Both
`_cur_size` (the bitmap cardinality) and `_cur_offset` are `int64_t`. When a
bitmap holds more than `INT_MAX` (~2.1 billion) elements, the subtraction
`_cur_size - _cur_offset` exceeds the range of `int`, so the C-style `(int)`
cast overflows and yields a negative `max_step`. That negative value is later
used in `target->resize(origin_size + max_step)`, which underflows the size
computation and crashes the BE (core dump).
The fix performs the `std::min` in `int64_t` space so the comparison is done
without truncation, then casts the result — now provably within `[0, max_step]`
and therefore in `int` range — back to `int`. A `DCHECK_GE(max_step, 0)` guard
documents and asserts the post-condition, matching the glog `DCHECK` idiom
already used by the sibling table_function sources.
### Release note
Fix BE crash when exploding a bitmap whose cardinality exceeds INT_MAX.
### Check List (For Author)
- Test
- [x] No need to test or manual test. Explain why:
- [x] Other reason: Reproducing the crash requires a bitmap with
more than 2^31 (~2.1 billion) elements (~16GB of memory), which is not feasible
in a unit or regression test. This is a defensive correctness fix.
- Behavior changed:
- [x] No.
- Does this need documentation?
- [x] No.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
