From: "martinemde (Martin Emde) via ruby-core" <ruby-core@...>
Date: 2023-12-16T05:50:30+00:00
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/19357067789?pr=7129

2. https://github.com/rubygems/rubygems/actions/runs/7131889001/job/19421304163?pr=7228



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/

 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/