You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[C++][Python] Casting a MapArray whose keys child carries an all-valid validity bitmap aborts the process (residual case of GH-38553) #51029
Describe the bug, including details regarding any error messages, version, and platform.
Casting a map array still hard-aborts the process (SIGABRT, not a raised exception) with Map array keys array should have no nulls when the keys child carries a validity bitmap — even an all-valid one. This is a residual case of #38553: the fix in #41957 changed MapArray::ValidateChildData to use MayHaveNulls(), which resolved the no-bitmap repro on that issue, but MayHaveNulls() answers true whenever a validity bitmap is present and the null count is unknown — it never counts. A cast's output starts with an unknown null count, so the fatal ARROW_CHECK_OK(ValidateChildData(...)) in MapArray::SetData (array_nested.cc:912 as of current main) kills the process.
Three-line reproduction, all public API, on pyarrow 24.0.0 (the current release):
/Users/runner/work/crossbow/crossbow/arrow/cpp/src/arrow/array/array_nested.cc:912: Check failed: _s.ok() Operation failed: ValidateChildData(data->child_data)
Bad status: Invalid: Map array keys array should have no nulls
Exit code 134. The filter call itself succeeds and the filtered array passes validate(full=True).
filter matters only because it materializes new child arrays that carry an all-valid validity bitmap; slice re-views the original buffers without one, which is why the slice→cast variant works after #41957. The bitmap alone is sufficient — same abort with no filter involved:
Forcing null-count computation on the input (m.keys.null_count → 0) does not help: the cast produces a fresh keys ArrayData whose count is unknown again.
Real-world impact: pyiceberg's scan path does filter-then-cast (row-filtered Parquet read, then cast to large types), so any row-filtered scan that projects a map column kills the worker process.
Two candidate fixes, possibly both:
MapArray::ValidateChildData (array_nested.cc:899/905) could force-compute the null count (GetNullCount() != 0) rather than ask MayHaveNulls(); counting an all-valid bitmap is cheap next to aborting the process.
The ARROW_CHECK_OK at array_nested.cc:912 turns an Invalid status into process death even when the data is genuinely invalid; a returned/raised error would be recoverable.
I'd like to take this issue up and work on the fix. I'll first reproduce the crash and investigate the MapArray validation/casting path, then add a regression test covering the all-valid validity bitmap case.
Implemented the fix in PR #51093.
The MapArray validation now correctly handles all-valid validity bitmaps with an unknown null count, and the regression tests pass successfully.
Please have a look when you get a chance.
Activity
AnuragRaut08 commentedon Aug 29, 2026
I'd like to take this issue up and work on the fix. I'll first reproduce the crash and investigate the MapArray validation/casting path, then add a regression test covering the all-valid validity bitmap case.
AnuragRaut08 commentedon Aug 31, 2026
Implemented the fix in PR #51093.
The
MapArrayvalidation now correctly handles all-valid validity bitmaps with an unknown null count, and the regression tests pass successfully.Please have a look when you get a chance.
apacheGH-51029: fix MapArray validation with unknown null count
apacheGH-51029: fix MapArray validation with unknown null count
GH-51029: [C++] Fix MapArray validation with unknown null count (#51093)
pitrou commentedon Sep 2, 2026
Issue resolved by pull request 51093
#51093
fix(write): write a small object to S3 in one request, not three (#172)