Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Adjust FFI_ArrowArray offset based on the offset of offset buffer #5895

Merged
merged 4 commits into from
Jun 20, 2024

Conversation

viirya
Copy link
Member

@viirya viirya commented Jun 15, 2024

Which issue does this PR close?

Closes #5896.

Rationale for this change

What changes are included in this PR?

Are there any user-facing changes?

Copy link
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @viirya -- I verified that this PR fixes the test case and therefore I think it is an improvement.

However, I am a bit confused about how the pointer and data buffer can be different so I left some additional comments / suggestions on how we might make that better

}

#[test]
fn test_extend_imported_string_slice() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ran this test without the code changes in this PR and it fails like

range end index 10890 out of range for slice of length 5500
thread 'ffi::tests_from_ffi::test_extend_imported_string_slice' panicked at arrow-data/src/transform/variable_size.rs:38:29:
range end index 10890 out of range for slice of length 5500
stack backtrace:

Thus I believe the test correctly covers the new code

@@ -1458,4 +1460,58 @@ mod tests_from_ffi {

test_round_trip(&imported_array.consume()?)
}

fn export_string(array: StringArray) -> StringArray {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps calling this function "roundtrip_string_array" would better describe what it does

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it looks better.

// the `FFI_ArrowArray` offset field.
Some(unsafe {
let b = &data.buffers()[0];
b.as_ptr().offset_from(b.get_bytes().ptr().as_ptr()) as usize
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this calculation assumes that the string data begins at the start of the buffer (aka b.as_ptr() is the base).

I double checked and the comments seem to imply that that is always the case
https://github.com/apache/arrow-rs/blob/c096172b769da8003ea7816086df60f38229a891/arrow-buffer/src/bytes.rs#L40-L39

Since this is calculating on internal state of Buffer, I think this code would be easier to understand / document if we added a method to Buffer that did the calculation and could be documented better:

Something like

impl Buffer {
  .. 
  /// Returns the offset, in bytes, of `Self::ptr` to `Self::data`
  ///
  /// self.ptr and self.data can be different in the following cases:
  /// TODO
  fn ptr_offset(&self) -> usize {
...
  }

I was non obvious to me when reading the Buffer code that it was possible for ptr and data to be different

@@ -71,6 +71,11 @@ impl Buffer {
}
}

/// Returns the internal byte buffer.
pub fn get_bytes(&self) -> Arc<Bytes> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than exposing an internal detail, perhaps we can move the offset calculation into Buffer (see suggestion below). In addition to keeping the code more encapsulated, I think it would also likely be faster as it would avoid the Arc clone.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestion.

@andygrove
Copy link
Member

Thanks for review @alamb. This is a blocking issue for our first Comet release. Do you think it would be possible to create a patch release of arrow-rs to include this fix (once we are through the review process)?

@alamb
Copy link
Contributor

alamb commented Jun 17, 2024

Thanks for review @alamb. This is a blocking issue for our first Comet release. Do you think it would be possible to create a patch release of arrow-rs to include this fix (once we are through the review process)?

For sure -- I filed #5906 to track the idea

@@ -71,6 +71,24 @@ impl Buffer {
}
}

/// Returns the offset, in bytes, of `Self::ptr` to `Self::data`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

// Handle buffer offset for offset buffer.
let offset_offset = match data.data_type() {
DataType::Utf8 | DataType::Binary => {
// Offset buffer is possible a slice of the buffer.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this looks much nicer now

/// This function is unsafe as it uses unsafe function `offset_from`. Under certain
/// conditions, this function can cause undefined behavior. See the documentation of
/// `offset_from` for more information.
pub unsafe fn ptr_offset(&self) -> usize {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if this function should be unsafe. The ptr should always be in bounds of data, any safe function that modifies ptr should uphold that invariant. If it is not in bounds then nearly all other methods of Buffer would also expose UB.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. slice, advance and slice_with_length even as_ptr are all safe functions.

@viirya viirya force-pushed the fix_string_offset_ffi branch 2 times, most recently from 4959548 to c1dd831 Compare June 18, 2024 15:17
@viirya viirya merged commit 20a569a into apache:master Jun 20, 2024
25 checks passed
@viirya
Copy link
Member Author

viirya commented Jun 20, 2024

Thanks @alamb @andygrove @jhorstmann

@viirya viirya deleted the fix_string_offset_ffi branch June 20, 2024 01:43
@tustvold
Copy link
Contributor

I intend to take a closer look at this tomorrow, as I'm not entirely sure it is correct

@viirya
Copy link
Member Author

viirya commented Jun 26, 2024

Let me know if you have any question about the issue we encountered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arrow Changes to the arrow crate
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Out of range when extending on a slice of string array imported through FFI
5 participants