iemejia opened a new pull request, #3920:
URL: https://github.com/apache/avro/pull/3920
## What changes were proposed in this pull request?
`GenericDatumReader.readArray` already validates a declared array block
count against the bytes actually remaining (`ensureAvailableCollectionBytes`)
and applies a heap-aware bound for element types whose minimum encoded size is
zero, before eagerly allocating the backing storage.
The `ReflectDatumReader.readArray` override did not apply these guards: it
called `newArray(old, (int) l, ...)` → `Array.newInstance(elementClass, count)`
using the declared block count directly, so a malformed or truncated record
mapped to a Java array field (for example `long[]`) could drive a large eager
allocation before a single element was read.
This aligns `ReflectDatumReader.readArray` with the generic reader by
applying the same `ensureAvailableCollectionBytes` and
`checkMaxCollectionAllocation` guards before the allocation. Malformed input
now fails fast (`EOFException`) instead of over-allocating; valid arrays read
unchanged.
## How was this patch tested?
- New test in `TestReflectDatumReader`:
- `read_PojoWithArray_rejectsOversizedArrayCount` — a record declaring a
~2e9 array block count with no elements now fails fast instead of attempting a
large allocation. Existing round-trip tests act as negative controls.
- Full `avro` module test suite passes.
### JIRA
- [AVRO-4324](https://issues.apache.org/jira/browse/AVRO-4324)
--
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]
