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

[ruby-core:111960] [Ruby master Bug#19364] Issue with tracepoint enable/disable across ractors
by luke-gru (Luke Gruber) 08 Sep '26

08 Sep '26

Issue #19364 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19364: Issue with tracepoint enable/disable across ractors https://bugs.ruby-lang.org/issues/19364 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This sometimes segfaults: ```ruby def test_enable_disable_in_multiple_ractors_with_target rs = [] 100.times do |i| # setup new iseqs Kernel.define_method :"my_method_to_change_for_tracing_#{i}" do true end end 100.times do |i| rs << Ractor.new(i) do |j| meth = :"my_method_to_change_for_tracing_#{j}" tp = TracePoint.new(:line) { } # local to ractor 100.times do tp.enable(target: method(meth)) # change iseq internals of given method, should be done with lock tp.disable # disable hooks should hold lock too, changes method definition internals end end end rs.each(&:take) # shouldn't raise end test_enable_disable_in_multiple_ractors_with_target() ``` Changing iseq internals is done without the VM lock. This is true in Tracepoint#enable and Tracepoint#disable methods. I have a patch coming. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:126605] [Ruby Bug#18733] Heavy GC allocations cause performance issue with Ractor
by ko1 (Koichi Sasada) 08 Sep '26

08 Sep '26

Issue #18733 has been updated by ko1 (Koichi Sasada). Status changed from Assigned to Closed Re-checked on master 4d185cce78 (4.1.0dev). The gap this ticket is about is gone. I used jhawthorn's variant of the benchmark from #note-4 (`[0,1].itself.include?(n)`, so the array literal is not elided), fib(34) in 8 workers, with fork and Ractor measured alternately inside the same process, two rounds each: ruby fork wall ractor wall ractor/fork ractor cpu/wall (max 8) master 4d185cce78 2.12 / 2.26 2.03 / 2.09 x0.96 / x0.92 7.89 / 7.85 4.0.2 2.57 / 2.64 5.36 / 6.56 x2.08 / x2.49 3.56 / 3.09 3.4.4 2.76 / 2.91 89.8 / 94.5 x32.6 / x32.4 1.64 / 1.61 3.3.2 2.57 / 2.74 115.6 / 83.1 x45.0 / x30.3 1.80 / 2.08 On master the Ractor version is as fast as fork and uses 7.85-7.89 of the 8 cores; the remaining difference is run-to-run noise. The big step is the per-Ractor GC work (GH-18194, merged 2026-08-07), which is in master but not in 4.0: allocation-heavy Ractors no longer serialise on a global GC. (I did not bisect; this is a version-level attribution. The earlier 3.4 -> 4.0 step, x32 -> x2, is separate GC work.) Measured on an idle 16-core Linux box. Only the fork/Ractor ratio within one run should be read, not the absolute times. ---------------------------------------- Bug #18733: Heavy GC allocations cause performance issue with Ractor https://bugs.ruby-lang.org/issues/18733#change-118837 * Author: jakit (Jakit Liang) * Status: Closed * Assignee: ractor * ruby -v: ruby 3.1.1p18 (2022-02-18 revision 53f5fc4236) [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Code: ``` require 'benchmark' def fib(n) return n if [0,1].include?(n) fib(n-1) + fib(n-2) end tp = [] puts Benchmark.measure { 8.times do tp << fork { fib(37) } end tp.each { |t| Process.wait(t) } } puts Benchmark.measure { 8.times.map { Ractor.new { fib(37) } }.each{ |r| r.take } } ``` Result: |A |B | |--|--| | fork | 0.000264 0.003439 87.181198 ( 11.211349) | | Ractor | 80.292916 15.062559 95.355475 ( 39.569527) | And I found that here's the problem showing on the ActiveMonitor.app: ![ruby_bug_with_m1](http://jakit.cn/screen_shot_ruby_bug.jpg) As you can see, the process of ruby is always using all Performance Cores on my Apple M1 Mac. But there's no one of the Efficiency Cores was in used by ruby Ractor. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116061] [Ruby master Bug#20158] Ractor affects Coverage results
by janosch-x 08 Sep '26

08 Sep '26

Issue #20158 has been reported by janosch-x (Janosch Müller). ---------------------------------------- Bug #20158: Ractor affects Coverage results https://bugs.ruby-lang.org/issues/20158 * Author: janosch-x (Janosch Müller) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0preview1 (2023-05-12 master a1b01e7701) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I have a large rspec test suite. I found that if I call a Ractor, the Coverage results are strongly affected, i.e. almost all files appear to be uncovered. This happens even if I only ever call a Ractor before the library or rspec are required. Unfortunately, I was not able to build a simple repro yet. I assume it is a timing thing and only affects larger suites, or it only happens if there are multiple files, and maybe if the library lazily requires its sub-modules? However, I guess this should produce the same results when added to the spec_helper.rb of other large suites: ```ruby # Ractor.new { nil } # uncomment this to affect coverage results require 'coverage' Coverage.start # require library, set up rspec etc. RSpec.configuration.after(:suite) do # this number is greatly reduced and unstable when calling Ractor above p Coverage.result.values.sum { |arr| arr.sum(&:to_i) } end ``` I had this problem in [this library](https://github.com/jaynetics/character_set/). The problem affects simplecov users as well, as described [here](https://github.com/simplecov-ruby/simplecov/issues/1058). -- https://bugs.ruby-lang.org/

4 5

[ruby-core:121941] [Ruby Bug#21315] Finalizers violate the `rb_ractor_confirm_belonging` assertion
by byroot (Jean Boussier) 08 Sep '26

08 Sep '26

Issue #21315 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21315: Finalizers violate the `rb_ractor_confirm_belonging` assertion https://bugs.ruby-lang.org/issues/21315 * Author: byroot (Jean Boussier) * Status: Open * Assignee: ractor * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Reproduction (with assertions enabled): ```ruby require "tempfile" Ractor.new do 10.times do Tempfile.new end end.take GC.start ``` ``` <OBJ_INFO:rb_ractor_confirm_belonging@../src/ractor_core.h:375> (File) /home/runner/work/ruby/ruby/src/lib/tempfile.rb:387: [BUG] rb_ractor_confirm_belonging object-ractor id:1, current-ractor id:2 ruby 3.5.0dev (2025-05-09T15:51:24Z pull/13291/merge e289a1dc58) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0005 p:0007 s:0025 e:000024 METHOD /home/runner/work/ruby/ruby/src/lib/tempfile.rb:387 [FINISH] c:0004 p:0022 s:0020 e:000019 METHOD /home/runner/work/ruby/ruby/src/lib/prism/parse_result.rb:833 [FINISH] c:0003 p:---- s:0012 e:000011 CFUNC :parse_lex_file c:0002 p:0006 s:0007 e:000006 BLOCK /home/runner/work/ruby/ruby/src/test/prism/ractor_test.rb:26 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- /home/runner/work/ruby/ruby/src/test/prism/ractor_test.rb:26:in 'block in test_parse_lex_file' /home/runner/work/ruby/ruby/src/test/prism/ractor_test.rb:26:in 'parse_lex_file' /home/runner/work/ruby/ruby/src/lib/prism/parse_result.rb:833:in 'initialize' /home/runner/work/ruby/ruby/src/lib/tempfile.rb:387:in 'call' -- Threading information --------------------------------------------------- Total ractor count: 2 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /home/runner/work/ruby/ruby/build/ruby(rb_print_backtrace+0x14) [0x561441aeedbf] ../src/vm_dump.c:843 /home/runner/work/ruby/ruby/build/ruby(rb_vm_bugreport) ../src/vm_dump.c:1175 /home/runner/work/ruby/ruby/build/ruby(bug_report_end+0x0) [0x561441aa3f39] ../src/error.c:1097 /home/runner/work/ruby/ruby/build/ruby(rb_bug_without_die_internal) ../src/error.c:1097 /home/runner/work/ruby/ruby/build/ruby(die+0x0) [0x5614416e237f] ../src/error.c:1115 /home/runner/work/ruby/ruby/build/ruby(rb_bug) ../src/error.c:1117 /home/runner/work/ruby/ruby/build/ruby(rb_ractor_confirm_belonging+0xde) [0x56144188c6be] ../src/ractor_core.h:376 /home/runner/work/ruby/ruby/build/ruby(vm_exec_core+0xef) [0x5614418b23ef] /home/runner/work/ruby/ruby/build/vm.inc:2500 /home/runner/work/ruby/ruby/build/ruby(rb_vm_exec+0x156) [0x5614418a4676] ../src/vm.c:2618 /home/runner/work/ruby/ruby/build/ruby(vm_call0_cc+0x13d) [0x5614418aa1dd] ../src/vm_eval.c:101 /home/runner/work/ruby/ruby/build/ruby(rb_vm_call0+0x4c) [0x5614418b1cc5] ../src/vm_eval.c:61 /home/runner/work/ruby/ruby/build/ruby(rb_vm_call_kw) ../src/vm_eval.c:326 /home/runner/work/ruby/ruby/build/ruby(rb_check_funcall_default_kw) ../src/vm_eval.c:694 /home/runner/work/ruby/ruby/build/ruby(rb_gc_run_obj_finalizer+0x1cf) [0x56144170220f] ../src/gc.c:306 /home/runner/work/ruby/ruby/build/ruby(rb_multi_ractor_p+0x0) [0x56144170246f] ../src/gc/default/default.c:2820 /home/runner/work/ruby/ruby/build/ruby(rb_vm_lock_enter) ../src/vm_sync.h:74 /home/runner/work/ruby/ruby/build/ruby(rb_gc_vm_lock) ../src/gc.c:137 /home/runner/work/ruby/ruby/build/ruby(finalize_list) ../src/gc/default/default.c:2843 /home/runner/work/ruby/ruby/build/ruby(finalize_deferred_heap_pages) ../src/gc/default/default.c:2866 ``` I think it wouldn't be hard to disable that check when running a finalizer, but I don't know if it's the correct thing to do. -- https://bugs.ruby-lang.org/

5 8

[ruby-core:112091] [Ruby master Bug#19387] Issue with ObjectSpace.each_objects not returning IO objects after starting a ractor
by luke-gru (Luke Gruber) 08 Sep '26

08 Sep '26

Issue #19387 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19387: Issue with ObjectSpace.each_objects not returning IO objects after starting a ractor https://bugs.ruby-lang.org/issues/19387 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby r = Ractor.new do receive # block, the problem is not the termination of the ractor but the starting end ObjectSpace.each_object(IO) { |io| p io # we get no objects } ``` -- https://bugs.ruby-lang.org/

6 9

[ruby-core:126596] [Ruby Bug#22299] opt_new emits a duplicate :line trace point for Const.new following a branch
by Eregon (Benoit Daloze) 08 Sep '26

08 Sep '26

Issue #22299 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #22299: opt_new emits a duplicate :line trace point for Const.new following a branch https://bugs.ruby-lang.org/issues/22299 * Author: Eregon (Benoit Daloze) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary On Ruby master (`4.1.0dev`), compiling an expression of the form `Constant.new(...)` that is the first statement of a basic block reached after a branch (e.g. immediately after a `return unless`/`next unless` guard) produces **two** `:line` trace points for that one line instead of one. The extra event only appears when the `opt_new` specialized instruction is generated, so it depends on: - a **constant** receiver (`Foo.new`, `A::B.new` — not `foo.new`), - the method being `new` with `opt_new` applicable (no block; `Foo.new { }` is fine), - the call sitting at the head of a basic block after a control-flow merge, and - `RubyVM::InstructionSequence.compile_option[:specialized_instruction]` being `true` (the default). ## Reproduction ```ruby def line_events(iseq) ev = iseq.trace_points.select { |_, e| e == :line }.map(&:first) iseq.each_child { |c| ev.concat(line_events(c)) } ev end src = <<~RUBY return unless x Foo.new RUBY [true, false].each do |spec| RubyVM::InstructionSequence.compile_option = { specialized_instruction: spec } events = line_events(RubyVM::InstructionSequence.compile(src)) puts "specialized_instruction: #{spec.inspect}\t=> line events #{events.inspect}" end ``` ### Output Ruby `4.1.0dev` (master): ``` specialized_instruction: true => line events [1, 2, 2] specialized_instruction: false => line events [1, 2] ``` Ruby `4.0.6` (and earlier): ``` specialized_instruction: true => line events [1, 2] specialized_instruction: false => line events [1, 2] ``` Line 2 (`Foo.new`) is reported twice on master with the default compile options. ## Analysis With `specialized_instruction: true`, the `opt_new` codepath prepends a `putnil` (reserving the slot for the object) that carries the statement's line, and the following `opt_getconstant_path` *also* carries a `:line` trace point — so line 2 is emitted twice: ``` 0007 putnil ( 2)[Li] # statement start 0008 opt_getconstant_path <Foo>[Li] # duplicate :line on the same line 0010 opt_new <calldata!mid:new, argc:0, ARGS_SIMPLE>, 17 ``` For comparison, the non-`opt_new` path (`Foo.bar`, or `Foo.new` under `specialized_instruction: false`) emits the line once, on `opt_getconstant_path`: ``` 0007 opt_getconstant_path <Foo>( 2)[Li] 0009 opt_send_without_block <calldata!mid:bar, ...> ``` The `[Li]` on `opt_getconstant_path` in the `opt_new` path appears to be redundant: the `putnil` before it already carries the statement's line event. ## Impact This surfaced as a failure of `test/prism/newline_test.rb` in `make test-all` on ruby-head in [this Prism PR](https://github.com/ruby/prism/pull/4223). That test asserts that prism's newline flags match RubyVM's `:line` trace points exactly. Two fixtures hit the pattern: - `test/prism/ruby/parameters_signature_test.rb:95` — `object = Object.new` after `return unless compare` - `test/prism/locals_test.rb:101` — `yield ISeq.new(opnd)` after `next unless ...` It is not observed when running the same test in the prism repository, because there `require "test/unit"` (the test-unit gem) sets `specialized_instruction: false` globally, which suppresses `opt_new` and therefore the duplicate event. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:115328] [Ruby master Bug#19996] `RUBY_MN_THREADS=1` triggers Action Cable unit test failures
by yahonda (Yasuo Honda) 08 Sep '26

08 Sep '26

Issue #19996 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #19996: `RUBY_MN_THREADS=1` triggers Action Cable unit test failures https://bugs.ruby-lang.org/issues/19996 * Author: yahonda (Yasuo Honda) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-11-09T16:24:15Z :detached: c49adfab5d) +MN [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ### Steps to reproduce 1. Install `ruby 3.3.0dev` 2. Set `RUBY_MN_THREADS=1` environment variable 3. git clone https://github.com/rails/rails cd rails rm Gemfile.lock bundle install cd actioncable bin/test test/channel/base_test.rb test/subscription_adapter/redis_test.rb test/channel/test_case_test.rb test/subscription_adapter/redis_test.rb test/client_test.rb --seed 14800 ``` ### Expected behavior It should pass as not setting ``` $ unset RUBY_MN_THREADS $ bin/test test/channel/base_test.rb test/subscription_adapter/redis_test.rb test/channel/test_case_test.rb test/subscription_adapter/redis_test.rb test/client_test.rb --seed 14800 /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/minitest-5.20.0/lib/minitest.rb:3: warning: mutex_m which will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec. Run options: --seed 14800 # Running: ......................................................................... Finished in 12.031310s, 6.0675 runs/s, 46.7115 assertions/s. 73 runs, 562 assertions, 0 failures, 0 errors, 0 skips $ ``` ### Actual behavior It usually fails as follows. ``` $ bin/test test/channel/base_test.rb test/subscription_adapter/redis_test.rb test/channel/test_case_test.rb test/subscription_adapter/redis_test.rb test/client_test.rb --seed 14800 /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/minitest-5.20.0/lib/minitest.rb:3: warning: mutex_m which will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec. Run options: --seed 14800 # Running: ..................................................F Failure: RedisAdapterTest::AlternateConfiguration#test_channel_prefix [/home/yahonda/src/github.com/rails/rails/actioncable/test/subscription_adapter/common.rb:35]: Expected #<Concurrent::Event:0x00007f0b2698d4f0 @__Lock__=#<Thread::Mutex:0x00007f0b26f8cab8>, @__Condition__=#<Thread::ConditionVariable:0x00007f0b26f8ca90>, @set=false, @iteration=0> to be set?. bin/test test/subscription_adapter/channel_prefix.rb:6 .F Failure: RedisAdapterTest::AlternateConfiguration#test_multiple_broadcast [/home/yahonda/src/github.com/rails/rails/actioncable/test/subscription_adapter/common.rb:35]: Expected #<Concurrent::Event:0x00007f0b2698a4d0 @__Lock__=#<Thread::Mutex:0x00007f0b26fac688>, @__Condition__=#<Thread::ConditionVariable:0x00007f0b26fac4f8>, @set=false, @iteration=0> to be set?. bin/test test/subscription_adapter/common.rb:74 E Error: ClientTest#test_interacting_clients: ThreadError: queue empty <internal:thread_sync>:18:in `pop' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:168:in `read_message' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:241:in `block (2 levels) in test_interacting_clients' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:218:in `block (2 levels) in concurrently' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/promises.rb:1583:in `evaluate_to' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/promises.rb:1766:in `block in on_resolvable' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:352:in `run_task' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:343:in `block (3 levels) in create_worker' <internal:kernel>:187:in `loop' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:334:in `block (2 levels) in create_worker' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:333:in `catch' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:333:in `block in create_worker' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/promises.rb:1258:in `raise' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/promises.rb:1258:in `wait_until_resolved!' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/promises.rb:988:in `value!' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:218:in `map' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:218:in `concurrently' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:240:in `block in test_interacting_clients' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:90:in `with_puma_server' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:234:in `test_interacting_clients' bin/test test/client_test.rb:233 E Error: ClientTest#test_disappearing_client: ThreadError: queue empty <internal:thread_sync>:18:in `pop' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:168:in `read_message' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:275:in `block in test_disappearing_client' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:90:in `with_puma_server' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:273:in `test_disappearing_client' bin/test test/client_test.rb:272 .................. Finished in 1323.812615s, 0.0551 runs/s, 0.3830 assertions/s. 73 runs, 507 assertions, 2 failures, 2 errors, 0 skips $ ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:126594] [Ruby Feature#17513] Methods of shareable objects and UnboundMethods should be shareable
by ko1 (Koichi Sasada) 08 Sep '26

08 Sep '26

Issue #17513 has been updated by ko1 (Koichi Sasada). Status changed from Assigned to Closed 4c893e2ff1 ---------------------------------------- Feature #17513: Methods of shareable objects and UnboundMethods should be shareable https://bugs.ruby-lang.org/issues/17513#change-118819 * Author: marcandre (Marc-Andre Lafortune) * Status: Closed * Assignee: ko1 (Koichi Sasada) ---------------------------------------- ```ruby class Foo def foo end end f = Foo.new.freeze Ractor.shareable?(f) # => true Ractor.make_shareable(f.method(:foo).to_proc) # => Proc, ok Ractor.make_shareable(f.method(:foo)) # => Ractor::Error, expected Method Ractor.make_shareable(Foo.instance_method(:foo)) # => Ractor::Error, expected UnboundMethod ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118182] [Ruby master Bug#20526] File.open(encoding: "bom|utf-8") converts "\r\n" to "\n" on Windows
by kou (Kouhei Sutou) 08 Sep '26

08 Sep '26

Issue #20526 has been reported by kou (Kouhei Sutou). ---------------------------------------- Bug #20526: File.open(encoding: "bom|utf-8") converts "\r\n" to "\n" on Windows https://bugs.ruby-lang.org/issues/20526 * Author: kou (Kouhei Sutou) * Status: Open * Target version: 3.2 * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x64-mingw-ucrt] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I'm not sure whether this is an intentional behavior but it seems that `encoding: "utf-8"` doesn't change newline conversion but `encoding: "bom|utf-8"` changes newline conversion: ```ruby File.write("a.txt", "a\r\n") File.read("a.txt").bytes # => [97, 13, 10] File.open("a.txt", encoding: "utf-8") {|f| f.read.bytes} # => [97, 10, 10] File.open("a.txt", encoding: "bom|utf-8") {|f| f.read.bytes} # => [97, 10] XXX: \r\n -> \n File.open("a.txt", encoding: "bom|utf-8", universal_newline: false) {|f| f.read.bytes} # => [97, 13, 10] ``` Note that the `XXX: ` line the above codes. Is this an intentional behavior? -- https://bugs.ruby-lang.org/

3 5

[ruby-core:125706] [Ruby Bug#22106] Getting a segfault when using finalizers and/or WeakMap in Ractors
by miles-georgi (Miles Georgi) 08 Sep '26

08 Sep '26

Issue #22106 has been reported by miles-georgi (Miles Georgi). ---------------------------------------- Bug #22106: Getting a segfault when using finalizers and/or WeakMap in Ractors https://bugs.ruby-lang.org/issues/22106 * Author: miles-georgi (Miles Georgi) * Status: Open * ruby -v: ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- If I run the following script I get a segfault: ```ruby def ractor_and_port_counts total_ractor_count = total_ractor_port_count = open_ractor_count = open_ractor_port_count = 0 ObjectSpace.each_object do |object| case object when Ractor total_ractor_count += 1 open_ractor_count += 1 unless object.default_port.closed? when Ractor::Port total_ractor_port_count += 1 open_ractor_port_count += 1 unless object.closed? end end [total_ractor_count, open_ractor_count, total_ractor_port_count, open_ractor_port_count] end def show_ractor_counts GC.start pp ractor_and_port_counts end class Wrapper class << self def finalizer_proc proc do |id| wrapper_to_ractor = Ractor[:wrapper_to_ractor] if wrapper_to_ractor wrapper_to_ractor[id]&.each_key { |ractor| ractor << :close } rescue Ractor::ClosedError end end end def setup_finalizer(wrapper) wrapper_to_ractor = Ractor[:wrapper_to_ractor] ||= {} map = wrapper_to_ractor[wrapper.object_id] ||= ObjectSpace::WeakMap.new map[wrapper.ractor] = true ObjectSpace.define_finalizer(wrapper, &finalizer_proc) end end attr_reader :ractor def initialize(object) @ractor = Ractor.new do loop { break if receive == :close } o = nil end @ractor.send(object, move: true) self.class.setup_finalizer(self) end end class Outer def initialize = @inner = Wrapper.new(Inner.new) end class Inner; end show_ractor_counts outer = Wrapper.new(Outer.new) show_ractor_counts outer = nil # Removing the following line makes it so it only segfaults sometimes instead of everytime show_ractor_counts ``` I'll attach the script and the whole segfault but part of the segfault is: ``` <internal:gc>:44: [BUG] FL_FINALIZE flag is set, but finalizers are not found ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0004 p:0010 s:0023 e:000018 l:y b:0001 METHOD <internal:gc>:44 c:0003 p:0004 s:0011 e:000010 l:y b:0001 METHOD test_scripts/finalizer-in-ractor-test-segfault:23 c:0002 p:0075 s:0007 E:000f98 l:n b:---- EVAL test_scripts/finalizer-in-ractor-test-segfault:72 [FINISH] c:0001 p:0000 s:0003 E:000b40 l:y b:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- test_scripts/finalizer-in-ractor-test-segfault:72:in '<main>' test_scripts/finalizer-in-ractor-test-segfault:23:in 'show_ractor_counts' <internal:gc>:44:in 'start' ``` This happens in both a local build of 4.1-dev and 4.0.5 I suspect one might need to put GC.start at the end of the script if unable to reproduce. ---Files-------------------------------- segfault.txt (22 KB) finalizer-in-ractor-test-segfault (1.66 KB) -- https://bugs.ruby-lang.org/

2 2