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

[ruby-core:122229] [Ruby Bug#21360] Inconsistent Support for `Exception#cause` in `Fiber#raise` and `Thread#raise`
by ioquatix (Samuel Williams) 22 Jul '25

22 Jul '25

Issue #21360 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21360: Inconsistent Support for `Exception#cause` in `Fiber#raise` and `Thread#raise` https://bugs.ruby-lang.org/issues/21360 * Author: ioquatix (Samuel Williams) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The `raise` method supports setting the cause of an exception using the `cause:` keyword, but this behavior does not work as expected when calling `Fiber#raise` or `Thread#raise`, resulting in a `TypeError`. This breaks consistency with `Kernel#raise` and makes it difficult to attach causal chains to exceptions raised from other execution contexts. ## The Problem The following code behaves correctly when using `Kernel#raise`, correctly setting the `cause`: ```ruby cause = RuntimeError.new("cause") begin raise RuntimeError, "boom", cause: cause rescue => error pp error: error, cause: error.cause end ``` Produces: ```ruby {error: #<RuntimeError: boom>, cause: #<RuntimeError: cause>} ``` However, using `Fiber.current.raise` or `Thread.current.raise` with the same arguments produces a `TypeError`: ```ruby begin Fiber.current.raise RuntimeError, "boom", cause: cause rescue => error pp error: error, cause: error.cause end ``` Results in: ```ruby {error: #<TypeError: backtrace must be an Array of String or an Array of Thread::Backtrace::Location>, cause: nil} ``` This occurs because the third argument is incorrectly interpreted as a backtrace, not as keyword arguments. A similar issue occurs with `Thread#raise`. ## Proposed Solution Update `Fiber#raise` and `Thread#raise` to accept and correctly interpret keyword arguments, including `cause:`, in the same manner as `Kernel#raise`. This would restore consistency across all `raise` implementations and allow causal exception chaining regardless of context. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:121060] [Ruby master Feature#21140] Add a method to get the address of certain JIT related functions
by tenderlovemaking (Aaron Patterson) 22 Jul '25

22 Jul '25

Issue #21140 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #21140: Add a method to get the address of certain JIT related functions https://bugs.ruby-lang.org/issues/21140 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- Feature #21116 extracted RJIT as a gem. But RJIT accesses certain internal functions which it cannot access as a gem. For example it used the `rb_str_bytesize` function, but this symbol is not exported, so we cannot access it (even from a C extension). Instead of exporting these symbols, I would like to propose an API for getting access to their addresses in Ruby. For example ```ruby RubyVM::RJIT.address_of(:rb_str_bytesize) # => 123456 ``` I would like to limit the addresses to [this list](https://github.com/ruby/ruby/blob/f32d5071b7b01f258eb45cf533496d82d5c… which are the ones required by RJIT. -- https://bugs.ruby-lang.org/

7 22

[ruby-core:121605] [Ruby Bug#21259] The Prism compiler wrongly creates a line number of zero
by mame (Yusuke Endoh) 21 Jul '25

21 Jul '25

Issue #21259 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #21259: The Prism compiler wrongly creates a line number of zero https://bugs.ruby-lang.org/issues/21259 * Author: mame (Yusuke Endoh) * Status: Assigned * Assignee: prism * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- test.rb ``` TracePoint.new(:line) do |tp| p tp end.enable load "./target.rb" ``` target.rb ``` if true..true end ``` ``` $ ~/work/ruby/local/bin/ruby --parser=prism test.rb #<TracePoint:line test.rb:5> #<TracePoint:line /tmp/reproduce-simplecov-ruby34-bug/target.rb:0> # <=== This lineno should be 1 $ ~/work/ruby/local/bin/ruby --parser=parse.y test.rb #<TracePoint:line test.rb:5> #<TracePoint:line /tmp/reproduce-simplecov-ruby34-bug/target.rb:1> ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:115422] [Ruby master Bug#20009] Marshal.load raises exception when load dumped class include non-ASCII
by ippachi (Kazuya Hatanaka) 19 Jul '25

19 Jul '25

Issue #20009 has been reported by ippachi (Kazuya Hatanaka). ---------------------------------------- Bug #20009: Marshal.load raises exception when load dumped class include non-ASCII https://bugs.ruby-lang.org/issues/20009 * Author: ippachi (Kazuya Hatanaka) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ## Reproduction code ```ruby class Cクラス; end Marshal.load(Marshal.dump(Cクラス)) ``` ## Actual result ``` <internal:marshal>:34:in `load': undefined class/module C\xE3\x82\xAF\xE3\x83\xA9\xE3\x82\xB9 (ArgumentError) from marshal.rb:2:in `<main>' ``` ## Expected result Returns `Cクラス` ## Impacted area An exception is raised in Rails under the following conditions * minitest is used with default settings * Parallel execution with parallelize * test class names contain non-ASCII characters The default parallelization uses DRb, and Marshal is used inside DRb. ## Other After trying various things, I thought I could fix it by making `rb_path_to_class` support strings containing non-ASCII characters, but I couldn't find anything more than that. -- https://bugs.ruby-lang.org/

7 13

[ruby-core:120579] [Ruby master Feature#21020] Sync sig directory for prism of default gem.
by ksss (Yuki Kurihara) 18 Jul '25

18 Jul '25

Issue #21020 has been reported by ksss (Yuki Kurihara). ---------------------------------------- Feature #21020: Sync sig directory for prism of default gem. https://bugs.ruby-lang.org/issues/21020 * Author: ksss (Yuki Kurihara) * Status: Open ---------------------------------------- Currently, the type signatures (RBS) for the default gem is not available. **Prism** is the only default gem with type signatures, but this number is expected to increase in the future. As a first step to resolving this issue, I propose including the `sig` directory of Prism as a default gem in the synchronization process. PR: https://github.com/ruby/ruby/pull/12541 -- https://bugs.ruby-lang.org/

5 5

[ruby-core:121592] [Ruby Bug#21256] `it` value is wrapped in an array when that doesn't happen with numbered parameter
by Earlopain (Earlopain _) 18 Jul '25

18 Jul '25

Issue #21256 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21256: `it` value is wrapped in an array when that doesn't happen with numbered parameter https://bugs.ruby-lang.org/issues/21256 * Author: Earlopain (Earlopain _) * 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 ---------------------------------------- I have the following script: ```rb require "bundler/inline" gemfile do source "https://rubygems.org" gem "rspec-core", "3.13.3" gem "rspec-expectations", "3.13.3" end require "rspec/autorun" require "rspec/expectations" RSpec::Matchers.define :example do chain(:foo) { pp _1 } chain(:bar) { pp it } end RSpec.describe "demo" do it do example.foo(1) example.bar(2) end end ``` It calls two methods were the only difference is that one accesses the argument with `_1`, the other with `it`. It prints the following: ``` 1 [2] ``` So, `it` for some reason wraps it in an array. I appologise for the reproduction script, it uses `rspec` and the amount of metaprogramming it uses makes it impossible for me to reduce this further. When running with `parser=parse.y`, the expected output is returned (just `2`, no array). I also tested against current ruby-dev and it also happens there. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:122345] [Ruby Feature#21386] Introduce `Enumerable#join_map`
by matheusrich (Matheus Richard) 16 Jul '25

16 Jul '25

Issue #21386 has been reported by matheusrich (Matheus Richard). ---------------------------------------- Feature #21386: Introduce `Enumerable#join_map` https://bugs.ruby-lang.org/issues/21386 * Author: matheusrich (Matheus Richard) * Status: Open ---------------------------------------- ### Problem The pattern `.map { ... }.join(sep)` is extremely common in Ruby codebases: ```ruby users.map(&:name).join(", ") ``` It’s expressive but repetitive (both logically and computationally). This pattern allocates an intermediate array and does two passes over the collection. Real-world usage is widespread: - [Open source Ruby projects using this pattern](https://github.com/search?q=lang%3Aruby+%2F%5C.map%5Cs*%5C%7B%5B%5… - [Within Rails](https://github.com/search?q=lang%3Aruby+%2F%5C.map%5Cs*%5C%7B%5B%5E%… - [Within Ruby itself](https://github.com/search?q=lang%3Aruby+%2F%5C.map%5Cs*%5C%7B%5B%5E… ### Proposal Just like `filter_map` exists to collapse a common `map + compact`, this proposal introduces `Enumerable#join_map`, which maps and joins in a single pass. ```ruby users.join_map(", ", &:name) ``` A Ruby implementation could look like this: ```ruby module Enumerable def join_map(sep = "") return "" unless block_given? str = +"" first = true each do |item| str << sep unless first str << yield(item).to_s first = false end str end end ``` The name `join_map` follows the precedent of `filter_map`, emphasizing the final operation (`join`) over the intermediate (`map`). ### Prior Art Some other languages have similar functionality, but with different names or implementations: #### Elixir Elixir has this via [the `Enum.map_join/3` function](https://hexdocs.pm/elixir/1.12/Enum.html#map_join/3): ```elixir Enum.map_join([1, 2, 3], &(&1 * 2)) "246" Enum.map_join([1, 2, 3], " = ", &(&1 * 2)) "2 = 4 = 6" ``` #### Crystal Crystal, on the other hand, [uses `Enumerable#join` with a block](https://crystal-lang.org/api/1.16.3/Enumerable.html#join%28separator…: ```crystal [1, 2, 3].join(", ") { |i| -i } # => "-1, -2, -3" ``` #### Kotlin Kotlin has a similar [function called `joinToString`](https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.collections/join-to-string.html) that can take a transformation function: ```kotlin val chars = charArrayOf('a', 'b', 'c') println(chars.joinToString() { it.uppercaseChar().toString() }) // A, B, C ``` -- https://bugs.ruby-lang.org/

9 11

[ruby-core:112664] [Ruby master Bug#19473] can't be called from trap context (ThreadError) is too limiting
by Eregon (Benoit Daloze) 15 Jul '25

15 Jul '25

Issue #19473 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19473: can't be called from trap context (ThreadError) is too limiting https://bugs.ruby-lang.org/issues/19473 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Simple reproducer: ``` $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] -e:1:in `synchronize': can't be called from trap context (ThreadError) from -e:1:in `block in <main>' from -e:1:in `kill' from -e:1:in `<main>' ``` Expected behavior: ``` $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' truffleruby 22.3.1, like ruby 3.0.3, GraalVM CE Native [x86_64-linux] :OK $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' jruby 9.4.0.0 (3.1.0) 2022-11-23 95c0ec159f OpenJDK 64-Bit Server VM 17.0.6+10 on 17.0.6+10 +jit [x86_64-linux] :OK ``` This exception is highly problematic, for instance it breaks `Timeout.timeout` in `trap`: https://github.com/ruby/timeout/issues/17#issuecomment-1142035939 I suppose this behavior is because *sometimes* it's problematic to lock a Mutex in trap, e.g., if it's already locked by the main thread/fiber. However, that's just one case, not all, so we should not raise an exception early like that. There seems to be no valid reason to prevent *all* `Mutex#synchronize` in `trap`. After all, if the Mutex for instance is only used in `trap`, it's well-defined AFAIK. For instance a given trap handler does not seem executed concurrently: ``` $ ruby -ve 'trap(:HUP) { puts "in trap\n"+caller.join("\n")+"\n\n"; sleep 0.1 }; pid = Process.pid; Process.wait fork { 20.times { Process.kill :HUP, pid } }; sleep 1' ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' ``` And if the trap handler using the Mutex is never called while the Mutex is held by the main thread/fiber, there is also no problem. -- https://bugs.ruby-lang.org/

8 27

[ruby-core:122327] [Ruby Bug#21380] Use-After-Free in String#split with In-Block String Modification
by bytesmith (Orin Nova) 14 Jul '25

14 Jul '25

Issue #21380 has been reported by bytesmith (Orin Nova). ---------------------------------------- Bug #21380: Use-After-Free in String#split with In-Block String Modification https://bugs.ruby-lang.org/issues/21380 * Author: bytesmith (Orin Nova) * Status: Open * ruby -v: 3.5.0 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- A use-after-free bug can be triggered in Ruby's String#split when the target string is modified within the block passed to split. Ruby version: ``` ./ruby -v ruby 3.5.0dev (2025-05-28T04:34:40Z master d064fd067b) +PRISM [x86_64-linux] ``` Program input: ``` str = "one two" def mutate(s) s.prepend("junk" * 1000) end counter = 0 loop do str.split { mutate(str) } counter += 1 break if counter > 10 end ``` ASAN output: ``` ================================================================= ==30097==ERROR: AddressSanitizer: heap-use-after-free on address 0x526000002fe4 at pc 0x562c9f1bad20 bp 0x7ffc937b5440 sp 0x7ffc937b5430 READ of size 1 at 0x526000002fe4 thread T0 #0 0x562c9f1bad1f in rb_str_split_m ../string.c:9765 #1 0x562c9f2eb9c5 in vm_call_cfunc_with_frame_ ../vm_insnhelper.c:3774 #2 0x562c9f3056f6 in vm_sendish ../vm_insnhelper.c:5971 #3 0x562c9f3543b7 in vm_exec_core ../insns.def:851 #4 0x562c9f32315e in rb_vm_exec ../vm.c:2625 #5 0x562c9f367157 in rb_iseq_eval_main ../vm.c:2905 #6 0x562c9ee6078a in rb_ec_exec_node ../eval.c:281 #7 0x562c9ee67e4d in ruby_run_node ../eval.c:319 #8 0x562c9ee575c1 in rb_main ../main.c:42 #9 0x562c9ee575c1 in main ../main.c:62 #10 0x7f7ecc8811c9 (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 42c84c92e6f98126b3e2230ebfdead22c235b667) #11 0x7f7ecc88128a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 42c84c92e6f98126b3e2230ebfdead22c235b667) ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122215] [Ruby Bug#21356] Error when accessing local variable named "default" with Binding#local_variable_get
by richardboehme 14 Jul '25

14 Jul '25

Issue #21356 has been reported by richardboehme (Richard Böhme). ---------------------------------------- Bug #21356: Error when accessing local variable named "default" with Binding#local_variable_get https://bugs.ruby-lang.org/issues/21356 * Author: richardboehme (Richard Böhme) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-21T06:12:18Z master f6cbf499bc) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- On Ruby master when using `Binding#local_variable_get` with the name `:default` it raises the following error: ``` 'Binding#local_variable_get': numbered parameter 'default' is not a local variable (NameError) ``` I saw that this error was introduced in #21049 but it seems like the check for whether the passed variable name is a numbered parameter does not work for the `:default` symbol. I think this might be an off-by-one error in the `rb_numparam_id_p` function in proc.c, where instead of adding 9 (the maximum number of numbered parameters) to tNUMPARAM_1 we currently add 10 which then includes the id of default as well? Compiling with this change (see attached diff) fixed the issue but I'm not sure if it might break other things. ---Files-------------------------------- patch.diff (384 Bytes) -- https://bugs.ruby-lang.org/

4 4