[C++] ListArray::FromListView gives wrong nulls for sliced list-view arrays
Maintainer thường phản hồi trong vòng 2 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 86/100
Hướng nghiên cứu
Bắt đầu trong cpp/src/arrow/array/array_nested.cc tại ListFromListViewImpl và so sánh cách truy cập validity-bitmap của nó với FlattenListViewArray, đặc biệt là cách xử lý offset. Tái hiện vấn đề bằng ví dụ list-view đã được slice, sau đó thêm hoặc cập nhật một regression test để ListArray::FromListView và LargeListArray::FromListView giữ nguyên các giá trị null trong đầu vào.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Describe the bug, including details regarding any error messages, version, and platform.
ListArray::FromListView (and LargeListArray::FromListView) returns the wrong validity for a sliced list-view array with nulls.
auto views = arrow::json::ArrayFromJSONString(
arrow::list_view(arrow::int32()),
"[[1], [2], [3], [4], [5], [6], [7], [8], null, [10], [11]]")
.ValueOrDie();
auto sliced = std::static_pointer_cast<arrow::ListViewArray>(views->Slice(1));
auto lists =
arrow::ListArray::FromListView(*sliced, arrow::default_memory_pool()).ValueOrDie();
// is null (list view): 0 0 0 0 0 0 0 1 0 0
// is null (list): 0 0 1 1 1 1 1 1 1 1
Expected: the same nulls as the input.
In ListFromListViewImpl (cpp/src/arrow/array/array_nested.cc), the validity bitmap is read with list_view_data->GetValues<uint8_t>(0), which already advances the pointer by offset bytes. It is then passed to bit_util::GetBit(in_validity_bitmap, list_view_data->offset + i), which applies the offset again, in bits. FlattenListViewArray in the same file does this correctly with GetValues<uint8_t>(0, 0).
Found while trying to use FromListView in a compute kernel (GH-33295). Related: GH-51612, where the list_view to list cast could use FromListView. Reproduced on current main, Linux x86_64.
Component(s)
C++
- Ngôn ngữ chính
- C++
- Star
- 17.1k
- Fork
- 4.3k
- Merge trung bình
- 4 ngày 5 giờ
- Pull request đã merge (30 ngày)
- 106
Chuẩn bị môi trường
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của apache/arrow
-
Component: C++ Type: enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 2 ngày
-
Component: GLib
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 2 ngày
-
Component: Python Type: enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
apache/arrow#51474 · 4 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Component: Continuous Integration Component: MATLAB Type: enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 2 ngày
-
[C++][Parquet] Update bundled Apache Thrift to 0.24.0 for CVE-2026-55969Có thể đã có người làm @Hanayoshi-8744 đã nhận 3 ngày trước. Đang mởComponent: C++ Component: Parquet Type: enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
apache/arrow#51354 · 1 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 2 ngày
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Icinga/icinga2#11058 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
component: split-view platform: windows
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
zen-browser/desktop#15616 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
-
area/ysql kind/bug priority/medium status/awaiting-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
yugabyte/yugabyte-db#34415 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
WayfireWM/wayfire#3148 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày