[Ruby] Ensure initializing all `rb_memory_view_t` members

[kou]

Describe the enhancement requested

rb_memory_view_get() caller may not pass zero-cleared rb_memory_view_t.

Component(s)

Ruby

[github-actions]

This issue has been marked as stale because it has had no activity in the past 365 days. Please remove the stale label or comment below, or this issue will be closed in 14 days. If this improvement is still desired but has no current owner, please add the 'Status: needs champion' label.

[himotoyoshi]

Hit this in practice on red-arrow 24.0.0 / ruby 3.4.1 / arm64-darwin24.
A C-extension consumer that stack-allocates rb_memory_view_t view;
sends the uninitialised view.item_desc.components straight into the
unconditional xfree at the end of rb_memory_view_release, and
libmalloc aborts the process. Current main is still affected
(primitive_array_get and buffer_get in ext/arrow/memory-view.cpp
do not initialise the item_desc fields).

Fix

Two lines in each of primitive_array_get (line 220 on main) and
buffer_get (line 247 on main):

view_->item_desc.components = NULL;
view_->item_desc.length     = 0;

Reproduction (stdlib + red-arrow only)

require "arrow"

# Bind rb_memory_view_get / rb_memory_view_release through Fiddle (FFI).
require "fiddle"
libruby = Fiddle.dlopen(nil)
rb_memory_view_get      = Fiddle::Function.new(libruby["rb_memory_view_get"],
                            [Fiddle::TYPE_UINTPTR_T, Fiddle::TYPE_VOIDP, Fiddle::TYPE_INT],
                            Fiddle::TYPE_INT)
rb_memory_view_release  = Fiddle::Function.new(libruby["rb_memory_view_release"],
                            [Fiddle::TYPE_VOIDP],
                            Fiddle::TYPE_INT)

# Allocate a buffer for rb_memory_view_t and fill it with non-zero
# garbage, mimicking an uninitialised stack-allocated struct.
view = Fiddle::Pointer.malloc(256)
256.times { |i| view[i] = 0xAA }

# Acquire and release a MemoryView on an Arrow::Int32Array.
arr = Arrow::Int32Array.new([1, 2, 3, 4, 5])
rb_memory_view_get.call(Fiddle.dlwrap(arr), view, 0)
rb_memory_view_release.call(view)

# ruby(...) malloc: *** error for object 0xaaaaaaaaaaaaaaaa:
#     pointer being freed was not allocated
# Abort trap: 6

Replacing 0xAA with 0 makes the same script complete cleanly,
confirming the abort is driven entirely by what value
item_desc.components happens to hold.

[kou]

Issue resolved by pull request 50234
#50234

[kou]

@Reranko05 Could you add "take" comment here?

[Reranko05]

take