GH-45187: [Ruby] Ensure initializing all rb_memory_view_t members

[Reranko05]

Rationale for this change

rb_memory_view_get() callers may pass a non-zero-initialized rb_memory_view_t. primitive_array_get() and buffer_get() did not initialize item_desc.components and item_desc.length, which could cause rb_memory_view_release() to attempt to free an invalid pointer and abort the process.

What changes are included in this PR?

This change initializes item_desc.components and item_desc.length in both primitive_array_get() and buffer_get().

It also adds regression tests that verify releasing a memory view with a non-zero-initialized rb_memory_view_t does not crash for both Arrow::Int32Array and Arrow::Buffer.

Are these changes tested?

Yes. Added regression tests in test-memory-view.rb that reproduced the crash before this change and pass after the fix.

Are there any user-facing changes?

No.

This PR contains a "Critical Fix".

This change fixes a crash that could occur when rb_memory_view_release() is called with a memory view whose item_desc members were not initialized.

• GitHub Issue: [Ruby] Ensure initializing all rb_memory_view_t members #45187

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[github-actions]

⚠️ GitHub issue #45187 has been automatically assigned in GitHub to PR creator.

[Reranko05]

@kou The lint failure appears unrelated to this PR. It was caused by a ShellCheck Docker image pull issue. The same dev lint workflow passes successfully on my fork.

[Reranko05]

@kou Thanks for the review. Addressed all review comments.

• Switched memory view initialization to memset(view_, 0, sizeof(memory_view)).
• Added regression tests for uninitialized rb_memory_view_t handling under a dedicated sub_test_case.
• Updated the Fiddle bindings to use TYPE_BOOL.
• Used Fiddle::Pointer.malloc(..., Fiddle::RUBY_FREE) for automatic cleanup.
• Replaced assert_nothing_raised with explicit return value checks.

[Reranko05]

@kou One question about the regression tests: I added the sub_test_case structure you suggested, but I noticed your earlier comment about avoiding the hard-coded 256 size and possibly not adding tests for this case at all.

Would you prefer keeping the tests as they are now, or removing them entirely?

[kou]

I prefered not adding tests for this at all in the first review because I feel that we don't want to maintain these tests. But I'm OK with adding them now because they are organized now.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Reranko05]

I prefered not adding tests for this at all in the first review because I feel that we don't want to maintain these tests. But I'm OK with adding them now because they are organized now.

@kou Thanks for the clarification.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[kou]

+1

[Reranko05]

@kou Thanks for the review. All CI checks have completed successfully now.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit 12b3eda.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 8 possible false positives for unstable benchmarks that are known to sometimes produce them.