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

[ruby-core:123201] ‍
by voicemaiI 09 Sep '25

09 Sep '25

1 0

[ruby-core:123200] ‍
by voicemaiI 09 Sep '25

09 Sep '25

1 0

[ruby-core:123196] ‍
by voicemaiI 08 Sep '25

08 Sep '25

1 0

[ruby-core:123192] [Ruby Bug#18487] Kernel#binding behaves differently depending on implementation language of items on the stack
by alanwu (Alan Wu) 08 Sep '25

08 Sep '25

Issue #18487 has been updated by alanwu (Alan Wu). @ttilberg That's right. The backtrace has `bind_call` as the caller of `binding`, and `bind_call` is a C method, hence the exception. ---------------------------------------- Bug #18487: Kernel#binding behaves differently depending on implementation language of items on the stack https://bugs.ruby-lang.org/issues/18487#change-114523 * Author: alanwu (Alan Wu) * Status: Closed * ruby -v: ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Recently I [discovered] that one could use `Kernel#binding` to capture the environment of a frame that is not directly below the stack frame for `Kernel#binding`. I've known that C extensions have this [privilege] for a while, but didn't realize that it was also possible using only the core library. This is a powerful primitive that allows for some funky programs: ```ruby def lookup(hash, key) hash[key] hash end p lookup( Hash.new(&( Kernel.instance_method(:send).method(:bind_call).to_proc >> ->(binding) { binding.local_variable_set(:hash, :action_at_a_distance!) } ) ), :binding ) # => :action_at_a_distance! ``` There might be ways to compose core library procs such that it's less contrived and more useful, but I couldn't figure out a way to do it. Maybe there is a way to make a "local variable set" proc that takes only a name-value pair and no block? ### What's the big deal? This behavior makes the implementation language of methods part of the API surface for `Kernel#binding`. In other words, merely changing a Ruby method to be a C method can be a breaking change for the purposes of `Kernel#binding`, even if the method behaves the same in all other observable ways. I feel that whether a method is native or not should be an implementation detail and should not impact `Kernel#binding`. This is a problem for Ruby implementations that want to implement many core methods in Ruby, because they risk breaking compatibility with CRuby. TruffleRuby has this [problem][privilege] as I alluded to earlier, and CRuby risks making unintentional breaking changes as more methods change to become Ruby methods in the core library. ### Leaking less details I think a straight forward way to fix this issue is by making it so that `Kernel#binding` only ever looks at the stack frame directly below it. If the frame below is a not a Ruby frame, it can return an empty binding. I haven't done the leg work of figuring out how hard this would be to implement in CRuby, though. This new behavior allows observing the identity of native frames, which is new. ### Does the more restrictive behavior help YJIT? Maybe. It's hard to tell without building out more optimizations that are related to local variables. YJIT currently doesn't do much in that area. If I had to guess I wouuld say the more restrictive semantics at least open up the possibility of some deoptimization strategies that are more memory efficient. ### What do you think? This is not a huge issue, but it might be nice to start thinking about for the next release. If a lot of people actually rely on the current behavior we can provide a migration plan. Since it might take years to land, I would like to solicit feedback now. [discovered]: https://github.com/ruby/ruby/commit/54c91042ed61a869d4a66fc089b21f56d165265f [privilege]: https://github.com/oracle/truffleruby/issues/2171 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123190] [Ruby Bug#18487] Kernel#binding behaves differently depending on implementation language of items on the stack
by ttilberg (Tim Tilberg) 08 Sep '25

08 Sep '25

Issue #18487 has been updated by ttilberg (Tim Tilberg). I'm upgrading a project from Ruby 3.0 to Ruby 3.4, and I think I came across an unexpected bug related to this related to using `binding` from a `SimpleDelegator` child. Can someone help me confirm and organize? Example reproduction script: ``` ruby require 'erb' require 'delegate' class Report < SimpleDelegator def title "Great report" end def to_s ERB.new("<%= title %>!").result(binding) end end puts Report.new(Object.new).to_s ``` ``` ▶ ruby --version && ruby example.rb ruby 3.0.6p216 (2023-03-30 revision 23a532679b) [arm64-darwin22] Great report! ▶ ruby --version && ruby example.rb ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [arm64-darwin22] Great report! ▶ ruby --version && ruby example.rb ruby 3.2.4 (2024-04-23 revision af471c0e01) +YJIT [arm64-darwin23] /Users/ttilberg/.asdf/installs/ruby/3.2.4/lib/ruby/3.2.0/delegate.rb:89:in `binding': Cannot create Binding object for non-Ruby caller (RuntimeError) from /Users/ttilberg/.asdf/installs/ruby/3.2.4/lib/ruby/3.2.0/delegate.rb:89:in `bind_call' from /Users/ttilberg/.asdf/installs/ruby/3.2.4/lib/ruby/3.2.0/delegate.rb:89:in `method_missing' from example.rb:10:in `to_s' from example.rb:14:in `<main>' ``` And it continues the same into future versions. I arrived here by way of Zevrok's ruby references notes. https://rubyreferences.github.io/rubychanges/3.2.html#kernelbinding-raises-… -- it seemed like the most reasonable suspect. ---------------------------------------- Bug #18487: Kernel#binding behaves differently depending on implementation language of items on the stack https://bugs.ruby-lang.org/issues/18487#change-114520 * Author: alanwu (Alan Wu) * Status: Closed * ruby -v: ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Recently I [discovered] that one could use `Kernel#binding` to capture the environment of a frame that is not directly below the stack frame for `Kernel#binding`. I've known that C extensions have this [privilege] for a while, but didn't realize that it was also possible using only the core library. This is a powerful primitive that allows for some funky programs: ```ruby def lookup(hash, key) hash[key] hash end p lookup( Hash.new(&( Kernel.instance_method(:send).method(:bind_call).to_proc >> ->(binding) { binding.local_variable_set(:hash, :action_at_a_distance!) } ) ), :binding ) # => :action_at_a_distance! ``` There might be ways to compose core library procs such that it's less contrived and more useful, but I couldn't figure out a way to do it. Maybe there is a way to make a "local variable set" proc that takes only a name-value pair and no block? ### What's the big deal? This behavior makes the implementation language of methods part of the API surface for `Kernel#binding`. In other words, merely changing a Ruby method to be a C method can be a breaking change for the purposes of `Kernel#binding`, even if the method behaves the same in all other observable ways. I feel that whether a method is native or not should be an implementation detail and should not impact `Kernel#binding`. This is a problem for Ruby implementations that want to implement many core methods in Ruby, because they risk breaking compatibility with CRuby. TruffleRuby has this [problem][privilege] as I alluded to earlier, and CRuby risks making unintentional breaking changes as more methods change to become Ruby methods in the core library. ### Leaking less details I think a straight forward way to fix this issue is by making it so that `Kernel#binding` only ever looks at the stack frame directly below it. If the frame below is a not a Ruby frame, it can return an empty binding. I haven't done the leg work of figuring out how hard this would be to implement in CRuby, though. This new behavior allows observing the identity of native frames, which is new. ### Does the more restrictive behavior help YJIT? Maybe. It's hard to tell without building out more optimizations that are related to local variables. YJIT currently doesn't do much in that area. If I had to guess I wouuld say the more restrictive semantics at least open up the possibility of some deoptimization strategies that are more memory efficient. ### What do you think? This is not a huge issue, but it might be nice to start thinking about for the next release. If a lot of people actually rely on the current behavior we can provide a migration plan. Since it might take years to land, I would like to solicit feedback now. [discovered]: https://github.com/ruby/ruby/commit/54c91042ed61a869d4a66fc089b21f56d165265f [privilege]: https://github.com/oracle/truffleruby/issues/2171 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111526] [Ruby master Bug#19288] Ractor JSON parsing significantly slower than linear parsing
by maciej.mensfeld (Maciej Mensfeld) 08 Sep '25

08 Sep '25

Issue #19288 has been reported by maciej.mensfeld (Maciej Mensfeld). ---------------------------------------- Bug #19288: Ractor JSON parsing significantly slower than linear parsing https://bugs.ruby-lang.org/issues/19288 * Author: maciej.mensfeld (Maciej Mensfeld) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- a simple benchmark: ```ruby require 'json' require 'benchmark' CONCURRENT = 5 RACTORS = true ELEMENTS = 100_000 data = CONCURRENT.times.map do ELEMENTS.times.map do { rand => rand, rand => rand, rand => rand, rand => rand }.to_json end end ractors = CONCURRENT.times.map do Ractor.new do Ractor.receive.each { JSON.parse(_1) } end end result = Benchmark.measure do if RACTORS CONCURRENT.times do |i| ractors[i].send(data[i], move: false) end ractors.each(&:take) else # Linear without any threads data.each do |piece| piece.each { JSON.parse(_1) } end end end puts result ``` Gives following results on my 8 core machine: ```shell # without ractors: 2.731748 0.003993 2.735741 ( 2.736349) # with ractors 12.580452 5.089802 17.670254 ( 5.209755) ``` I would expect Ractors not to be two times slower on the CPU intense work. -- https://bugs.ruby-lang.org/

9 23

[ruby-core:123180] [Ruby Bug#21563] Misleading error message when `to_proc` does not return a Proc in an Object used as a &block argument
by soulcutter (Bradley Schaefer) 06 Sep '25

06 Sep '25

Issue #21563 has been reported by soulcutter (Bradley Schaefer). ---------------------------------------- Bug #21563: Misleading error message when `to_proc` does not return a Proc in an Object used as a &block argument https://bugs.ruby-lang.org/issues/21563 * Author: soulcutter (Bradley Schaefer) * Status: Open * ruby -v: ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When a class implements `#to_proc` it should always return a Proc. Nonetheless bugs are possible, and when an implementation returns something else, and is used as a block argument to a method, you get an error that claims that the argument type is the implementing class rather than the type that was returned from `to_proc`. Reproduction ``` class SayHi def call = "hi" def to_proc = "obviously not a proc" end def callablock(&block) = block.call callablock &SayHi.new # wrong argument type SayHi (expected Proc) (TypeError) ``` In real-world code it may not be _this_ obvious that `to_proc` is returning the wrong type, and so I would expect the error would report the type of object returned by `to_proc` so that you have a more-direct path to understanding the misbehavior. In this case I would expect: wrong argument type String (expected Proc) Or maybe something more-descriptive as an error message, but I don't have a concrete suggestion for that. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123176] [Ruby Bug#21562] IO#each_codepoint raises using with IO#ungetc
by YO4 (Yoshinao Muramatsu) 06 Sep '25

06 Sep '25

Issue #21562 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21562: IO#each_codepoint raises using with IO#ungetc https://bugs.ruby-lang.org/issues/21562 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * ruby -v: ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [x64-mingw-ucrt] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Using IO#each_codepoint together with IO#ungetc causes ```byte oriented read for character buffered IO (IOError)``` when encoding conversion is active. ``` C:\>ruby -e "open('NUL', 'rt') { _1.ungetc('aa'); _1.each_codepoint { |c| p c }}" 97 -e:1:in 'IO#each_codepoint': byte oriented read for character buffered IO (IOError) from -e:1:in 'block in <main>' from -e:1:in 'Kernel#open' from -e:1:in '<main>' ``` note: 'rt' enables newline conversion for input, and it uses the encoding conversion mechanism. When encoding conversion is not used, similar operations complete successfully. ``` C:\>ruby -e "open('NUL', 'rb') { _1.ungetc('aa'); _1.each_codepoint { |c| p c }}" 97 97 ``` Since both IO#each_codepoint and IO#ungetc handle characters, I believe IO#each_codepoint should work on both cases. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:122932] [Ruby Bug#21534] ppc64le Ractor ractor_port_receive aborted (core dumped)
by jaruga (Jun Aruga) 04 Sep '25

04 Sep '25

Issue #21534 has been reported by jaruga (Jun Aruga). ---------------------------------------- Bug #21534: ppc64le Ractor ractor_port_receive aborted (core dumped) https://bugs.ruby-lang.org/issues/21534 * Author: jaruga (Jun Aruga) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I am seeing the following errors in the Ubuntu 24.04 noble server "Ubuntu (ppc64le)" on RubyCI on the relatively latest master branch commit `f3206cc79bec2fd852e81ec56de59f0a67ab32b7`. Originally I found the errors at <https://github.com/ruby/ruby/pull/13972#issuecomment-3160768404>. ## Reproducing the errors ``` $ grep ^VERSION /etc/os-release VERSION_ID="24.04" VERSION="24.04.3 LTS (Noble Numbat)" VERSION_CODENAME=noble $ uname -m ppc64le $ uname -r 6.8.0-71-generic ``` ``` $ pwd /home/jaruga/git/ruby/ruby ``` The following `configure` script's options comes from the `.github/workflows/ubuntu.yml`. https://github.com/ruby/ruby/blob/24d0b458cd6ccde1e052c1db15af120def349693/… ``` $ ./autogen.sh $ ./configure -C --disable-install-doc cppflags=-DRUBY_DEBUG $ make -j4 ``` Then the 2 assertions in the following tests always fail. ``` $ make btest BTESTS=bootstraptest/test_ractor.rb ... FAIL 2/147 tests failed make: *** [uncommon.mk:913: yes-btest] Error 1 $ make btest-ruby BTESTS=bootstraptest/test_ractor.rb FAIL 2/145 tests failed make: *** [uncommon.mk:921: yes-btest-ruby] Error 1 ... ``` And the `test_ractor_1.rb` is a minimal reproducer so far I found for the 1st failing assertion. ``` $ cat test_ractor_1.rb # Ractor.count counts = [] counts << Ractor.count p counts.inspect ractors = (1..2).map { Ractor.new { Ractor.receive } } counts << Ractor.count p counts.inspect ractors[0].send('End 0').join sleep 0.1 until ractors[0].inspect =~ /terminated/ counts << Ractor.count p counts.inspect ractors[1].send('End 1').join sleep 0.1 until ractors[1].inspect =~ /terminated/ counts << Ractor.count p counts.inspect ``` Then the following test fails once in 2 or 3 times. Below is a passing case. ``` $ make run TESTRUN_SCRIPT=test_ractor_1.rb ./miniruby -I./lib -I. -I.ext/common -r./powerpc64le-linux-fake test_ractor_1.rb "[1]" test_ractor_1.rb:6: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. "[1, 3]" "[1, 3, 2]" "[1, 3, 2, 1]" ``` Below is a failing (aborting) case. ``` $ make run TESTRUN_SCRIPT=test_ractor_1.rb ./miniruby -I./lib -I. -I.ext/common -r./powerpc64le-linux-fake test_ractor_1.rb "[1]" test_ractor_1.rb:6: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. "[1, 3]" vm_core.h:2017: Assertion Failed: rb_current_execution_context:ec == rb_current_ec_noinline() ruby 3.5.0dev (2025-08-06T15:07:49Z master f3206cc79b) +PRISM [powerpc64le-linux] -- Control frame information ----------------------------------------------- c:0004 p:0003 s:0014 e:000013 METHOD <internal:ractor>:667 c:0003 p:0008 s:0010 e:000009 METHOD <internal:ractor>:313 c:0002 p:0004 s:0006 e:000005 BLOCK test_ractor_1.rb:6 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- test_ractor_1.rb:6:in 'block (2 levels) in <main>' <internal:ractor>:313:in 'receive' <internal:ractor>:667:in 'receive' -- Threading information --------------------------------------------------- Total ractor count: 3 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /home/jaruga/git/ruby/ruby/miniruby(rb_print_backtrace+0x8) [0x10a262075e10] vm_dump.c:843 /home/jaruga/git/ruby/ruby/miniruby(rb_vm_bugreport) vm_dump.c:1175 /home/jaruga/git/ruby/ruby/miniruby(rb_assert_failure_detail+0x12c) [0x10a261c62aa0] error.c:1215 /home/jaruga/git/ruby/ruby/miniruby(rb_assert_failure+0x1c) [0x10a261c62ae0] error.c:1191 /home/jaruga/git/ruby/ruby/miniruby(rb_current_execution_context+0x34) [0x10a261c66574] vm_core.h:2017 /home/jaruga/git/ruby/ruby/miniruby(ractor_basket_value+0x0) [0x10a261ee2720] ractor_sync.c:826 /home/jaruga/git/ruby/ruby/miniruby(ractor_basket_accept) ractor_sync.c:833 /home/jaruga/git/ruby/ruby/miniruby(ractor_try_receive) ractor_sync.c:1144 /home/jaruga/git/ruby/ruby/miniruby(ractor_receive) ractor_sync.c:1160 /home/jaruga/git/ruby/ruby/miniruby(ractor_port_receive) ractor_sync.c:142 /home/jaruga/git/ruby/ruby/miniruby(builtin_invoker0+0x24) [0x10a26201c3f4] vm_insnhelper.c:7344 /home/jaruga/git/ruby/ruby/miniruby(invoke_bf+0x128) [0x10a26202d968] vm_insnhelper.c:7485 /home/jaruga/git/ruby/ruby/miniruby(vm_invoke_builtin_delegate+0x1c) [0x10a262059e08] vm_insnhelper.c:7509 /home/jaruga/git/ruby/ruby/miniruby(vm_exec_core) insns.def:1698 /home/jaruga/git/ruby/ruby/miniruby(vm_exec_loop+0x0) [0x10a26204af08] vm.c:2621 /home/jaruga/git/ruby/ruby/miniruby(rb_vm_exec) vm.c:2624 /home/jaruga/git/ruby/ruby/miniruby(thread_do_start_proc+0x394) [0x10a261fd6154] thread.c:584 /home/jaruga/git/ruby/ruby/miniruby(thread_do_start+0x8) [0x10a261fd68c8] thread.c:626 /home/jaruga/git/ruby/ruby/miniruby(thread_start_func_2) thread.c:677 /home/jaruga/git/ruby/ruby/miniruby(thread_sched_lock_+0x0) [0x10a261fd7104] thread_pthread.c:2237 /home/jaruga/git/ruby/ruby/miniruby(co_start) thread_pthread_mn.c:460 /home/jaruga/git/ruby/ruby/miniruby(co_start+0x8) [0x10a261fd7028] thread_pthread_mn.c:439 -- Other runtime information ----------------------------------------------- * Loaded script: test_ractor_1.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 pathname.so 6 ruby2_keywords.rb 7 set.rb 8 /home/jaruga/git/ruby/ruby/powerpc64le-linux-fake.rb * Process memory map: 10a261c30000-10a2622d0000 r-xp 00000000 08:01 1279300 /home/jaruga/git/ruby/ruby/miniruby 10a2622d0000-10a2622e0000 r--p 00690000 08:01 1279300 /home/jaruga/git/ruby/ruby/miniruby 10a2622e0000-10a2622f0000 rw-p 006a0000 08:01 1279300 /home/jaruga/git/ruby/ruby/miniruby 10a2622f0000-10a262300000 rw-p 00000000 00:00 0 10a279e90000-10a27a030000 rw-p 00000000 00:00 0 [heap] 68d2b0000000-68d2b0030000 rw-p 00000000 00:00 0 68d2b0030000-68d2b4000000 ---p 00000000 00:00 0 68d2b8000000-68d2b8030000 rw-p 00000000 00:00 0 68d2b8030000-68d2bc000000 ---p 00000000 00:00 0 68d2bc6f0000-68d2bc700000 ---p 00000000 00:00 0 68d2bc700000-68d2bc800000 rw-p 00000000 00:00 0 68d2bc800000-68d2bc910000 rw-p 00000000 00:00 0 [anon:Ruby:nt_alloc_thread_stack_chunk] 68d2bc910000-68d2bc920000 ---p 00000000 00:00 0 [anon:Ruby:nt_alloc_thread_stack_chunk] 68d2bc920000-68d2bcb20000 rw-p 00000000 00:00 0 [anon:Ruby:nt_alloc_thread_stack_chunk] 68d2bcb20000-68d2bcb30000 ---p 00000000 00:00 0 [anon:Ruby:nt_alloc_thread_stack_chunk] 68d2bcb30000-68d2dc800000 rw-p 00000000 00:00 0 [anon:Ruby:nt_alloc_thread_stack_chunk] 68d2dc800000-68d2dc810000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dc810000-68d2dc8c0000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dc8c0000-68d2dc8d0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dc8d0000-68d2dc980000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dc980000-68d2dc990000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dc990000-68d2dca40000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dca40000-68d2dca50000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dca50000-68d2dcb00000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcb00000-68d2dcb10000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcb10000-68d2dcbc0000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcbc0000-68d2dcbd0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcbd0000-68d2dcc80000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcc80000-68d2dcc90000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcc90000-68d2dcd40000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcd40000-68d2dcd50000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcd50000-68d2dce00000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dce00000-68d2dce10000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dce10000-68d2dcec0000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcec0000-68d2dced0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dced0000-68d2dcf80000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcf80000-68d2dcf90000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcf90000-68d2dd040000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd040000-68d2dd050000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd050000-68d2dd100000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd100000-68d2dd110000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd110000-68d2dd1c0000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd1c0000-68d2dd1d0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd1d0000-68d2dd280000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd280000-68d2dd290000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd290000-68d2dd340000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd340000-68d2dd350000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd350000-68d2dd400000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd400000-68d2dd410000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd410000-68d2dd4c0000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd4c0000-68d2dd4d0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd4d0000-68d2dd580000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd580000-68d2dd590000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd590000-68d2dd640000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd640000-68d2dd650000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd650000-68d2dd700000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd700000-68d2dd710000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd710000-68d2dd7c0000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd7c0000-68d2dd7d0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd7d0000-68d2dd880000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd880000-68d2dd890000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd890000-68d2dd940000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd940000-68d2dd950000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd950000-68d2dda00000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dda00000-68d2dda10000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dda10000-68d2ddac0000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddac0000-68d2ddad0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddad0000-68d2ddb80000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddb80000-68d2ddb90000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddb90000-68d2ddc40000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddc40000-68d2ddc50000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddc50000-68d2ddd00000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddd00000-68d2ddd10000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddd10000-68d2dddc0000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dddc0000-68d2dddd0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dddd0000-68d2dde80000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dde80000-68d2dde90000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dde90000-68d2ddf40000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddf40000-68d2ddf50000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddf50000-68d2de000000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2de040000-68d2de060000 r-xp 00000000 08:01 13327 /usr/lib/powerpc64le-linux-gnu/libgcc_s.so.1 68d2de060000-68d2de070000 r--p 00010000 08:01 13327 /usr/lib/powerpc64le-linux-gnu/libgcc_s.so.1 68d2de070000-68d2de080000 rw-p 00020000 08:01 13327 /usr/lib/powerpc64le-linux-gnu/libgcc_s.so.1 68d2de080000-68d2de0b0000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] 68d2de0b0000-68d2de0c0000 ---p 00000000 00:00 0 68d2de0c0000-68d2de1c0000 rw-p 00000000 00:00 0 68d2de1c0000-68d2de1f0000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] 68d2de1f0000-68d2de200000 ---p 00000000 00:00 0 68d2de200000-68d2dea00000 rw-p 00000000 00:00 0 68d2dea00000-68d2f6a00000 rw-p 00000000 00:00 0 [anon:Ruby:Init_default_shapes:shape_cache] 68d2f6a00000-68d2f7e00000 rw-p 00000000 00:00 0 [anon:Ruby:Init_default_shapes:shape_list] 68d2f7e00000-68d2f80f0000 r--p 00000000 08:01 5476 /usr/lib/locale/locale-archive 68d2f80f0000-68d2f8200000 rw-p 00000000 00:00 0 68d2f8200000-68d2f8460000 r-xp 00000000 08:01 25968 /usr/lib/powerpc64le-linux-gnu/libc.so.6 68d2f8460000-68d2f8470000 r--p 00260000 08:01 25968 /usr/lib/powerpc64le-linux-gnu/libc.so.6 68d2f8470000-68d2f8480000 rw-p 00270000 08:01 25968 /usr/lib/powerpc64le-linux-gnu/libc.so.6 68d2f8490000-68d2f84c0000 rw-p 00000000 00:00 0 68d2f84c0000-68d2f84d0000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] 68d2f84e0000-68d2f8550000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] 68d2f8550000-68d2f85b0000 r--p 00000000 08:01 26004 /usr/lib/locale/C.utf8/LC_CTYPE 68d2f85b0000-68d2f86e0000 r-xp 00000000 08:01 25971 /usr/lib/powerpc64le-linux-gnu/libm.so.6 68d2f86e0000-68d2f86f0000 r--p 00130000 08:01 25971 /usr/lib/powerpc64le-linux-gnu/libm.so.6 68d2f86f0000-68d2f8700000 rw-p 00140000 08:01 25971 /usr/lib/powerpc64le-linux-gnu/libm.so.6 68d2f8700000-68d2f8740000 r-xp 00000000 08:01 5029 /usr/lib/powerpc64le-linux-gnu/libcrypt.so.1.1.0 68d2f8740000-68d2f8750000 r--p 00030000 08:01 5029 /usr/lib/powerpc64le-linux-gnu/libcrypt.so.1.1.0 68d2f8750000-68d2f8760000 rw-p 00040000 08:01 5029 /usr/lib/powerpc64le-linux-gnu/libcrypt.so.1.1.0 68d2f8760000-68d2f8800000 r-xp 00000000 08:01 27939 /usr/lib/powerpc64le-linux-gnu/libgmp.so.10.5.0 68d2f8800000-68d2f8810000 r--p 00090000 08:01 27939 /usr/lib/powerpc64le-linux-gnu/libgmp.so.10.5.0 68d2f8810000-68d2f8820000 rw-p 000a0000 08:01 27939 /usr/lib/powerpc64le-linux-gnu/libgmp.so.10.5.0 68d2f8820000-68d2f8850000 r-xp 00000000 08:01 23504 /usr/lib/powerpc64le-linux-gnu/libz.so.1.3 68d2f8850000-68d2f8860000 r--p 00020000 08:01 23504 /usr/lib/powerpc64le-linux-gnu/libz.so.1.3 68d2f8860000-68d2f8870000 rw-p 00030000 08:01 23504 /usr/lib/powerpc64le-linux-gnu/libz.so.1.3 68d2f8870000-68d2f8880000 r--s 00000000 08:01 25957 /usr/lib/powerpc64le-linux-gnu/gconv/gconv-modules.cache 68d2f8880000-68d2f88a0000 r--p 00000000 00:00 0 [vvar] 68d2f88a0000-68d2f88b0000 r-xp 00000000 00:00 0 [vdso] 68d2f88b0000-68d2f8900000 r-xp 00000000 08:01 25965 /usr/lib/powerpc64le-linux-gnu/ld64.so.2 68d2f8900000-68d2f8910000 r--p 00040000 08:01 25965 /usr/lib/powerpc64le-linux-gnu/ld64.so.2 68d2f8910000-68d2f8920000 rw-p 00050000 08:01 25965 /usr/lib/powerpc64le-linux-gnu/ld64.so.2 7fffe3520000-7fffe3550000 rw-p 00000000 00:00 0 [stack] make: *** [uncommon.mk:1430: run] Aborted (core dumped) ``` ## Debugging on gdb ``` $ make gdb TESTRUN_SCRIPT=test_ractor_1.rb gdb -x run.gdb --quiet --args ./miniruby -I./lib -I. -I.ext/common test_ractor_1.rb Reading symbols from ./miniruby... warning: File "/home/jaruga/git/ruby/ruby/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /home/jaruga/git/ruby/ruby/.gdbinit line to your configuration file "/home/jaruga/.config/gdb/gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/jaruga/.config/gdb/gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" Breakpoint 1 at 0x32acc: file error.c, line 1190. Breakpoint 2 at 0x32d30: file error.c, line 1112. Breakpoint 3 at 0x108820: file debug.c, line 168. warning: ./breakpoints.gdb: No such file or directory This GDB supports auto-downloading debuginfo from the following URLs: <https://debuginfod.ubuntu.com> Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal] Debuginfod has been disabled. To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1". [New Thread 0x7fffddfff100 (LWP 3470199)] "[1]" test_ractor_1.rb:6: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. [New Thread 0x7fffdd7ef100 (LWP 3470200)] [New Thread 0x7fffbbdff100 (LWP 3470201)] "[1, 3]" "[1, 3, 2]" [Switching to Thread 0x7fffbbdff100 (LWP 3470201)] Thread 4 "miniruby" hit Breakpoint 1, 0x0000000100032acc in rb_assert_failure ( file=file@entry=0x100514e48 "vm_core.h", line=line@entry=2017, name=name@entry=0x100573a28 <__func__.2> "rb_current_execution_context", expr=expr@entry=0x10050f5e0 "ec == rb_current_ec_noinline()") at error.c:1190 1190 { (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/jaruga/git/ruby/ruby/miniruby -I./lib -I. -I.ext/common test_ractor_1.rb [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1". [New Thread 0x7fffddfff100 (LWP 3470207)] "[1]" test_ractor_1.rb:6: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. [New Thread 0x7fffdd7ef100 (LWP 3470208)] [New Thread 0x7fffbbdff100 (LWP 3470209)] "[1, 3]" "[1, 3, 2]" [Switching to Thread 0x7fffbbdff100 (LWP 3470209)] Thread 4 "miniruby" hit Breakpoint 1, 0x0000000100032acc in rb_assert_failure ( file=file@entry=0x100514e48 "vm_core.h", line=line@entry=2017, name=name@entry=0x100573a28 <__func__.2> "rb_current_execution_context", expr=expr@entry=0x10050f5e0 "ec == rb_current_ec_noinline()") at error.c:1190 1190 { ``` ``` (gdb) bt #0 0x0000000100032acc in rb_assert_failure (file=file@entry=0x100514e48 "vm_core.h", line=line@entry=2017, name=name@entry=0x100573a28 <__func__.2> "rb_current_execution_context", expr=expr@entry=0x10050f5e0 "ec == rb_current_ec_noinline()") at error.c:1190 #1 0x0000000100036574 in rb_current_execution_context (expect_ec=true) at vm_core.h:2017 #2 0x00000001002b2720 in rb_current_execution_context (expect_ec=true) at ractor_sync.c:826 #3 rb_current_ractor_raw (expect=true) at vm_core.h:2039 #4 rb_current_ractor_raw (expect=<optimized out>) at vm_core.h:2033 #5 rb_current_ractor () at vm_core.h:2047 #6 rb_current_ractor () at vm_core.h:2045 #7 ractor_queue_deq (rq=0x10082d680, r=<optimized out>) at ractor_sync.c:339 #8 ractor_try_receive (ec=0x10080ed30, rp=<optimized out>, cr=<optimized out>) at ractor_sync.c:1137 #9 ractor_receive (rp=<optimized out>, ec=<optimized out>) at ractor_sync.c:1160 #10 ractor_port_receive (ec=0x10080ed30, ec@entry=<error reading variable: value has been optimized out>, self=<error reading variable: value has been optimized out>) at ractor_sync.c:142 #11 0x00000001003ec3f4 in builtin_invoker0 (ec=<optimized out>, self=<optimized out>, argv=<optimized out>, funcptr=<optimized out>) at vm_insnhelper.c:7344 #12 0x00000001003fd968 in invoke_bf (ec=0x10080ed30, reg_cfp=0x7fffbc11ff20, bf=0x1006a9678 <ractor_table+552>, argv=0x0) at vm_insnhelper.c:7485 #13 0x0000000100429e08 in vm_invoke_builtin_delegate (start_index=<optimized out>, bf=<optimized out>, cfp=<optimized out>, ec=<optimized out>) at vm_insnhelper.c:7509 #14 vm_exec_core (ec=0x10080ed30) at insns.def:1698 #15 0x000000010041af08 in rb_vm_exec (ec=0x10080ed30) at vm.c:2621 #16 0x00000001003a6154 in thread_do_start_proc (th=th@entry=0x10082d6a0) at thread.c:584 #17 0x00000001003a68c8 in thread_do_start (th=0x10082d6a0) at thread.c:626 #18 thread_start_func_2 (th=th@entry=0x10082d6a0, stack_start=<optimized out>) at thread.c:677 #19 0x00000001003a7104 in call_thread_start_func_2 (th=<optimized out>) at thread_pthread.c:2237 #20 co_start (from=<optimized out>, self=0x10082d960) at thread_pthread_mn.c:458 Backtrace stopped: previous frame identical to this frame (corrupt stack?) ``` In the stacktrace info, the ractor_sync.c:142 is below. https://github.com/ruby/ruby/blob/f3206cc79bec2fd852e81ec56de59f0a67ab32b7/… The ractor_sync.c:826 is below. https://github.com/ruby/ruby/blob/f3206cc79bec2fd852e81ec56de59f0a67ab32b7/… ## RubyCI Ubuntu (ppc64le) passing Interestingly, it seems that this core dump doesn't happen on the RubyCI Ubuntu (ppc64le) server, for example on the following log. I don't know why this core dump doesn't happen on the server. https://rubyci.s3.amazonaws.com/ppc64le/ruby-master/log/20250807T130006Z.lo… -- https://bugs.ruby-lang.org/

2 11

[ruby-core:123173] ‍
by Voicemail 03 Sep '25

03 Sep '25

1 0