[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)
From:
"kjtsanaktsidis (KJ Tsanaktsidis) via ruby-core" <ruby-core@...>
Date:
2024-03-28 05:01:27 UTC
List:
ruby-core #117356
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/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/