Issue #20050 has been updated by martinemde (Martin Emde).
Subject changed from Segfault on Ruby 3.2.2 on x86_64 Darwin 20 (maybe in Array#hash) to
Segfault on Ruby 3.2.2 (and 3.1) on x86_64 Darwin 20 (rb_id_table_lookup for #hash)
I’m refining this more based on reading the ruby source (though I’m mostly struggling to
understand.)
It appears that this bug happens when trying to store an entry in a hash using
Gem::NameTuple as the key. NameTuple redefines `#hash`.
When ruby is checking if the key (a NameTuple) uses the built in hash method, it tries to
lookup hash in the method table and segfaults around that point.
Hope this helps. If needed I can create a rubygems branch that should fail with some
regularity to try to debug this better.
----------------------------------------
Bug #20050: Segfault on Ruby 3.2.2 (and 3.1) on x86_64 Darwin 20 (rb_id_table_lookup for
#hash)
https://bugs.ruby-lang.org/issues/20050#change-105673
* Author: martinemde (Martin Emde)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin20]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
Hi,
In the rubygems & bundler repositories we've now had two segfaults in the same
exact code within days of merging a change to that code, both on ruby 3.2.2 on darwin20.
1.
https://github.com/rubygems/rubygems/actions/runs/7110489973/job/1935706778…
2.
https://github.com/rubygems/rubygems/actions/runs/7131889001/job/1942130416…
The specific error seems to happen when calculating the hash of the array in
Gem::NameTuple#hash. The array contents that is being `.hash`ed both times should be
exactly: `["has_metadata", "1.0", "ruby"]`. If I'm
reading this correctly, this indicates that the crash is related either to creating this
hash or storing this hash in the hash table (I'm not quite sure which is triggering
the crash).
An excerpt of the C backtrace shows the same backtrace for both crashes:
```
-- C level backtrace information -------------------------------------------
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_vm_bugreport+0x7c4)
[0x10cb0f994]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_bug_for_fatal_signal+0x1d0)
[0x10c9158c0]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(sigsegv+0x5b)
[0x10ca609ab]
/usr/lib/system/libsystem_platform.dylib(_sigtramp+0x1d) [0x7ff810c14dfd]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_id_table_lookup+0x16)
[0x10caa2a56]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(callable_method_entry_or_negative+0x5e)
[0x10cae9c8e]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_check_funcall_basic_kw+0x129)
[0x10caf0039]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(obj_any_hash+0x3c)
[0x10c94bd2c]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(any_hash+0x52)
[0x10c94bc12]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_st_add_direct+0x1d)
[0x10ca69b7d]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(ar_try_convert_table+0x85)
[0x10c94d015]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_hash_aset+0x18f)
[0x10c94e26f]
```
I'm not sure how to follow this instruction in this case on GitHub actions:
"Don't forget to include the Crash Report log file under DiagnosticReports
directory in bug reports."
I have not been able to reproduce this locally with the same version of ruby (but I'm
on darwin22 instead of 20). I will follow up if we continue to see this same crash.
--
https://bugs.ruby-lang.org/