- ruby-core - ml.ruby-lang.org

[ruby-core:121458] [Ruby Bug#21202] Ripper wrongly concats separate tstring_content within nested unterminated heredoc
by tompng (tomoya ishida) 27 Mar '25

27 Mar '25

Issue #21202 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21202: Ripper wrongly concats separate tstring_content within nested unterminated heredoc https://bugs.ruby-lang.org/issues/21202 * Author: tompng (tomoya ishida) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ~~~ruby code = <<~'CODE' <<H1 #{<<H2}a H2 b CODE Ripper.tokenize(code) #=> ["<<H1", "\n", "\#{", "<<H2", "}", "a\nb\n", "H2\n"] ~~~ `"a\nb\n"` should be a separate token `"a\n"` and `"b\n"` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:120979] [Ruby master Feature#21133] [ruby/logger] Add an option to disable writing the header when creating a new log file
by viralpraxis (Iaroslav Kurbatov) 27 Mar '25

27 Mar '25

Issue #21133 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Feature #21133: [ruby/logger] Add an option to disable writing the header when creating a new log file https://bugs.ruby-lang.org/issues/21133 * Author: viralpraxis (Iaroslav Kurbatov) * Status: Open ---------------------------------------- Creating a logger automatically writes a hardcoded header comment ("# Logfile created on ..."): https://github.com/ruby/logger/blob/0eb10f2d278435899ce9055c98eb5b53caa0092… As far as I can see, it helps to verify that logdev is writable as early as possible (rather than on the first log entry) and it also serves as a useful indicator of which program created the logfile. However, this header can introduce unnecessary complexity is some use-cases -- especially when working with third-party tools that need to ignore these lines. I think it might make sense to add a new configuration option (`skip_header`) which will be `false` by default so the changes are backward-compatible. Proposed implementation: https://github.com/ruby/logger/pull/119 -- https://bugs.ruby-lang.org/

1 1

[ruby-core:121450] [Ruby Bug#21200] Ractor spuriously hangs, segfault or errors
by Eregon (Benoit Daloze) 27 Mar '25

27 Mar '25

Issue #21200 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21200: Ractor spuriously hangs, segfault or errors https://bugs.ruby-lang.org/issues/21200 * Author: Eregon (Benoit Daloze) * Status: Open * Assignee: ractor * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- For a new test `test_ractor_parallel` I added in https://github.com/ruby/etc/pull/52/files This seems a Ractor bug. Example failures: https://github.com/ruby/ruby/actions/runs/14097239052/job/39486770259?pr=12… ``` 1) Failure: TestEtc#test_ractor_parallel [/Users/runner/work/ruby/ruby/src/test/etc/test_etc.rb:178]: assert_separately failed with error message pid 51588 exit 0 | [BUG] ``` https://github.com/ruby/ruby/actions/runs/14094646363/job/39479353266?pr=12… ``` TestEtc#test_ractor_parallel [/Users/runner/work/ruby/ruby/src/test/etc/test_etc.rb:178]: assert_separately failed with error message pid 47346 exit 0 | [BUG] pthread_mutex_lock: Invalid argument (EINVAL) | ruby 3.5.0dev (2025-03-26T22:25:25Z pull/12984/merge 1ea32181b7) +PRISM [arm64-darwin23] | | -- Crash Report log information -------------------------------------------- | See Crash Report log file in one of the following locations: | * ~/Library/Logs/DiagnosticReports | * /Library/Logs/DiagnosticReports | for more details. | Don't forget to include the above Crash Report log file in bug reports. | | -- Control frame information ----------------------------------------------- | | | -- Threading information --------------------------------------------------- | Total ractor count: 1 | Ruby thread count for this ractor: 0 | | -- C level backtrace information ------------------------------------------- | [BUG] Segmentation fault at 0xfffffffffffffff8 | ruby 3.5.0dev (2025-03-26T22:25:25Z pull/12984/merge 1ea32181b7) +PRISM [arm64-darwin23] | | -- Crash Report log information -------------------------------------------- | See Crash Report log file in one of the following locations: | * ~/Library/Logs/DiagnosticReports | * /Library/Logs/DiagnosticReports | for more details. | Don't forget to include the above Crash Report log file in bug reports. | | Crashed while printing bug report | [IMPORTANT] | Don't forget to include the Crash Report log file under | DiagnosticReports directory in bug reports. | ``` https://github.com/ruby/ruby/actions/runs/14069270994/job/39402894235#step:… ``` 1) Error: TestEtc#test_ractor_parallel: Test::Unit::ProxyError: execution of Test::Unit::CoreAssertions#assert_separately expired timeout (10 sec) pid 145797 killed by SIGKILL (signal 9) | /home/runner/work/ruby/ruby/src/test/etc/test_etc.rb:178:in 'TestEtc#test_ractor_parallel' ``` The test has been disabled for now in https://github.com/ruby/ruby/pull/12992. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114147] [Ruby master Bug#19765] Ractor.make_shareable ignores self of a proc created from a Method
by Ethan (Ethan -) 27 Mar '25

27 Mar '25

Issue #19765 has been reported by Ethan (Ethan -). ---------------------------------------- Bug #19765: Ractor.make_shareable ignores self of a proc created from a Method https://bugs.ruby-lang.org/issues/19765 * Author: Ethan (Ethan -) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-07-12T00:26:03Z master dfe782be17) [x86_64-darwin21] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- An unshareable receiver of a Proc or a Method will cause make_shareable to error, but this does not happen with a proc from Method#to_proc: ```ruby str = "" a = str.instance_exec { proc { to_s } } Ractor.make_shareable a # => <internal:ractor>:820:in `make_shareable': Proc's self is not shareable: #<Proc:0x00000001064b62c8 (irb):1> (Ractor::IsolationError) b = str.instance_exec { method(:to_s) } Ractor.make_shareable b # => <internal:ractor>:820:in `make_shareable': can not make shareable object for #<Method: String#to_s()> (Ractor::Error) c = str.instance_exec { method(:to_s).to_proc } Ractor.make_shareable c c.call # => "" str[0] = "!" c.call # => "!" ``` Related, maybe: #19372 #19374 Tangential: why does Proc cause Ractor::IsolationError but Method causes Ractor::Error? -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120915] [Ruby master Bug#21125] Kernel is called first
by mikik0 (Hashino Mikiko) 26 Mar '25

26 Mar '25

Issue #21125 has been reported by mikik0 (Hashino Mikiko). ---------------------------------------- Bug #21125: Kernel is called first https://bugs.ruby-lang.org/issues/21125 * Author: mikik0 (Hashino Mikiko) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Kernel#system is being called when there is a column or method name named system. The other methods of Kernel reproduce the problem. Ex.Rand returns a random value, and exit terminates the program. ## Reproducible script: ``` ruby class ObjectifiedHash def initialize(hash) @hash = hash end private attr_reader :hash def method_missing(method_name, *args, &block) if hash.key?(method_name.to_sym) hash[method_name.to_sym] else super end end def respond_to_missing?(method_name, include_private = false) hash.key?(method_name.to_sym) || super end end class Foo def system(...) # Kernel#system is called raw.system(...) # (...) passes if there is no # raw.system end def initialize(raw) @raw = raw end def get_system system end private attr_reader :raw end class Test def self.run obj = ObjectifiedHash.new({ system: 'system' }) foo = Foo.new(obj) # foo.system would pass. # After executing foo.system, hoge.get_system also passes. # p foo.system p foo.get_system end end Test.run ``` ## Execution Results ``` shell hoge.rb:26:in 'Kernel#system': wrong number of arguments (given 0, expected 1+) (ArgumentError) raw.system(...) ^^^ from ruby.rb:26:in 'Foo#system' from ruby.rb:36:in 'Foo#get_system' from ruby.rb:54:in 'Test.run' from ruby.rb:58:in '<main>' ``` ## Expected results ``` shell "system" ``` PR that may be relevant: https://github.com/ruby/ruby/pull/11028 -- https://bugs.ruby-lang.org/

3 6

[ruby-core:121400] [Ruby Bug#21191] Ruby 3.4.2 crashes unexpectedly
by datanoise (Kent Sibilev) 26 Mar '25

26 Mar '25

Issue #21191 has been reported by datanoise (Kent Sibilev). ---------------------------------------- Bug #21191: Ruby 3.4.2 crashes unexpectedly https://bugs.ruby-lang.org/issues/21191 * Author: datanoise (Kent Sibilev) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Running my Rails app in development mode with Ruby 3.4.2 crashes with: Thread 15 Crashed:: puma srv tp 003 0 libsystem_kernel.dylib 0x19323f720 __pthread_kill + 8 1 libsystem_pthread.dylib 0x193277f70 pthread_kill + 288 2 libsystem_c.dylib 0x193184908 abort + 128 3 libruby.3.4.dylib 0x10176c30c die + 12 4 libruby.3.4.dylib 0x101a78e38 rb_bug + 32 5 libruby.3.4.dylib 0x101a49570 yjit::yjit::rb_bug_panic_hook::_$u7b$$u7b$closure$u7d$$u7d$::h0f4c55d7c8e55fcf + 340 6 libruby.3.4.dylib 0x1019d242c std::panicking::rust_panic_with_hook::h9a5dc30b684e2ff4 + 740 7 libruby.3.4.dylib 0x1019d2030 std::panicking::begin_panic_handler::_$u7b$$u7b$closure$u7d$$u7d$::hbcb5de8b840ae91c + 104 8 libruby.3.4.dylib 0x1019d1188 std::sys::backtrace::__rust_end_short_backtrace::ha657d4b4d65dc993 + 12 9 libruby.3.4.dylib 0x1019d1cdc rust_begin_unwind + 32 10 libruby.3.4.dylib 0x101a6a8c8 core::panicking::panic_fmt::hda207213c7ca0065 + 32 11 libruby.3.4.dylib 0x101a6a938 core::panicking::panic::h58f3db1cc4835fac + 52 12 libruby.3.4.dylib 0x1019f3330 yjit::codegen::jit_guard_known_klass::h231d0cbaae1c099c + 2852 13 libruby.3.4.dylib 0x1019ec404 yjit::codegen::gen_equality_specialized::h93a21f50d2816872 + 760 14 libruby.3.4.dylib 0x1019ec82c yjit::codegen::gen_opt_eq::h5396bf9fac489b74 + 36 15 libruby.3.4.dylib 0x1019df604 yjit::codegen::gen_single_block::h01cba096a3e9933d + 2996 16 libruby.3.4.dylib 0x101a200a8 yjit::core::gen_block_series::h1b8008b9e695e93a + 132 17 libruby.3.4.dylib 0x101a21fe0 yjit::core::branch_stub_hit_body::ha9f3b0e799953b26 + 916 18 libruby.3.4.dylib 0x101a3a390 yjit::stats::with_compile_time::hb64811b90dfb965e + 64 19 libruby.3.4.dylib 0x101a66088 yjit::cruby::with_vm_lock::hf301ea5cad023986 + 84 20 libruby.3.4.dylib 0x101a253e4 yjit::core::branch_stub_hit::h44174fb9640d7093 + 80 21 ??? 0x150002078 ??? 22 libruby.3.4.dylib 0x10190ad58 vm_exec_core + 9576 23 libruby.3.4.dylib 0x1019072d8 rb_vm_exec + 492 24 libruby.3.4.dylib 0x10192ed2c invoke_block_from_c_bh + 872 25 libruby.3.4.dylib 0x10192e46c catch_i + 108 26 libruby.3.4.dylib 0x101918e78 vm_catch_protect + 200 27 libruby.3.4.dylib 0x101919888 rb_f_catch + 112 28 ??? 0x1502acbe4 ??? 29 libruby.3.4.dylib 0x10190ad58 vm_exec_core + 9576 30 libruby.3.4.dylib 0x101907304 rb_vm_exec + 536 31 libruby.3.4.dylib 0x10191ba24 vm_invoke_proc + 712 32 libruby.3.4.dylib 0x1018db74c thread_do_start_proc + 668 33 libruby.3.4.dylib 0x1018dae18 thread_start_func_2 + 796 34 libruby.3.4.dylib 0x1018da994 nt_start + 248 35 libsystem_pthread.dylib 0x1932782e4 _pthread_start + 136 36 libsystem_pthread.dylib 0x1932730fc thread_start + 8 ---Files-------------------------------- ruby-2025-03-18-112226.ips (97.7 KB) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120884] [Ruby master Bug#21115] Etc.getgrgid is not Ractor-safe but is marked as such
by Eregon (Benoit Daloze) 25 Mar '25

25 Mar '25

Issue #21115 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21115: Etc.getgrgid is not Ractor-safe but is marked as such https://bugs.ruby-lang.org/issues/21115 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby require 'etc' 20.times.map do Ractor.new do 1000.times do raise unless Etc.getgrgid(Process.gid).gid == Process.gid end end end.each(&:take) ``` Running it a few times gives a segfault: ``` $ ruby ractor_getgrgid.rb ractor_getgrgid.rb:4: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. #<Thread:0x00007f251b7d0478 run> terminated with exception (report_on_exception is true): ractor_getgrgid.rb:6:in 'block (3 levels) in <main>': unhandled exception from <internal:numeric>:257:in 'Integer#times' from ractor_getgrgid.rb:5:in 'block (2 levels) in <main>' #<Thread:0x00007f251b7dde70 run> terminated with exception (report_on_exception is true): ractor_getgrgid.rb:6:in 'block (3 levels) in <main>': unhandled exception from <internal:numeric>:257:in 'Integer#times' from ractor_getgrgid.rb:5:in 'block (2 levels) in <main>' ractor_getgrgid.rb:6: [BUG] Segmentation fault at 0x00000000706d7564 ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0005 p:---- s:0019 e:000018 CFUNC :getgrgid c:0004 p:0009 s:0014 e:000013 BLOCK ractor_getgrgid.rb:6 c:0003 p:0024 s:0011 e:000010 METHOD <internal:numeric>:257 c:0002 p:0005 s:0006 e:000005 BLOCK ractor_getgrgid.rb:5 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] ``` Etc is marked as Ractor-safe since https://github.com/ruby/ruby/pull/3954. But that is not correct, etc.c uses many C functions which are not thread-safe, such as `getgrgid()`. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:118823] [Ruby master Bug#20670] fork deadlocks in child process due to timer thread
by jhawthorn (John Hawthorn) 22 Mar '25

22 Mar '25

Issue #20670 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #20670: fork deadlocks in child process due to timer thread https://bugs.ruby-lang.org/issues/20670 * Author: jhawthorn (John Hawthorn) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- We've been seeing an occasional failure in the Rails CI related to a test which forks and I managed to reduce it to the following reproduction. ``` ruby Thread.new do loop { sleep 0.0001 } end 1000.times do pid = fork{} Process.waitpid(pid) rescue Exception Process.kill(:KILL, pid) raise end ``` This hangs on Ruby 3.3 and HEAD (_fairly_ reliably), but completes always on Ruby 3.2 In a debugger it seems like the timer thread acquires `vm->ractor.sched.lock` in the parent process just as the process is forking. The child process then ends up stuck inside of `thread_sched_atfork` when trying to acquire the same lock. I've opened https://github.com/ruby/ruby/pull/11356 with a fix -- https://bugs.ruby-lang.org/

4 4

[ruby-core:121429] [Ruby Bug#21196] Ruby 3.4 ignores visibility when passing arguments using `...`
by toy (Ivan Kuchin) 21 Mar '25

21 Mar '25

Issue #21196 has been reported by toy (Ivan Kuchin). ---------------------------------------- Bug #21196: Ruby 3.4 ignores visibility when passing arguments using `...` https://bugs.ruby-lang.org/issues/21196 * Author: toy (Ivan Kuchin) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- If method is passing arguments using `...`, then receiver visibility gets ignored if once called without receiver: ```ruby class A private def foo = :foo def bar = :bar end class B def initialize(o) @o = o end def foo(...) = @o.foo(...) def bar = @o.bar def internal_foo = foo def internal_bar = bar end def try p yield rescue => e p e end ``` If `foo` is called first without receiver through `internal_foo`: ```ruby b = B.new(A.new) try{ b.internal_foo } try{ b.internal_bar } try{ b.foo } try{ b.bar } ``` Visibility of `A#foo` gets ignored: ``` ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] :foo #<NoMethodError: private method 'bar' called for an instance of A> :foo #<NoMethodError: private method 'bar' called for an instance of A> ``` ``` ruby 3.3.7 (2025-01-15 revision be31f993d7) [x86_64-linux] #<NoMethodError: private method `foo' called for an instance of A> #<NoMethodError: private method `bar' called for an instance of A> #<NoMethodError: private method `foo' called for an instance of A> #<NoMethodError: private method `bar' called for an instance of A> ``` If `internal_foo` is not called before `foo`: ```ruby b = B.new(A.new) try{ b.foo } try{ b.bar } ``` Visibility of `A#foo` gets checked: ``` ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] #<NoMethodError: private method 'foo' called for an instance of A> #<NoMethodError: private method 'bar' called for an instance of A> ``` ``` ruby 3.3.7 (2025-01-15 revision be31f993d7) [x86_64-linux] #<NoMethodError: private method `foo' called for an instance of A> #<NoMethodError: private method `bar' called for an instance of A> ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121421] [Ruby Feature#21194] How to manage application-level information in Ruby application
by mame (Yusuke Endoh) 21 Mar '25

21 Mar '25

Issue #21194 has been reported by mame (Yusuke Endoh). ---------------------------------------- Feature #21194: How to manage application-level information in Ruby application https://bugs.ruby-lang.org/issues/21194 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- ## Goal I want to manage application-level information (e.g., application configuration) while making it easily accessible from the part classes of the application. Additionally, I want to support multiple instances of the application within a single process. ## Current approach 1: Global variables The simplest way to achieve this is by using global variables. ```ruby class MyApp class Part1 def run using $config[:part1]... end end class Part2 def run using $config[:part2]... end end def initialize(config) $config = config @part1 = Part1.new @part2 = Part2.new end def run @part1.run @part2.run end end app1 = MyApp.new({ part1: "aaa", part2: "bbb" }) # app2 = MyApp.new({ part1: "AAA", part2: "BBB" }) # Cannot create this app1.run ``` This code is simple and clear, but it does not allow creating multiple `MyApp` instances with different configurations. To achieve that, we would need to create separate process using `fork` or `spawn`. This limitation remains even if we replace global variables with constants (`MyApp::Config`) or class methods (`MyApp.config`). ## Current approach 2: Passing configuration via `initialize` A textbook and well-structured approach is to explicitly pass configuration through `initialize`. ```ruby class MyApp class Part1 def initialize(config) @config = config end def run using @config[:part1]... end end class Part2 def initialize(config) @config = config end def run using @config[:part2]... end end def initialize(config) @part1 = Part1.new(config) @part2 = Part2.new(config) end def run @part1.run @part2.run end end app1 = MyApp.new({ part1: ..., part2: ... }) app2 = MyApp.new({ part1: ..., part2: ... }) app1.run app2.run ``` This approach allows creating multiple MyApp instances with different configurations in a single Ruby process. However, it has two major drawbacks: * `config` must be passed explicitly in every `initialize` and `new` call, making the code verbose. * Both `Part1` and `Part2` instances hold their own `@config` variables, which is redundant -- especially when creating a large number of small instances (e.g., tree nodes). ## Current approach 3: Thread-local storage Storing configuration in `Thread[:config]` allows multiple application instances without explicit parameter passing. ```ruby class MyApp class Part1 def run using Thread[:config][:part1]... end end class Part2 def run using Thread[:config][:part2]... end end def initialize(config) @config = config @part1 = Part1.new @part2 = Part2.new end def run Thread[:config] = config @part1.run @part2.run end end app1 = MyApp.new({ part1: ..., part2: ... }) app2 = MyApp.new({ part1: ..., part2: ... }) app1.run app2.run ``` This approach is mostly effective but has an issue: * `Thread[:config] = @config` must be set at the beginning of `MyApp#run`. While this is manageable if there is only one public API, it becomes error-prone when multiple APIs exist. Note that using `Fiber#[]` instead of `Thread#[]` has the same issue. ## Proposal Ideally, we want to support multiple application instances while keeping the simplicity of the global variable approach. To achieve this, I propose introducing a new type variable, such as `$@config`: * `$@config` belongs to an instance * When accessing `$@config`, it is looked up not only in `self` but also by traversing the call stack to find the nearest `self` instance that has `$@config`. With this, the code could be written as follows: ```ruby class MyApp class Part1 def run $@config[:part1] # accesses MyApp's $@config end end class Part2 def run $@config[:part2] end end def initialize(config) $@config = config @part1 = Part1.new @part2 = Part2.new end def run @part1.run @part2.run end end app1 = MyApp.new({ part1: ..., part2: ... }) app2 = MyApp.new({ part1: ..., part2: ... }) app1.run app2.run ``` This behaves similarly to dynamically scoped variables but differs in that it is resolved through the `self` instances. (`Thread.new` is a bit problematic: if you use `Thread.new` in a method of `MyApp::Part1`, you wouldn't have access to `$@config` in it. It might be nice to take over all `$@x` variables.) ## Feedback wanted Whenever I write a large Ruby application, I encounter this problem. However, TBH, I am not entirely confident that my proposed solution is the best one. Do you ever encounter this problem? How do you deal with the problem when you do? Is there a better workaround? -- https://bugs.ruby-lang.org/

1 0