Repository navigation
GH-51029: [C++] Fix MapArray validation with unknown null count - #51093
Conversation
|
|
pitrou
left a comment
There was a problem hiding this comment.
Thanks for doing this @AnuragRaut08 ! See comments below.
Also, there are other uses of MayHaveNulls in array_nested.cc, shouldn't we fix them as well?
Reranko05
left a comment
There was a problem hiding this comment.
Also fix the lint by using:-
python -m pre_commit run clang-format --files <file_path>
0e4c2a2 to
4574e70
Compare
|
Done, ran clang-format on the affected C++ files with pre-commit. |
|
@pitrou I checked the other MayHaveNulls() uses in array_nested.cc. They are used for validating nullable list/map offsets when constructing arrays, rather than validating MapArray keys, so I left them unchanged. |
But the same issue applies: |
4574e70 to
aee42e9
Compare
|
Thanks, addressed. I have updated the remaining |
| MANIFEST | ||
| compile_commands.json | ||
| build.ninja | ||
| build/ |
|
@AlenkaF FYI |
pyarrow before 26 aborts the process when a cast changes a map's key type (string -> large_string) and the keys child carries a validity bitmap, which filter and take produce (apache/arrow#51029, fixed by apache/arrow#51093 in 26.0.0). PyIceberg 0.11.1's upsert makes exactly that cast after a filtered scan, so the data lake fuzzer's pyiceberg_rest writer aborted the whole pytest process on the first nightly Data lake fuzzer (arm_release) run, and the remaining writers never ran. Replaying 5000 pyiceberg_rest fuzzer histories in the runner image without ClickHouse: 53 abort with pyarrow 23.0.1, none with 26.0.1. pip check is clean; test_arrowflight_interface and test_storage_iceberg_no_spark pass identically on both versions. Related: ClickHouse#128538 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Rationale for this change
MapArrayvalidation usesMayHaveNulls()to check that the map child and keys contain no nulls. When an all-valid validity bitmap is present with an unknown null count,MayHaveNulls()can report that the array may contain nulls even though all values are valid.During a cast of a
MapArray, this can cause validation to return an invalid status which is passed toARROW_CHECK_OK, resulting in a process abort instead of a recoverable error.What changes are included in this PR?
GetNullCount()instead ofMayHaveNulls()when validating theMapArraychild and keys.kUnknownNullCount.Are these changes tested?
Yes, with existing and additional unit tests.
Are there any user-facing changes?
Only a bugfix.
This PR contains a "Critical Fix".
This fixes a bug that can cause a process crash when casting a valid
MapArraywhose keys carry an all-valid validity bitmap with an unknown null count. This is easily reproduced in Python: