[ruby-core:115649] [Ruby master Bug#20050] Segfault on Ruby 3.2.2 on x86_64 Darwin 20 (maybe in Array#hash)
7 Dec
2023
7 Dec
'23
7:57 p.m.
Issue #20050 has been reported by martinemde (Martin Emde).
----------------------------------------
Bug #20050: Segfault on Ruby 3.2.2 on x86_64 Darwin 20 (maybe in Array#hash)
https://bugs.ruby-lang.org/issues/20050
* 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/
8 Dec
8 Dec
5:42 p.m.
New subject: [ruby-core:115662] [Ruby master Bug#20050] Segfault on Ruby 3.2.2 on x86_64 Darwin 20 (maybe in Array#hash)
Issue #20050 has been updated by martinemde (Martin Emde).
Another failure with a slightly different C backtrace.
https://github.com/rubygems/rubygems/actions/runs/7133159688/job/19425249816
```
-- C level backtrace information -------------------------------------------
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_vm_bugreport+0x7c4)
[0x1070a6994]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_bug_for_fatal_signal+0x1d0)
[0x106eac8c0]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(sigsegv+0x5b)
[0x106ff79ab]
/usr/lib/system/libsystem_platform.dylib(_sigtramp+0x1d) [0x7ff815fdcdfd]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(ruby_sip_hash13+0x60)
[0x106fa7cb0]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_str_hash+0x62)
[0x10700df12]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(any_hash+0x35)
[0x106ee2bf5]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_st_add_direct+0x1d)
[0x107000b7d]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(ar_try_convert_table+0x85)
[0x106ee4015]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_hash_aset+0x18f)
[0x106ee526f]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(vm_exec_core+0x60a3)
[0x10707d9b3]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_vm_exec+0xbfa)
[0x10708fcca]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(invoke_block_from_c_bh+0x71e)
[0x1070a14ee]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(loop_i+0x5f)
[0x1070a08ef]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_vrescue2+0x187)
[0x106eb8d87]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_rescue2+0x7b)
[0x106eb8bdb]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(vm_call_cfunc_with_frame+0x15d)
[0x10709a2dd]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(vm_sendish+0x4c7)
[0x10709cab7]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(vm_exec_core+0x2b66)
[0x10707a476]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_vm_exec+0xbfa)
[0x10708fcca]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_vm_invoke_proc+0xd4a)
[0x10708d98a]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(thread_do_start_proc+0x2ab)
[0x10704773b]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(thread_start_func_2+0x500)
[0x107046d80]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(thread_start_func_1+0x17c)
[0x10704663c]
/usr/lib/system/libsystem_pthread.dylib(_pthread_start+0x7d) [0x7ff815fc74e1]
```
----------------------------------------
Bug #20050: Segfault on Ruby 3.2.2 on x86_64 Darwin 20 (maybe in Array#hash)
https://bugs.ruby-lang.org/issues/20050#change-105599
* 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/
12 Dec
12 Dec
1:37 a.m.
New subject: [ruby-core:115712] [Ruby master Bug#20050] Segfault on Ruby 3.2.2 on x86_64 Darwin 20 (maybe in Array#hash)
Issue #20050 has been updated by martinemde (Martin Emde).
We updated the code, guessing that overriding .new on NameTuple was causing something
weird. This new segfault happened again but with no patch applied to NameTuple
new/initialize because of a guard. I don't know where to go from here.
https://github.com/rubygems/rubygems/actions/runs/7175297908/job/1953835242…
----------------------------------------
Bug #20050: Segfault on Ruby 3.2.2 on x86_64 Darwin 20 (maybe in Array#hash)
https://bugs.ruby-lang.org/issues/20050#change-105642
* 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/
13 Dec
13 Dec
11:23 p.m.
New subject: [ruby-core:115738] [Ruby master Bug#20050] Segfault on Ruby 3.2.2 on x86_64 Darwin 20 (maybe in Array#hash)
Issue #20050 has been updated by martinemde (Martin Emde).
One more.
https://github.com/rubygems/rubygems/actions/runs/7187119964/job/1957401519…
We have decided to stop using Gem::NameTuple as a hash key to avoid this crash when we
release bundler 2.5.0.
This is the one that finally made us decide to remove it:
https://github.com/rubygems/rubygems/actions/runs/7197973441/job/19606353088
In this one you can see `double free or corruption (fasttop)` and this is on ubuntu.
----------------------------------------
Bug #20050: Segfault on Ruby 3.2.2 on x86_64 Darwin 20 (maybe in Array#hash)
https://bugs.ruby-lang.org/issues/20050#change-105671
* 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/
14 Dec
14 Dec
7:54 a.m.
New subject: [ruby-core:115740] [Ruby master Bug#20050] Segfault on Ruby 3.2.2 (and 3.1) on x86_64 Darwin 20 (rb_id_table_lookup for #hash)
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/
10:57 a.m.
New subject: [ruby-core:115742] [Ruby master Bug#20050] Segfault on Ruby 3.2.2 (and 3.1) on x86_64 Darwin 20 (rb_id_table_lookup for #hash)
Issue #20050 has been updated by mame (Yusuke Endoh).
I'm not sure if this is really the same problem, but I was able to segfault with the
following code.
```ruby
srand(0)
class Foo
def to_a
[]
end
def hash
$h.delete($h.keys.sample) if rand < 0.1
to_a.hash
end
end
GC.stress = true
100.times do
$h = {}
(0..10).each {|i| $h[Foo.new] ||= {} }
end
```
```
t.rb:17: [BUG] Segmentation fault at 0x0000000000000034
ruby 3.3.0dev (2023-12-14T08:39:42Z master e51f9e9f75) [x86_64-linux]
-- Control frame information -----------------------------------------------
c:0007 p:---- s:0029 e:000028 CFUNC :hash
c:0006 p:0021 s:0026 e:000021 BLOCK ../t.rb:17 [FINISH]
c:0005 p:---- s:0018 e:000017 CFUNC :each
c:0004 p:0009 s:0014 e:000013 BLOCK ../t.rb:17
c:0003 p:0025 s:0011 e:000010 METHOD <internal:numeric>:237
c:0002 p:0025 s:0006 e:000005 EVAL ../t.rb:15 [FINISH]
c:0001 p:0000 s:0003 E:001dd0 DUMMY [FINISH]
-- Ruby level backtrace information ----------------------------------------
../t.rb:15:in `<main>'
<internal:numeric>:237:in `times'
../t.rb:17:in `block in <main>'
../t.rb:17:in `each'
../t.rb:17:in `block (2 levels) in <main>'
../t.rb:17:in `hash'
-- Threading information ---------------------------------------------------
Total ractor count: 1
Ruby thread count for this ractor: 1
-- Machine register context ------------------------------------------------
RIP: 0x0000564aa444d3ab RBP: 0x00007f48494e4b00 RSP: 0x00007fffa788b410
RAX: 0x0000000000000000 RBX: 0x0000564aa6749e40 RCX: 0x0000564aa444d370
RDX: 0x0000000000000000 RDI: 0x0000000000000024 RSI: 0x0000000000000000
R8: 0x0000000000000ac1 R9: 0x00007f48494e4b00 R10: 0x0000000000000000
R11: 0x0000000000000024 R12: 0x0000564aa6709580 R13: 0x0000564aa6709580
R14: 0x00007f48495feec0 R15: 0x0000000000000000 EFL: 0x0000000000010293
-- C level backtrace information -------------------------------------------
/home/mame/work/ruby/miniruby(rb_print_backtrace+0x14) [0x564aa4585a94]
/home/mame/work/ruby/vm_dump.c:820
/home/mame/work/ruby/miniruby(rb_vm_bugreport) /home/mame/work/ruby/vm_dump.c:1151
/home/mame/work/ruby/miniruby(rb_bug_for_fatal_signal+0x14c) [0x564aa43bd4dc]
/home/mame/work/ruby/error.c:1065
/home/mame/work/ruby/miniruby(sigsegv+0x53) [0x564aa44e6633]
/home/mame/work/ruby/signal.c:920
/lib/x86_64-linux-gnu/libc.so.6(0x7f4849a42910) [0x7f4849a42910]
./miniruby(rb_float_noflonum_value+0x0) [0x564aa444d3ab]
/home/mame/work/ruby/miniruby(rb_float_flonum_value) ./internal/numeric.h:240
/home/mame/work/ruby/miniruby(rb_float_value_inline) ./internal/numeric.h:238
/home/mame/work/ruby/miniruby(flo_hash) /home/mame/work/ruby/numeric.c:1652
/home/mame/work/ruby/miniruby(vm_call0_cfunc_with_frame+0xca) [0x564aa457e356]
./vm_eval.c:173
/home/mame/work/ruby/miniruby(vm_call0_cfunc) ./vm_eval.c:187
/home/mame/work/ruby/miniruby(vm_call0_body) ./vm_eval.c:233
/home/mame/work/ruby/miniruby(rb_funcallv+0x212) [0x564aa4564902] ./vm_eval.c:110
/home/mame/work/ruby/miniruby(vm_catch_protect+0xfe) [0x564aa456a91e] ./vm_eval.c:2369
/home/mame/work/ruby/miniruby(exec_recursive+0x216) [0x564aa4529e76]
/home/mame/work/ruby/thread.c:5179
/home/mame/work/ruby/miniruby(obj_any_hash+0x56) [0x564aa43f2486]
/home/mame/work/ruby/hash.c:218
/home/mame/work/ruby/miniruby(any_hash+0x4c) [0x564aa43f239c]
/home/mame/work/ruby/hash.c:203
/home/mame/work/ruby/miniruby(do_hash+0x6) [0x564aa44ee2d8] /home/mame/work/ruby/st.c:320
/home/mame/work/ruby/miniruby(rb_st_add_direct) /home/mame/work/ruby/st.c:1183
/home/mame/work/ruby/miniruby(ar_try_convert_table+0xbf) [0x564aa43f35df]
/home/mame/work/ruby/hash.c:714
/home/mame/work/ruby/miniruby(RHASH_ST_TABLE+0x0) [0x564aa43f456e]
/home/mame/work/ruby/hash.c:1641
/home/mame/work/ruby/miniruby(rb_hash_stlike_update) /home/mame/work/ruby/hash.c:1648
/home/mame/work/ruby/miniruby(tbl_update) /home/mame/work/ruby/hash.c:1689
./miniruby(rb_hash_aset+0xa7) [0x564aa43f44f7]
/home/mame/work/ruby/miniruby(vm_exec_core+0x5708) [0x564aa4560098]
./vm_insnhelper.c:6328
/home/mame/work/ruby/miniruby(vm_exec_loop+0x0) [0x564aa45598ad]
/home/mame/work/ruby/vm.c:2486
/home/mame/work/ruby/miniruby(rb_vm_exec) /home/mame/work/ruby/vm.c:2489
./miniruby(invoke_block_from_c_bh+0x469) [0x564aa4580439]
/home/mame/work/ruby/miniruby(vm_yield_with_cref+0x46) [0x564aa45686f5]
/home/mame/work/ruby/vm.c:1634
/home/mame/work/ruby/miniruby(vm_yield) /home/mame/work/ruby/vm.c:1642
/home/mame/work/ruby/miniruby(rb_yield_0) ./vm_eval.c:1366
/home/mame/work/ruby/miniruby(rb_yield) ./vm_eval.c:1382
/home/mame/work/ruby/miniruby(range_each_fixnum_loop+0x32) [0x564aa44a1df8]
/home/mame/work/ruby/range.c:911
/home/mame/work/ruby/miniruby(range_each) /home/mame/work/ruby/range.c:948
/home/mame/work/ruby/miniruby(vm_call_cfunc_with_frame_+0xf4) [0x564aa4578574]
./vm_insnhelper.c:3490
/home/mame/work/ruby/miniruby(vm_sendish+0xd6) [0x564aa455cd2b] ./vm_insnhelper.c:5581
/home/mame/work/ruby/miniruby(vm_exec_core) /home/mame/work/ruby/insns.def:814
/home/mame/work/ruby/miniruby(vm_exec_loop+0x0) [0x564aa45598ad]
/home/mame/work/ruby/vm.c:2486
/home/mame/work/ruby/miniruby(rb_vm_exec) /home/mame/work/ruby/vm.c:2489
/home/mame/work/ruby/miniruby(rb_ec_exec_node+0x2b) [0x564aa43c985b]
/home/mame/work/ruby/eval.c:287
/home/mame/work/ruby/miniruby(ruby_run_node) /home/mame/work/ruby/eval.c:328
/home/mame/work/ruby/miniruby(rb_main+0x1c) [0x564aa4318605] ./main.c:39
/home/mame/work/ruby/miniruby(main) ./main.c:58
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_call_main+0x80) [0x7f4849a280d0]
../sysdeps/nptl/libc_start_call_main.h:58
/lib/x86_64-linux-gnu/libc.so.6(call_init+0x0) [0x7f4849a28189] ../csu/libc-start.c:360
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main_impl) ../csu/libc-start.c:347
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main) (null):0
[0x564aa43184c5]
```
@martinemde Question to confirm if this is the same problem as yours: Does bundler access
the hash in question ([Bundler::Checksum::Store's
@store](https://github.com/rubygems/rubygems/commit/34d6c6c72f6099c83860d81b9810d0b1441d802d#diff-63b5dabde4934e1fdd1bf24aea2b5bcfa5c4c3bbcf28112bc10e46cb4a73c30aL167))
from multiple threads in parallel?
The problem I found occurs when a Hash is updated from another thread while
`ar_try_convert_table` is converting the internal representation of the hash. Since the
key implements `#hash` method in Ruby, I think a context switch is possible during the
conversion of `ar_try_convert_table`.
----------------------------------------
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-105675
* 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/
11:37 a.m.
New subject: [ruby-core:115743] [Ruby master Bug#20050] Segfault on Ruby 3.2.2 (and 3.1) on x86_64 Darwin 20 (rb_id_table_lookup for #hash)
Issue #20050 has been updated by Eregon (Benoit Daloze).
mame (Yusuke Endoh) wrote in #note-5:
@martinemde Question to confirm if this is the same
problem as yours: Does bundler access the hash in question
([Bundler::Checksum::Store's
@store](https://github.com/rubygems/rubygems/commit/34d6c6c72f6099c83860d81b9810d0b1441d802d#diff-63b5dabde4934e1fdd1bf24aea2b5bcfa5c4c3bbcf28112bc10e46cb4a73c30aL167))
from multiple threads in parallel?
If so, it sounds best to use a Mutex around accesses to that Hash, as it can cause issues
on other Ruby implementations as well (or have separate Hash instances per thread).
----------------------------------------
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-105676
* 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/
6:59 p.m.
New subject: [ruby-core:115746] [Ruby master Bug#20050] Segfault on Ruby 3.2.2 (and 3.1) on x86_64 Darwin 20 (rb_id_table_lookup for #hash)
Issue #20050 has been updated by ko1 (Koichi Sasada).
This is a patch: https://github.com/ruby/ruby/pull/9240
I'm happy if this patch solves your question.
----------------------------------------
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-105678
* 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/
16 Dec
16 Dec
5:50 a.m.
New subject: [ruby-core:115761] [Ruby master Bug#20050] Segfault on Ruby 3.2.2 (and 3.1) on x86_64 Darwin 20 (rb_id_table_lookup for #hash)
Issue #20050 has been updated by martinemde (Martin Emde).
mame (Yusuke Endoh) wrote in #note-5:
I'm not sure if this is really the same problem
…
Does bundler access the hash in question
([Bundler::Checksum::Store's
@store](https://github.com/rubygems/rubygems/commit/34d6c6c72f6099c83860d81b9810d0b1441d802d#diff-63b5dabde4934e1fdd1bf24aea2b5bcfa5c4c3bbcf28112bc10e46cb4a73c30aL167))
from multiple threads in parallel?
The problem I found occurs when a Hash is updated from another thread while
`ar_try_convert_table` is converting the internal representation of the hash. Since the
key implements `#hash` method in Ruby, I think a context switch is possible during the
conversion of `ar_try_convert_table`.
This seems likely. @eregon’s suggestion along with converting to a string key is what we
ended up using as a final fix.
https://github.com/rubygems/rubygems/pull/7283
Thank you for your help tracking this down and for applying a fix! Segfaults are so rare
in Ruby that a consistent one like this is a surprise.
----------------------------------------
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-105698
* Author: martinemde (Martin Emde)
* Status: Closed
* 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/
28 Mar
28 Mar
5:01 a.m.
New subject: [ruby-core:117356] [Ruby master Bug#20050] Segfault on Ruby 3.2.2 (and 3.1) on x86_64 Darwin 20 (rb_id_table_lookup for #hash)
Issue #20050 has been updated by kjtsanaktsidis (KJ Tsanaktsidis).
Backport changed from 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN to 3.0: UNKNOWN, 3.1:
UNKNOWN, 3.2: REQUIRED, 3.3: DONTNEED
Any chance this could be backported into Ruby 3.2? It was a bit tricky because of the
VWA-related changes in 3.3, but I did manage to open a PR to do this:
https://github.com/ruby/ruby/pull/10394
I'm running into this problem with the debug gem:
```
/__w/zendesk/zendesk/.bundle_deployment/ruby/3.2.0/gems/debug-1.8.0/lib/debug/session.rb:1624:
[BUG] Segmentation fault at 0x0000000000000034
ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]
-- Control frame information -----------------------------------------------
c:0007 p:---- s:0053 e:000052 CFUNC :hash
c:0006 p:0054 s:0050 e:000045 METHOD
/__w/zendesk/zendesk/.bundle_deployment/ruby/3.2.0/gems/debug-1.8.0/lib/debug/session.rb:1624
c:0005 p:0018 s:0041 e:000040 METHOD
/__w/zendesk/zendesk/.bundle_deployment/ruby/3.2.0/gems/debug-1.8.0/lib/debug/session.rb:1617
c:0004 p:0061 s:0036 e:000035 METHOD
/__w/zendesk/zendesk/.bundle_deployment/ruby/3.2.0/gems/debug-1.8.0/lib/debug/session.rb:270
c:0003 p:0012 s:0012 e:000011 METHOD
/__w/zendesk/zendesk/.bundle_deployment/ruby/3.2.0/gems/debug-1.8.0/lib/debug/session.rb:249
c:0002 p:0118 s:0007 E:0014c8 BLOCK
/__w/zendesk/zendesk/.bundle_deployment/ruby/3.2.0/gems/debug-1.8.0/lib/debug/session.rb:207
[FINISH]
c:0001 p:---- s:0003 e:000002 DUMMY [FINISH]
-- Ruby level backtrace information ----------------------------------------
/__w/zendesk/zendesk/.bundle_deployment/ruby/3.2.0/gems/debug-1.8.0/lib/debug/session.rb:207:in
`block in activate'
/__w/zendesk/zendesk/.bundle_deployment/ruby/3.2.0/gems/debug-1.8.0/lib/debug/session.rb:249:in
`session_server_main'
/__w/zendesk/zendesk/.bundle_deployment/ruby/3.2.0/gems/debug-1.8.0/lib/debug/session.rb:270:in
`process_event'
/__w/zendesk/zendesk/.bundle_deployment/ruby/3.2.0/gems/debug-1.8.0/lib/debug/session.rb:1617:in
`on_thread_begin'
/__w/zendesk/zendesk/.bundle_deployment/ruby/3.2.0/gems/debug-1.8.0/lib/debug/session.rb:1624:in
`create_thread_client'
/__w/zendesk/zendesk/.bundle_deployment/ruby/3.2.0/gems/debug-1.8.0/lib/debug/session.rb:1624:in
`hash'
-- Machine register context ------------------------------------------------
RIP: 0x00007f75f3a8acf4 RBP: 0x00007f75c3eacb50 RSP: 0x00007f75c3eacb50
RAX: 0x0000000000000000 RBX: 0x0000000000000024 RCX: 0x00007f75f3a8ace0
RDX: 0x0000000000000000 RDI: 0x0000000000000024 RSI: 0x0000000000000000
R8: 0x0000000055550083 R9: 0x0000000000000000 R10: 0x00007f75f210f260
R11: 0x0000000000000000 R12: 0x00007f75c3fad1c0 R13: 0x00007f75c7f9abd0
R14: 0x0000000000000000 R15: 0x0000000000001091 EFL: 0x0000000000010293
-- C level backtrace information -------------------------------------------
/usr/lib/libruby.so.3.2(rb_print_backtrace+0x11) [0x7f75f3bf6adf] vm_dump.c:785
/usr/lib/libruby.so.3.2(rb_vm_bugreport) vm_dump.c:1080
/usr/lib/libruby.so.3.2(rb_bug_for_fatal_signal+0xfc) [0x7f75f39e3ffc] error.c:813
/usr/lib/libruby.so.3.2(sigsegv+0x59) [0x7f75f3b44029] signal.c:964
/lib/x86_64-linux-gnu/libpthread.so.0(__restore_rt+0x0) [0x7f75f3355420]
/usr/lib/libruby.so.3.2(rb_float_noflonum_value+0x0) [0x7f75f3a8acf4]
internal/numeric.h:239
/usr/lib/libruby.so.3.2(rb_float_value_inline) internal/numeric.h:242
/usr/lib/libruby.so.3.2(flo_hash) numeric.c:1651
/usr/lib/libruby.so.3.2(vm_cfp_consistent_p+0x0) [0x7f75f3be9071] vm_eval.c:150
/usr/lib/libruby.so.3.2(vm_call0_cfunc_with_frame) vm_eval.c:152
/usr/lib/libruby.so.3.2(vm_call0_cfunc) vm_eval.c:164
/usr/lib/libruby.so.3.2(vm_call0_body) vm_eval.c:210
/usr/lib/libruby.so.3.2(rb_funcallv+0x197) [0x7f75f3beca67] vm_eval.c:87
/usr/lib/libruby.so.3.2(vm_catch_protect+0xf7) [0x7f75f3bd6567] vm_eval.c:2393
/usr/lib/libruby.so.3.2(exec_recursive+0x1dd) [0x7f75f3b8ea4d] thread.c:5177
/usr/lib/libruby.so.3.2(obj_any_hash+0x118) [0x7f75f3a18c08] hash.c:202
/usr/lib/libruby.so.3.2(any_hash+0x2d) [0x7f75f3a1c285] hash.c:187
/usr/lib/libruby.so.3.2(rb_any_hash) hash.c:227
/usr/lib/libruby.so.3.2(get_allocated_entries+0x0) [0x7f75f3b50042] st.c:320
/usr/lib/libruby.so.3.2(rebuild_table_if_necessary) st.c:1075
/usr/lib/libruby.so.3.2(st_add_direct_with_hash) st.c:1136
/usr/lib/libruby.so.3.2(rb_st_add_direct) st.c:1157
/usr/lib/libruby.so.3.2(ar_try_convert_table+0x6f) [0x7f75f3a1b8bf] hash.c:788
/usr/lib/libruby.so.3.2(RHASH_ST_TABLE+0x0) [0x7f75f3a1fe6d] hash.c:1711
/usr/lib/libruby.so.3.2(rb_hash_stlike_update) hash.c:1718
/usr/lib/libruby.so.3.2(tbl_update) hash.c:1759
/usr/lib/libruby.so.3.2(rb_hash_aset+0xa7) [0x7f75f3a205f7] hash.c:2973
/usr/lib/libruby.so.3.2(vm_exec_core+0x3aaa) [0x7f75f3bdd78a] vm_insnhelper.c:5780
/usr/lib/libruby.so.3.2(rb_vm_exec+0xcb) [0x7f75f3bdfefb] vm.c:2374
/usr/lib/libruby.so.3.2(rb_vm_invoke_proc+0x4c) [0x7f75f3be8eac] vm.c:1603
/usr/lib/libruby.so.3.2(thread_do_start_proc+0x1a1) [0x7f75f3b92a41] thread.c:595
/usr/lib/libruby.so.3.2(thread_do_start+0x14) [0x7f75f3b9313c] thread.c:614
/usr/lib/libruby.so.3.2(thread_start_func_2) thread.c:689
/usr/lib/libruby.so.3.2(thread_start_func_1+0x100) [0x7f75f3b93c50] thread_pthread.c:1170
/lib/x86_64-linux-gnu/libpthread.so.0(start_thread+0xd9) [0x7f75f3349609]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f75f326e353]
```
----------------------------------------
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-107515
* Author: martinemde (Martin Emde)
* Status: Closed
* ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin20]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: REQUIRED, 3.3: DONTNEED
----------------------------------------
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/
8 Apr
8 Apr
10:42 a.m.
New subject: [ruby-core:117465] [Ruby master Bug#20050] Segfault on Ruby 3.2.2 (and 3.1) on x86_64 Darwin 20 (rb_id_table_lookup for #hash)
Issue #20050 has been updated by nagachika (Tomoyuki Chikanaga).
Backport changed from 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: REQUIRED, 3.3: DONTNEED to 3.0:
UNKNOWN, 3.1: UNKNOWN, 3.2: DONE, 3.3: DONTNEED
Merged https://github.com/ruby/ruby/pull/10394.
@kjtsanaktsidis Thank you for the pull request.
----------------------------------------
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-107854
* Author: martinemde (Martin Emde)
* Status: Closed
* ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin20]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: DONE, 3.3: DONTNEED
----------------------------------------
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/
31
days inactive
154
days old
10 comments
6 participants
participants (6)
-
Eregon (Benoit Daloze) -
kjtsanaktsidis (KJ Tsanaktsidis)
-
ko1 (Koichi Sasada)
-
mame (Yusuke Endoh)
-
martinemde (Martin Emde)
-
nagachika (Tomoyuki Chikanaga)