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

[ruby-core:121468] [Ruby Feature#17414] Ractor should allow access to shareable attributes for Modules/Classes
by jhawthorn (John Hawthorn) 28 Mar '25

28 Mar '25

Issue #17414 has been updated by jhawthorn (John Hawthorn). Status changed from Assigned to Closed I think we can close this as accessing the class instance variables has been allowed for a while (Ruby 3.1?) ``` ruby module Config class << self attr_accessor :conf end self.conf = 42 end Ractor.new { Config.conf = 66 }.take # => can not set instance variables of classes/modules by non-main Ractors (Ractor::IsolationError) Ractor.new { puts Config.conf }.take # => 42 ``` ---------------------------------------- Feature #17414: Ractor should allow access to shareable attributes for Modules/Classes https://bugs.ruby-lang.org/issues/17414#change-112475 * Author: marcandre (Marc-Andre Lafortune) * Status: Closed * Assignee: ko1 (Koichi Sasada) ---------------------------------------- Current situation is *very* limiting. Use-case: global config. Example: [yaml has a global config](https://github.com/ruby/psych/blob/master/lib/psych.rb#L637-L640) and it's not clear to me how to make that Ractor-aware (nicely). It is possible to have the same effect but in ugly ways: ```ruby # Using instance variables of Module not allowed: module Config class << self attr_accessor :conf end self.conf = 42 end Ractor.new { Config.conf = 66 }.take # => can not access instance variables from non-main Ractors Ractor.new { puts Config.conf }.take # => can not access instance variables from non-main Ractors # Same functionality using constants allowed: module Config class << self def conf CONF end def conf=(new_conf) remove_const(:CONF) const_set(:CONF, new_conf) end end CONF = 42 end Ractor.new { Config.conf = 66 }.take # => ok Ractor.new { puts Config.conf }.take # => 66 # Same functionality using methods allowed: module Config class << self def conf 42 end def conf=(new_conf) singleton_class.undef_method(:conf) define_singleton_method(:conf, &Ractor.make_shareable(Proc.new { new_conf })) end end end Ractor.new { Config.conf = 66 }.take # => ok Ractor.new { puts Config.conf }.take # => 66 ``` The priority would be to allow reading these instance variables if they are shareable. Ideally writing would also be allowed, but limiting that to main ractor is less probablematic than with reading. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121448] [Ruby Bug#21199] Psych.dump and load on Date before 1582-10-15
by fitmap (Justin Peal) 28 Mar '25

28 Mar '25

Issue #21199 has been reported by fitmap (Justin Peal). ---------------------------------------- Bug #21199: Psych.dump and load on Date before 1582-10-15 https://bugs.ruby-lang.org/issues/21199 * Author: fitmap (Justin Peal) * Status: Open * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x64-mingw-ucrt] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The code is: require 'date' require 'psych' date = Date.new(1582, 10, 4) p "date=#{date.inspect}" str = Psych.dump(date, permitted_classes: [Date]) p "str=#{str}" date2 = Psych.load(str, permitted_classes: [Date]) p "date2=#{date2.inspect}" The output is: "date=#<Date: 1582-10-04 ((2299160j,0s,0n),+0s,2299161j)>" "str=--- 1582-10-14\n" "date2=#<Date: 1582-10-14 ((2299160j,0s,0n),+0s,-Infj)>" -- https://bugs.ruby-lang.org/

3 3

[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