Scattering into or from a sliced lists column produces wrong child rows whenever the list child is not fixed-width.
list_child_constructor in cpp/src/lists/copying/scatter_helper.cu reads the parent lists offsets with the raw row index and ignores the column view offset:
- strings branch:
strings_offset = lists_offsets_ptr[row_index] + intra_index
- nested-lists branch:
child_row_index = lists_offsets_ptr[row_index] + intra_index
For a sliced source or target view, row_index is relative to the view but the offsets data pointer is not shifted, so both reads land on the wrong offsets entry and the constructed child copies from wrong rows of the underlying buffer. The fixed-width branch is unaffected because element access goes through list_device_view, whose constructor already applies the offset (offsets.element(row_index + lists_column.offset())).
The struct branch has the same problem one level up: project_member_as_list_view builds the member-as-list column_view with the offset hardcoded to 0, so a sliced List<Struct> source or target misindexes both offsets values and null-mask bits inside its members.
Observed with a standalone program against libcudf 26.10 nightly: scattering a sliced 4-row List<List<int>> source (slice {1,3}) produced leaf values 10 11 12 13 14 where 13 14 15 was expected.
Suggested fix: use lists_column_device_view::offset_at(row_index) (which indexes offsets()[offset() + idx]) at the two device sites, and pass the parent's offset() into project_member_as_list_view. Both are no-ops when offset() == 0.
Scattering into or from a sliced lists column produces wrong child rows whenever the list child is not fixed-width.
list_child_constructorincpp/src/lists/copying/scatter_helper.cureads the parent lists offsets with the raw row index and ignores the column view offset:strings_offset = lists_offsets_ptr[row_index] + intra_indexchild_row_index = lists_offsets_ptr[row_index] + intra_indexFor a sliced source or target view,
row_indexis relative to the view but the offsets data pointer is not shifted, so both reads land on the wrong offsets entry and the constructed child copies from wrong rows of the underlying buffer. The fixed-width branch is unaffected because element access goes throughlist_device_view, whose constructor already applies the offset (offsets.element(row_index + lists_column.offset())).The struct branch has the same problem one level up:
project_member_as_list_viewbuilds the member-as-listcolumn_viewwith the offset hardcoded to0, so a slicedList<Struct>source or target misindexes both offsets values and null-mask bits inside its members.Observed with a standalone program against libcudf 26.10 nightly: scattering a sliced 4-row
List<List<int>>source (slice {1,3}) produced leaf values10 11 12 13 14where13 14 15was expected.Suggested fix: use
lists_column_device_view::offset_at(row_index)(which indexesoffsets()[offset() + idx]) at the two device sites, and pass the parent'soffset()intoproject_member_as_list_view. Both are no-ops whenoffset() == 0.