April 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:121659] [Ruby Bug#21267] respond_to check in Class#allocate is inconsistent
by jhawthorn (John Hawthorn) 26 May '25

26 May '25

Issue #21267 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #21267: respond_to check in Class#allocate is inconsistent https://bugs.ruby-lang.org/issues/21267 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `Class#allocate` has an additional `rb_obj_respond_to(klass, rb_intern("allocate"))` check to forbid allocate being called on a class where it has been made private or undefined, even if used via ex. `bind_call`. ``` >> Rational.allocate (irb):1:in '<main>': undefined method 'allocate' for class Rational (NoMethodError) >> Class.instance_method(:allocate).bind_call(Rational) (irb):1:in 'Class#allocate': calling Rational.allocate is prohibited (TypeError) ``` However I don't think this provides any additional protection from users accessing an uninitialized object, as the user can redefine allocate to anything to bypass the check: ``` >> Class.instance_method(:allocate).bind_call(Class.new(Rational) {def self.allocate; end}) => (0/1) ``` Or even override `respond_to_missing?` ``` >> Class.instance_method(:allocate).bind_call(Class.new(Rational) {def self.respond_to_missing? *; true; end}) => (0/1) ``` So I think we should remove this check. For classes that we need to forbid allocation we should use `rb_undef_alloc_func`. The classes I see this used for are: * MatchData * Refinement * Module * Complex * Rational My main motivation is that this check makes `Class#allocate` slow. There are ways we could improve that, but I don't think the check as-is is useful. If there's an alternative, more robust, check we'd like to do instead of simply removing this I'd be happy to implement it. This makes `allocate` ~75% faster. ``` |allocate_no_params | 19.009M| 20.087M| | | -| 1.06x| |allocate_allocate | 20.587M| 35.882M| | | -| 1.74x| ``` https://github.com/ruby/ruby/pull/13116 -- https://bugs.ruby-lang.org/

2 5

[ruby-core:121215] [Ruby master Bug#21166] Fiber Scheduler is unable to be interrupted by `IO#close`.
by ioquatix (Samuel Williams) 23 May '25

23 May '25

Issue #21166 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21166: Fiber Scheduler is unable to be interrupted by `IO#close`. https://bugs.ruby-lang.org/issues/21166 * Author: ioquatix (Samuel Williams) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ## Background Ruby's `IO#close` can cause `IO#read`, `IO#write`, `IO#wait`, `IO#wait_readable` and `IO#wait_writable` to be interrupted with an IOError (stream closed in another thread). For reference, `IO#select` cannot be interrupted in this way. ```ruby r, w = IO.pipe thread = Thread.new do r.read(1) end Thread.pass until thread.status == "sleep" r.close thread.join # ./test.rb:6:in 'IO#read': stream closed in another thread (IOError) ``` ## Problem The fiber scheduler provides hooks for `io_read`, `io_write` and `io_wait` which are used by `IO#read`, `IO#write`, `IO#wait`, `IO#wait_readable` and `IO#wait_writable`, but those hooks are not interrupted when `IO#close` is invoked. That is because `rb_notify_fd_close` is not scheduler aware, and the fiber scheduler is unable to register itself into the "waiting file descriptor" list. ```ruby #!/usr/bin/env ruby require 'async' r, w = IO.pipe thread = Thread.new do Async do r.wait_readable end end Thread.pass until thread.status == "sleep" r.close thread.join ``` In this test program, `rb_notify_fd_close` will incorrectly terminate the entire fiber scheduler thread: ``` #<Thread:0x00007faa5b161bf8 /home/samuel/Developer/socketry/io-event/test.rb:7 run> terminated with exception (report_on_exception is true): /home/samuel/Developer/socketry/io-event/lib/io/event/selector/select.rb:470:in 'IO.select': closed stream (IOError) from /home/samuel/Developer/socketry/io-event/lib/io/event/selector/select.rb:470:in 'block in IO::Event::Selector::Select#select' from /home/samuel/Developer/socketry/io-event/lib/io/event/selector/select.rb:468:in 'Thread.handle_interrupt' from /home/samuel/Developer/socketry/io-event/lib/io/event/selector/select.rb:468:in 'IO::Event::Selector::Select#select' from /home/samuel/.gem/ruby/3.4.1/gems/async-2.23.0/lib/async/scheduler.rb:396:in 'Async::Scheduler#run_once!' ... ``` ## Solution This PR introduces some new functions: - `VALUE rb_io_interruptible_operation(VALUE self, VALUE(*function)(VALUE), VALUE argument)` for wrapping user IO operations so they can be interrupted. - `IO#interruptable_operation(&block)` the same as above. - `VALUE rb_fiber_scheduler_fiber_interrupt(VALUE scheduler, VALUE fiber, VALUE exception)` for interrupting a specific fiber on the fiber scheduler. `rb_notify_fd_close` is modified so that it is fiber scheduler aware and uses `rb_fiber_scheduler_fiber_interrupt` to interrupt a fiber. In addition, we also change the internal `struct waiting_fd` to track the `rb_execution_context_t` rather than just the `rb_thread_t` instance, so that we can correctly wake up either the waiting thread or fiber. The public interface `rb_io_interruptible_operation` and `IO#interruptible_operation` are introduced so that the scheduler implementation can wrap IO operations that should be interruptible, e.g. ```ruby Fiber.schedule do io.interruptible_operation do io.wait_readable end end # Will interrupt above fiber: io.close ``` See <https://github.com/ruby/ruby/pull/12585> for the proposed implementation. -- https://bugs.ruby-lang.org/

3 12

[ruby-core:121222] [Ruby master Bug#21167] Visual Studio 2022 17.13.x couldn't build ruby.exe
by hsbt (Hiroshi SHIBATA) 23 May '25

23 May '25

Issue #21167 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21167: Visual Studio 2022 17.13.x couldn't build ruby.exe https://bugs.ruby-lang.org/issues/21167 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `miniruby.exe` built by Visual Studio 2022 17.13.0-2 is not working with our build process. ``` user32.lib advapi32.lib shell32.lib ws2_32.lib iphlpapi.lib gmp.lib imagehlp.lib shlwapi.lib bcrypt.lib linking miniruby.exe Creating library miniruby.lib and object miniruby.exp [BUG] heap_idx_for_size: allocation size too large (size=56u, heap_idx=891288545u) ruby 3.5.0dev (2025-03-03T02:17:14Z master a47e686cb6) [x64-mswin64_140] -- Control frame information ----------------------------------------------- c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 0 Ruby thread count for this ractor: 0 -- C level backtrace information ------------------------------------------- C:\WINDOWS\SYSTEM32\ntdll.dll(ZwWaitForSingleObject+0x14) [0x00007FF9057BF854] C:\WINDOWS\System32\KERNELBASE.dll(WaitForSingleObjectEx+0xaf) [0x00007FF902CFCE1F] C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(rb_print_backtrace+0x3e) [0x00007FF63DC37E7E] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\vm_dump.c:859 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(rb_vm_bugreport+0x1ba) [0x00007FF63DC3803E] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\vm_dump.c:1170 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(rb_bug_without_die_internal+0x72) [0x00007FF63DB0255A] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\error.c:1097 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(rb_bug+0x20) [0x00007FF63DB02448] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\error.c:1117 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(newobj_of+0x1e7) [0x00007FF63DB186FB] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\gc.c:1007 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(typed_data_alloc+0xc3) [0x00007FF63DB212CF] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\gc.c:1084 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(rb_data_typed_object_zalloc+0x3b) [0x00007FF63DB19797] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\gc.c:1107 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(pin_array_list_new+0x25) [0x00007FF63DC1B5D9] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\vm.c:4387 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(Init_vm_objects+0x17) [0x00007FF63DC1665B] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\vm.c:4446 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(ruby_setup+0x3f) [0x00007FF63DB08C1B] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\eval.c:83 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(ruby_init+0x9) [0x00007FF63DB089AD] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\eval.c:98 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(wmain+0x3a) [0x00007FF63DA8103A] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\main.c:51 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(__scrt_common_main_seh+0x10c) [0x00007FF63DC9DE88] D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288 C:\WINDOWS\System32\KERNEL32.DLL(BaseThreadInitThunk+0x17) [0x00007FF90409E8D7] -- Other runtime information ----------------------------------------------- NMAKE : fatal error U1077: '@ miniruby.exe -v' : return code '0x3' Stop. ``` I disabled that version on our CI temporary. * https://github.com/ruby/ruby/pull/12830 * https://github.com/ruby/actions/pull/81 -- https://bugs.ruby-lang.org/

2 7

[ruby-core:115995] [Ruby master Bug#20112] Ractors not working properly in ruby 3.3.0
by ariasdiniz (Aria Diniz) 19 May '25

19 May '25

Issue #20112 has been reported by ariasdiniz (Aria Diniz). ---------------------------------------- Bug #20112: Ractors not working properly in ruby 3.3.0 https://bugs.ruby-lang.org/issues/20112 * Author: ariasdiniz (Aria Diniz) * Status: Open * Priority: Normal * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I recently installed Ruby 3.3.0, and noticed that some of my scripts that use Ractors started to struggle with performance. After doing some benchmarks, I noticed that, while Ractors seem to be working well on Ruby 3.2.2, they're not working properly on 3.3.0. I'm using Ubuntu 22.04.3 LTS Here is the benchmark code: ``` ruby # frozen_string_literal: true require 'benchmark' Ractor.new { :warmup } if defined?(Ractor) Benchmark.bmbm do |x| x.report("Thread: ") do threads = [] 8.times do |i| threads << Thread.new do 20000000.times do |j| ((i * 20000000) + j)**2 end end end threads.each(&:join) end x.report("Ractor: ") do ractors = [] 0..8.times do |i| ractors << Ractor.new(i) do |k| 20000000.times do |j| ((k * 20000000) + j)**2 end end end ractors.map(&:take) end end ``` Here is the results for Ruby 3.2.2: Rehearsal -------------------------------------------- Thread: 7.666909 0.001091 7.668000 ( 7.675266) Ractor: 19.318528 0.012017 19.330545 ( 2.505888) ---------------------------------- total: 26.998545sec user system total real Thread: 7.918141 0.004011 7.922152 ( 7.928772) Ractor: 19.366414 0.003954 19.370368 ( 2.517993) Here is the results for Ruby 3.3.0: Rehearsal -------------------------------------------- Thread: 8.634152 0.010895 8.645047 ( 8.645104) Ractor: 100.172179 0.035985 100.208164 ( 15.213245) --------------------------------- total: 108.853211sec user system total real Thread: 9.451236 0.004002 9.455238 ( 9.460132) Ractor: 118.463294 0.119942 118.583236 ( 18.462157) -- https://bugs.ruby-lang.org/

5 4

[ruby-core:121597] [Ruby Bug#21257] YJIT can generate infinite loop when OOM
by rianmcguire (Rian McGuire) 18 May '25

18 May '25

Issue #21257 has been reported by rianmcguire (Rian McGuire). ---------------------------------------- Bug #21257: YJIT can generate infinite loop when OOM https://bugs.ruby-lang.org/issues/21257 * Author: rianmcguire (Rian McGuire) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- We've found an edge case where YJIT can generate an infinite loop (jump to the same address) when it's out-of-memory. Reproduction: ```ruby def first second end def second ::File end # Make `second` side exit on its first instruction trace = TracePoint.new(:line) { } trace.enable(target: method(:second)) 32.times do |i| puts i first if i == 29 # We've JITed the methods now - trigger the bug # Trigger a constant cache miss in rb_vm_opt_getconstant_path (in `second`) next time it's called module InvalidateConstantCache File = nil end # nb. this only works in yjit dev mode RubyVM::YJIT.simulate_oom! end end ``` This hangs indefinitely when run with YJIT (`./configure --enable-yjit=dev` is required for simulate_oom). If we attach a debugger to the Ruby process at this point, it's stuck in an infinite loop: ``` $ lldb -p 9753 (lldb) process attach --pid 9753 Process 9753 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x0000000104b202b8 -> 0x104b202b8: b 0x104b202b8 0x104b202bc: nop 0x104b202c0: nop 0x104b202c4: nop Target 0: (ruby) stopped. Executable module set to "/Users/rian/opt/ruby/bin/ruby". Architecture set to: arm64-apple-macosx-. ``` We've reproduced this on: ``` ruby 3.3.6 (2024-11-05 revision 75015d4c1f) [x86_64-linux] ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin23] ruby 3.5.0dev (2025-04-08T06:46:45Z master b68fe530f1) +PRISM [arm64-darwin23] ``` -- https://bugs.ruby-lang.org/

4 5

[ruby-core:121782] [Ruby Bug#21297] Update net-imap for ruby 3.2, 3.3, 3.4
by nevans (Nicholas Evans) 18 May '25

18 May '25

Issue #21297 has been reported by nevans (Nicholas Evans). ---------------------------------------- Bug #21297: Update net-imap for ruby 3.2, 3.3, 3.4 https://bugs.ruby-lang.org/issues/21297 * Author: nevans (Nicholas Evans) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The bundled `net-imap` versions are vulnerable to CVE-2025-43857 (GHSA-j3g3-5qv5-52mj). This vulnerability does not affect securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname). Fixing the issue requires upgrading to [v0.2.5], [v0.3.9], [v0.4.20], or [v0.5.7]. * ruby 3.2.8 bundles net-imap v0.3.8 PR: Bump net-imap to 0.3.9 for Ruby 3.2 https://github.com/ruby/ruby/pull/13213 * ruby 3.3.8 bundles net-imap v0.4.19 PR: Bump net-imap to 0.4.21 for Ruby 3.3 https://github.com/ruby/ruby/pull/13214 * ruby 3.4.3 bundles net-imap v0.5.6 PR: Bump net-imap to v0.5.8 for Ruby 3.4 https://github.com/ruby/ruby/pull/13215 I didn't have a release ready in time to be bundled with the final version of ruby 3.1, so I haven't created a PR for [v0.2.5]. The workaround is to uninstall the vulnerable bundled versions and `gem install net-imap`. Security Advisory Links: * https://www.cve.org/CVERecord?id=CVE-2025-43857 * https://github.com/ruby/net-imap/security/advisories/GHSA-j3g3-5qv5-52mj [v0.2.5]: https://github.com/ruby/net-imap/releases/tag/v0.2.5 [v0.3.9]: https://github.com/ruby/net-imap/releases/tag/v0.3.9 [v0.4.20]: https://github.com/ruby/net-imap/releases/tag/v0.4.20 [v0.5.7]: https://github.com/ruby/net-imap/releases/tag/v0.5.7 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:121556] [Ruby Bug#21220] Memory corruption in update_line_coverage() [write at index -1]
by mbcodeandsound (Mike Bourgeous) 17 May '25

17 May '25

Issue #21220 has been reported by mbcodeandsound (Mike Bourgeous). ---------------------------------------- Bug #21220: Memory corruption in update_line_coverage() [write at index -1] https://bugs.ruby-lang.org/issues/21220 * Author: mbcodeandsound (Mike Bourgeous) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hello! I have encountered repeatable memory corruption in Ruby 3.4.2 on Ubuntu 24.04.2 LTS, which I believe is happening in update_line_coverage(). I could not reproduce this on Ruby 3.x or earlier. My findings follow. I also have detailed step-by-step notes at https://github.com/mike-bourgeous/mb-sound/issues/36 ### Summary `update_line_coverage()` calls `rb_sourceline()`, subtracts one from its return value, and uses this as an index into an Array. Sometimes `rb_sourceline()` returns 0, and when this happens, `update_line_coverage()` will write to index -1 of the array. This corrupts the heap before the Array, resulting in a program crash later during GC. As I am new to the Ruby codebase I do not know if it's normal for rb_sourceline() to return 0 and update_line_coverage() should handle it, or if something is wrong in the code that ultimately feeds rb_sourceline(). ### Symptom On Linux, affected processes print one of the following errors and exit: ``` munmap_chunk(): invalid pointer Aborted (core dumped) ``` or, if preloading libc_malloc_debug.so ``` malloc_check_get_size: memory corruption Aborted (core dumped) ``` ### Reproduction I have a reduced GitHub project that can reproduce the bug consistently both on my machine and in CI. When I try to reduce the size of this repo further, the bug stops happening. The issue only reproduces locally if the `coverage/` directory has a large `.resultset.json`. - **Repo:** https://github.com/mike-bourgeous/reproduce-simplecov-ruby34-bug - **Example of the bug:** https://github.com/mike-bourgeous/reproduce-simplecov-ruby34-bug/actions/ru… ``` shell # Repeatedly running the process increases the likelihood of crashing # as the SimpleCov result file grows. for f in `seq 1 100`; do echo $f; ruby -r./spec/simplecov_helper.rb bin/midi_roll.rb -c 40 -r 2 spec/test_data/all_notes.mid > /dev/null || break ; done ``` ### Research and reasoning I initially found the crash during a live stream when I was upgrading a project from Ruby 2.7 to Ruby 3.4. The crash occurred when an RSpec test tried to spawn another Ruby process, while using SimpleCov to measure code coverage in both. I discovered a workaround of disabling SimpleCov in the nested process when running tests on Ruby 3.4. I used a somewhat unusual approach to get coverage metrics for subprocesses. After the stream I wanted to understand what was really happening and see if I could find a way to re-enable test code coverage for subprocesses. I used a combination of Valgrind, GDB, and trial and error to narrow down the site of the crash and the original corruption. I wrote [a GDB script to automate information gathering](https://github.com/mike-bourgeous/reproduce-simplecov-ruby34-bug… when the GC crash occurred, and Valgrind+vgdb to identify the original write that appeared to cause the corruption. I reviewed the Git history of update_line_coverage(), rb_sourceline() (and the functions it calls), and a few other functions, but did not find any obvious changes between Ruby 3.3.x and Ruby 3.4.x, so the root cause is somewhere beyond my familiarity with the codebase. Full details of my process are in my issue notes: https://github.com/mike-bourgeous/mb-sound/issues/36 ---Files-------------------------------- corruption_c_stack.txt (2.63 KB) corruption_ruby_stack.txt (948 Bytes) crash_ruby_stack.txt (4.46 KB) crash_c_stack.txt (26.2 KB) -- https://bugs.ruby-lang.org/

5 15

[ruby-core:120671] [Ruby master Bug#21037] Ractors hang with multiple threads
by tenderlovemaking (Aaron Patterson) 14 May '25

14 May '25

Issue #21037 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21037: Ractors hang with multiple threads https://bugs.ruby-lang.org/issues/21037 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-14T20:59:39Z master f1e32914eb) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following program hangs, but I don't expect it to hang: ```ruby # frozen_string_literal: true class Map def initialize @r = Ractor.new { cache = { "int" => "integer", "bool" => "boolean" } loop do key = receive Ractor.yield key end } freeze end def fetch(key) @r.send key m = @r.take raise unless key == m m end end tm = Map.new t1 = Thread.new { 10.times { |i| p [i + 1,tm.fetch("int")] } } t2 = Thread.new { 10.times { |i| p [i + 1, tm.fetch("bool")] } } t1.join t2.join ``` I'm not sure why this program hangs yet, but it does both on macOS and Linux. I've tested with master, Ruby 3.4, and Ruby 3.3. I'm not sure why it's hanging yet, but I wanted to file an issue. -- https://bugs.ruby-lang.org/

2 5

[ruby-core:119137] [Ruby master Bug#20726] Issue with hash without braces when assigned to constant with ractor literals
by luke-gru (Luke Gruber) 14 May '25

14 May '25

Issue #20726 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #20726: Issue with hash without braces when assigned to constant with ractor literals https://bugs.ruby-lang.org/issues/20726 * Author: luke-gru (Luke Gruber) * Status: Open * ruby -v: 3.4.0dev * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby a = 'hi' A = ['hello' => a] p A ``` gives: ``` ./ruby -I../ruby/lib -I. -I.ext/x86_64-linux -I.ext/common -r./x86_64-linux-fake ../ruby/test.rb -- raw disasm-------- trace: 1 0000 putchilledstring "hi" ( 3) 0002 setlocal_WC_0 3 ( 3) trace: 1 0004 newarray 1 ( 4) 0006 putspecialobject 3 ( 4) * 0008 setconstant :A ( 4) trace: 1 0010 putself ( 5) 0011 opt_getconstant_path [:A] ( 5) 0013 opt_send_without_block <calldata:p, 1> ( 5) 0015 leave ( 5) --------------------- ../ruby/test.rb:4: argument stack underflow (-1) ../ruby/test.rb: compile error (SyntaxError) ``` This is due to a line in `compile.c`, function `compile_shareable_literal_constant`: ```c if (!RNODE_HASH(node)->nd_brace) { } ``` I'm not sure why this condition is there so I'm not confident in making a fix. Also, my git-fu isn't the best so I can't track down the right commit where it was added. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:121754] [Ruby Bug#21289] Fix C level backtraces for USE_ELF
by dodecadaniel (Daniel Colson) 14 May '25

14 May '25

Issue #21289 has been reported by dodecadaniel (Daniel Colson). ---------------------------------------- Bug #21289: Fix C level backtraces for USE_ELF https://bugs.ruby-lang.org/issues/21289 * Author: dodecadaniel (Daniel Colson) * Status: Open * ruby -v: ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- After upgrading GitHub to Ruby 3.4 we noticed that we stopped getting useful C level backtrace information in our crash reports. We traced it back to https://github.com/github/ruby/commit/7dd2afbe3a14d021e5554288517709f5778c3…. Passing 0 instead of -1 makes sense for the Mach-O version of `fill_lines`, but there is a separate ELF version of `fill_lines` that still has special handling for -1: https://github.com/ruby/ruby/blob/58e3aa02240a9ec1b5fe6ce60d63828c2cf0c73a/…. More details in the corresponding PR: https://github.com/ruby/ruby/pull/13195 -- https://bugs.ruby-lang.org/

2 1