Dandandan opened a new issue, #22227: URL: https://github.com/apache/datafusion/issues/22227
### Describe the bug `array_resize` panics with `capacity overflow` when given a very large positive target size. The panic comes from `Vec::reserve` in `raw_vec` because the requested size in elements times the element layout exceeds `isize::MAX`. Related-but-distinct from the other large-allocation panics filed via the recent fuzz pass (#22188 `range`/`generate_series`, #22217 `repeat`, #22218/#22219 `array_repeat`). `array_resize` has its own scalar count argument with the same missing validation. ### To Reproduce ```bash cargo run -p datafusion-cli -- -c "SELECT array_resize(make_array(1), 9223372036854775807, 0)" ``` ### Actual behavior ``` DataFusion CLI v53.1.0 thread 'main' panicked at .../library/alloc/src/raw_vec/mod.rs:28:5: capacity overflow note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` ### Expected behavior Return an execution error (e.g. `"array_resize: target size too large"`) rather than panicking, mirroring the bounds-check fix suggested for #22188. ### Environment - DataFusion CLI v53.1.0 (from `main` at commit 8741a7752c) ### Additional context Found by running hand-crafted SQL through `cargo run -p datafusion-cli -- -c ...`. Same root-cause shape as the other array-builder overflow panics: a user-supplied count is fed straight into `Vec::reserve`/`with_capacity` without bounding against `isize::MAX / size_of::<T>()`. -- 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]
