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

[ruby-core:122953] [Ruby Bug#21540] prism allows `foo && return bar` when parse.y doesn't
by Earlopain (Earlopain _) 12 Aug '25

12 Aug '25

Issue #21540 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21540: prism allows `foo && return bar` when parse.y doesn't https://bugs.ruby-lang.org/issues/21540 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 3.5.0dev (2025-08-08T02:57:23Z master 3ad26d0501) [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Code such as `foo && return bar` has been disallowed in ruby since at least Ruby 2.0. Prism allows it though: ``` $ ruby -cve "a && return foo" ruby 3.5.0dev (2025-08-08T02:57:23Z master 3ad26d0501) +PRISM [x86_64-linux] Syntax OK $ ruby --parser=parse.y -cve "a && return foo" ruby 3.5.0dev (2025-08-08T02:57:23Z master 3ad26d0501) [x86_64-linux] -e:1: syntax error, unexpected local variable or method, expecting end-of-input a && return foo ruby: compile error (SyntaxError) ``` The code seems to behave like I'd expect it to and I wouldn't mind it being accepted but it is inconsistent. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120873] [Ruby master Bug#21111] RbConfig::CONFIG['CXX'] quietly set to "false" when Ruby cannot build C++ programs
by stanhu (Stan Hu) 12 Aug '25

12 Aug '25

Issue #21111 has been reported by stanhu (Stan Hu). ---------------------------------------- Bug #21111: RbConfig::CONFIG['CXX'] quietly set to "false" when Ruby cannot build C++ programs https://bugs.ruby-lang.org/issues/21111 * Author: stanhu (Stan Hu) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- As reported in https://gitlab.com/gitlab-org/gitlab-development-kit/-/issues/2222 and https://trac.macports.org/ticket/70750, we've had numerous macOS users experience problems with compiling Ruby C++ extensions after upgrading to XCode 16. Users have had to fix their XCode setups and reinstall Ruby when this happens. It turns out that when Ruby can't build a CXX program, it essentially sets CXX to the `false` string. From https://github.com/ruby/ruby/blob/7317f96727725ca37ddb06011918deb841de371c/…: ``` AS_IF([test -n "${rb_there_is_in_fact_no_gplusplus_but_autoconf_is_cheating_us}"], [ AC_MSG_NOTICE([Test skipped due to lack of a C++ compiler.]) ], [test -n "${CXX}"], [ RUBY_WERROR_FLAG([ AC_MSG_CHECKING([whether CXXFLAGS is valid]) AC_LANG_PUSH(C++) AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[@%:@include <cstdio>]], [[]])], [AC_MSG_RESULT(yes)],[ AC_MSG_RESULT(no) # The message mentions CXXFLAGS, but CPPFLAGS might also affects. AC_MSG_WARN([something wrong with CXXFLAGS="$CXXFLAGS"]) CXX=false ``` This causes C++ extensions, such as `unf_ext`, to fail while attempting to compile native extensions. There are no error messages because `false` is executed, so users only see: ``` Installing unf_ext 0.0.8.2 with native extensions Gem::Ext::BuildError: ERROR: Failed to build gem native extension. current directory: /Users/myuser/.rvm/gems/ruby-3.3.7/gems/unf_ext-0.0.8.2/ext/unf_ext /Users/kerrizor/.rvm/rubies/ruby-3.3.7/bin/ruby extconf.rb checking for -lstdc++... yes creating Makefile current directory: /Users/myuser/.rvm/gems/ruby-3.3.7/gems/unf_ext-0.0.8.2/ext/unf_ext make DESTDIR\= sitearchdir\=./.gem.20250203-69237-u2oi17 sitelibdir\=./.gem.20250203-69237-u2oi17 clean current directory: /Users/myuser/.rvm/gems/ruby-3.3.7/gems/unf_ext-0.0.8.2/ext/unf_ext make DESTDIR\= sitearchdir\=./.gem.20250203-69237-u2oi17 sitelibdir\=./.gem.20250203-69237-u2oi17 compiling unf.cc make: *** [unf.o] Error 1 ``` `unf_ext` only checks whether `RbConfig::CONFIG['CXX']` is defined, not that it is `false`: https://github.com/knu/ruby-unf_ext/blob/c72a36d0a5ea9fe3950611b0f289fc68a2…. Questions: 1. Should CXX just be set to `nil`? Or should all C++ extensions be expected to check for `false`? The latter seems surprising to me. 2. Should there be a way to fail the Ruby build if a valid C++ compiler is not found? -- https://bugs.ruby-lang.org/

6 7

[ruby-core:122951] [Ruby Feature#17316] On memoization
by Dan0042 (Daniel DeLorme) 11 Aug '25

11 Aug '25

Issue #17316 has been updated by Dan0042 (Daniel DeLorme). marksiemers (Mark Siemers) wrote in #note-12: > A big motivation for this comes from a recent change to rubocop-rails, which is now enforcing "Rails/FindByOrAssignmentMemoization" (see: https://rails.rubystyle.guide/\#find-by-memoization) > > A more rails-specific example below of this proposal: > ```ruby > # Previously allowed (though not performant in the case of nil returned by find_by) > def foo > @foo ||= Foo.find_by(id:) > end > > # The new rule enforces this syntax > def foo > if instance_variable_defined?(:@foo) > @foo > else > @foo = Foo.find_by(id:) > end > end > ``` This is appalling. If "best practices" are going to encourage this kind of un-ruby-ish horror, this memoization issue is more urgent to solve than I had expected. Personally I prefer a DSL like `memo def foo` but this `@||=` idea is pretty interesting in how it communicates this is a syntax that applies to instance variables. ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114255 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- I have seen so many attempts to memoize a value in the form: ```ruby @foo ||= some_heavy_calculation(...) ``` improperly, i.e., even when the value can potentially be falsy. This practice is wide spread, and since in most cases memoization is about efficiency and it would not be critical if it does not work correctly, people do not seem to care so much about correcting the wrong usage. In such case, the correct form would be: ```ruby unless instance_variable_defined?(:@foo) @foo = some_heavy_calculation(...) end ``` but this looks too long, and perhaps that is keeping people away from using it. What about allowing `Kernel#instance_variable_set` to take a block instead of the second argument, in which case the assignment should be done only when the instance variable is not defined? ```ruby instance_variable_set(:@foo){some_heavy_calculation(...)} ``` Or, if that does not look right or seems to depart from the original usage of `instance_variable_set`, then what about having a new method? ```ruby memoize(:foo){some_heavy_calculation(...)} ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121136] [Ruby master Bug#21151] IO and StringIO raise FrozenError even for read-only methods
by headius (Charles Nutter) 11 Aug '25

11 Aug '25

Issue #21151 has been reported by headius (Charles Nutter). ---------------------------------------- Bug #21151: IO and StringIO raise FrozenError even for read-only methods https://bugs.ruby-lang.org/issues/21151 * Author: headius (Charles Nutter) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Problem -------- While fixing a small [regression](https://github.com/ruby/stringio/issues/119) from my recent StringIO [fixes](https://github.com/ruby/stringio/issues/116) I discovered that a large number of read-only methods will fail if the StringIO is frozen. A few examples: ``` $ ruby -rstringio -e 's = StringIO.new; p s.lineno; s.freeze; p s.lineno' 0 -e:1:in 'StringIO#lineno': can't modify frozen StringIO: #<StringIO:0x0000000103711ea8> (FrozenError) from -e:1:in '<main>' $ ruby -rstringio -e 's = StringIO.new; p s.closed?; s.freeze; p s.closed?' false -e:1:in 'StringIO#closed?': can't modify frozen StringIO: #<StringIO:0x00000001008c1e68> (FrozenError) from -e:1:in '<main>' $ ruby -rstringio -e 's = StringIO.new; p s.eof?; s.freeze; p s.eof?' true -e:1:in 'StringIO#eof?': can't modify frozen StringIO: #<StringIO:0x000000011c171e80> (FrozenError) from -e:1:in '<main>' $ ruby -rstringio -e 's = StringIO.new; p s.pos; s.freeze; p s.pos' 0 -e:1:in 'StringIO#pos': can't modify frozen StringIO: #<StringIO:0x0000000105551df0> (FrozenError) from -e:1:in '<main>' ``` @kou pointed out that IO also raises for at least `lineno` and suggested I re-open the issue here. I still believe these read-only operations should be allowed on frozen IO or StringIO. Cause in StringIO ----------------- This is because the `StringIO` macro calls `get_strio` which calls `rb_io_taint_check` which calls `rb_check_frozen`. The `StringIO` macro is used in almost every method to access the rb_stringio_t data structure. A list of methods I believe should be operable when the StringIO is frozen (in stringio.c definition order): * string (returns underlying String but does not mutate anything) * lineno * pos * closed?/closed_read?/closed_write? * eof/eof? * sync * pid (a dummy method but it writes nothing) * fileno (dummy) * pread (by definition does not modify state) * isatty/tty? * size/length * external_encoding * internal_encoding In addition, `initialize_copy` probably should not require the original StringIO to be writable: ``` $ ruby -rstringio -e 's = StringIO.new("foo"); s.freeze; p s.dup' -e:1:in 'StringIO#initialize_copy': can't modify frozen StringIO: #<StringIO:0x0000000102eb1df8> (FrozenError) from -e:1:in 'Kernel#initialize_dup' from -e:1:in 'Kernel#dup' from -e:1:in '<main>' ``` The data from the original StringIO is unmodified by `initialize_copy`, other than the reference-counting `ptr->count` (which should not be subject to frozen checks). Cause in IO ----------- The `GetOpenFile` macro calls `RB_IO_POINTER` macro which calls `rb_io_taint_check` which calls `rb_check_frozen`. Methods in IO that should work on a frozen IO include any of the above StringIO that currently raise. For example `lineno` uses `GetOpenFile`, but `fileno` does not and does not raise. There's clearly some inconsistency here we can clean up. Origin ------ I believe most of the StringIO cases are caused by this change from 2011 that added frozen checks to StringIO (the class and the macro): https://github.com/ruby/ruby/commit/d8d9bac5c8b071135e50ad3f21c8a9b6a9c06e54 In IO, this behavior dates way back to 2000 by @matz himself: https://github.com/ruby/ruby/commit/087c83d7ceed6893afff93066937fb570ae4a115 Notes ----- I have started to fix the StringIO cases for JRuby in https://github.com/ruby/stringio/pull/122. I could probably fix the C version of StringIO as well, but I'm a little more unsure about how to fix IO. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:122948] [Ruby Feature#17316] On memoization
by marksiemers (Mark Siemers) 11 Aug '25

11 Aug '25

Issue #17316 has been updated by marksiemers (Mark Siemers). I agree with Sebastian that an operator is the best way to keep this code elegant. My proposal is to: **Introduce a new operator `@||` that does instance variable aware memoization succinctly** ```ruby # Allow this syntax def result @result @||= expensive_calculation end # As functionally equivalent to this def result if instance_variable_defined?(:@result) @result else @result = expensive_calculation end end ``` Reasons for this suggestion: 1. `@|` is already not valid syntax, so there should not be any issue with breaking legacy code 2. Use of the `@` symbol is a strong indicator that this impacts and is useful for instance variables 3. Keeping the `||` as part of the operator is familiar syntax for memoization 4. It is succinct, keeps things on one line, adds only one character, does not require blocks or method calls on separate lines (e.g. `memoize(:result)`) 5. If searching for memoization in the codebase - searching for `||=` will still work --- A big motivation for this comes from a recent change to rubocop-rails, which is now enforcing "Rails/FindByOrAssignmentMemoization" (see: https://rails.rubystyle.guide/\#find-by-memoization) A more rails-specific example below of this proposal: ```ruby # Previously allowed (though not performant in the case of nil returned by find_by def foo @foo ||= Foo.find_by(id:) end # The new rule enforces this syntax def foo if instance_variable_defined?(:@foo) @foo else @foo = Foo.find_by(id:) end end ``` Here's my main proposal with some reasons behind it: ```ruby def foo @foo @||= Foo.find_by(id:) end ``` --- Here are some other ideas, but I don't think any of them are as good as `@||`: ```ruby @result |||= expensive_calculation @result -||= expensive_calculation @result +||= expensive_calculation @result _||= expensive_calculation @result &||= expensive_calculation @result %||= expensive_calculation ``` ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114252 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- I have seen so many attempts to memoize a value in the form: ```ruby @foo ||= some_heavy_calculation(...) ``` improperly, i.e., even when the value can potentially be falsy. This practice is wide spread, and since in most cases memoization is about efficiency and it would not be critical if it does not work correctly, people do not seem to care so much about correcting the wrong usage. In such case, the correct form would be: ```ruby unless instance_variable_defined?(:@foo) @foo = some_heavy_calculation(...) end ``` but this looks too long, and perhaps that is keeping people away from using it. What about allowing `Kernel#instance_variable_set` to take a block instead of the second argument, in which case the assignment should be done only when the instance variable is not defined? ```ruby instance_variable_set(:@foo){some_heavy_calculation(...)} ``` Or, if that does not look right or seems to depart from the original usage of `instance_variable_set`, then what about having a new method? ```ruby memoize(:foo){some_heavy_calculation(...)} ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122947] [Ruby Feature#21539] Facilitate walking native and interpreter (and jit?) stacks from outside of the ruby process
by dalehamel (Dale Hamel) 11 Aug '25

11 Aug '25

Issue #21539 has been reported by dalehamel (Dale Hamel). ---------------------------------------- Feature #21539: Facilitate walking native and interpreter (and jit?) stacks from outside of the ruby process https://bugs.ruby-lang.org/issues/21539 * Author: dalehamel (Dale Hamel) * Status: Open ---------------------------------------- While ruby does have a great API for getting stack traces within the ruby processes, as used by profilers like vernier and stackprof, there are some projects which aim to profile ruby from outside of the process. Some examples include: - rbspy (https://github.com/rbspy/rbspy/tree/main/ruby-structs/src) - rbperf (https://github.com/javierhonduco/rbperf) - open telemetry (https://github.com/open-telemetry/opentelemetry-ebpf-profiler/blob/main/sup…, https://github.com/open-telemetry/opentelemetry-ebpf-profiler/blob/main/int…) These first two take the approach of embedding the ruby headers within the profiler to be able to walk the stack. otel's bpf exporter was relying on access to symbols (https://github.com/open-telemetry/opentelemetry-ebpf-profiler/issues/202) which were removed some time ago https://github.com/ruby/ruby/pull/7459. As a result, it cannot profile newer rubies as it cannot unwind the stacks. All of these solutions kind of take the approach of trying to reverse engineer the ruby process and rely on somewhat hacky approaches that touch internal things that might frequently move around between ruby versions, and all feel a bit brittle. I think the root of this is that there is no public, stable api for this sort of external profiling. I'm not exactly sure what the solution should be, but it would be great for ruby to offer a recommended, supported, and stable way for external profilers (whether they are using perf api's or ptrace) to be able to: - Obtain the ruby native stack starting point, and walk it while being able to resolve the native symbols - Obtain a reference to the ruby execution context and walk the ruby interpreter stack - Have all of this work in a stable and reasonable way regardless of if / which ruby jit is enabled It would be awesome for some ruby maintainers / experts to weigh-in on what such an external API could look like. Perhaps a public header containing stable (or at least perhaps, versioned?) public symbols and perhaps structs as a starting point? This might necessitate that some fields be refactored out of existing structs, and could slow down work related to them (eg, members need to be added or removed). -- https://bugs.ruby-lang.org/

1 0

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

11 Aug '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 2

[ruby-core:122945] [Ruby Bug#21538] initialize_dup not called when duping class/module
by chucke (Tiago Cardoso) 11 Aug '25

11 Aug '25

Issue #21538 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Bug #21538: initialize_dup not called when duping class/module https://bugs.ruby-lang.org/issues/21538 * Author: chucke (Tiago Cardoso) * Status: Open * ruby -v: 3.4.5 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Not sure whether this is expected behaviour or not, but just leaving it here to start the debate on whether callbacks like `initialize_dup` are supposed to be called when a module or class is duped (the same happens with `initialize_copy` and `initialize_clone` btw): class A def initialize_dup(_) puts "dup instance" super end def self.initialize_dup(_) puts "dup class" super end end A.new.dup #=> "dup instance" A.dup #=> nothing -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116382] [Ruby master Feature#20205] Enable `frozen_string_literal` by default
by byroot (Jean Boussier) 10 Aug '25

10 Aug '25

Issue #20205 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20205: Enable `frozen_string_literal` by default https://bugs.ruby-lang.org/issues/20205 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context The `frozen_string_literal: true` pragma was introduced in Ruby 2.3, and as far as I'm aware the plan was initially to make it the default for Ruby 3.0, but this plan was abandoned because it would be too much of a breaking change without any real further notice. According to Matz, he still wishes to enable `frozen_string_literal` by default in the future, but a reasonable migration plan is required. The main issue is backward compatibility, flipping the switch immediately would break a lot of code, so there must be some deprecation period. The usual the path forward for this kind of change is to emit deprecation warnings one of multiple versions in advance. One example of that was the Ruby 2.7 keyword argument deprecation. It was quite verbose, and some users were initially annoyed, but I think the community pulled through it and I don't seem to hear much about it anymore. So for frozen string literals, the first step would be to start warning when a string that would be frozen in the future is mutated. ### Deprecation Warning Implementation I implemented a quick proof of concept with @etienne in https://github.com/Shopify/ruby/pull/549 In short: - Files with `# frozen_string_literal: true` or `# frozen_string_literal: false` don't change in behavior at all. - Files with no `# frozen_string_literal` comment are compiled to use `putchilledstring` opcode instead of regular `putstring`. - This opcode mark the string with a user flag, when these strings are mutated, a warning is issued. Currently the proof of concept issue the warning at the mutation location, which in some case can make locating where the string was allocated a bit hard. But it is possible to improve it so the message also include the location at which the literal string was allocated, and learning from the keyword argument warning experience, we can record which warnings were already issued to avoid spamming users with duplicated warnings. As currently implemented, there is almost no overhead. If we modify the implementation to record the literal location, we'd incur a small memory overhead for each literal string in a file without an explicit `frozen_string_literal` pragma. But I believe we could do it in a way that has no overhead if `Warning[:deprecated] = false`. ### Timeline The migration would happen in 3 steps, each step can potentially last multiple releases. e.g. `R0` could be `3.4`, `R1` be `3.7` and `R2` be `4.0`. I don't have a strong opinion on the pace. - Release `R0`: introduce the deprecation warning (only if deprecation warnings enabled). - Release `R1`: make the deprecation warning show up regardless of verbosity level. - Release `R2`: make string literals frozen by default. ### Impact Given that `rubocop` is quite popular in the community and it has enforced the usage of `# frozen_string_literal: true` for years now, I suspect a large part of the actively maintained codebases in the wild wouldn't see any warnings. And with recent versions of `minitest` enabling deprecation warnings by default (and [potentially RSpec too](https://github.com/rspec/rspec-core/issues/2867)) the few that didn't migrate will likely be made compatible quickly. The real problem of course are the less actively developed libraries and applications. For such cases, any codebase can remain compatible by setting `RUBYOPT="--disable=frozen_string_literal"`, and so even after `R2` release. The flag would never be removed any legacy codebase can continue upgrading Ruby without changing a single line of cod by just flipping this flag. ### Workflow for library maintainers As a library maintainer, fixing the deprecation warnings can be as simple as prepending `# frozen_string_literal: false` at the top of all their source files, and this will keep working forever. Alternatively they can of course make their code compatible with frozen string literals. Code that is frozen string literal compatible doesn't need to explicitly declare it. Only code that need it turned of need to do so. ### Workflow for application owners For application owners, the workflow is the same than for libraries. However if they depend on a gem that hasn't updated, or that they can't upgrade it, they can run their application with `RUBYOPT="--disable=frozen_string_literal"` and it will keep working forever. Any user running into an incompatibility issue can set `RUBYOPT="--disable=frozen_string_literal"` forever, even in `4.x`, the only thing changing is the default value. And any application for which all dependencies have been made fully frozen string literal compatible can set `RUBYOPT="--enable=frozen_string_literal"` and start immediately removing magic comment from their codebase. -- https://bugs.ruby-lang.org/

21 74

[ruby-core:122943] [Ruby Bug#21537] rb_ractor_sched_barrier_start() hangs on Windows
by rhenium (Kazuki Yamaguchi) 10 Aug '25

10 Aug '25

Issue #21537 has been reported by rhenium (Kazuki Yamaguchi). ---------------------------------------- Bug #21537: rb_ractor_sched_barrier_start() hangs on Windows https://bugs.ruby-lang.org/issues/21537 * Author: rhenium (Kazuki Yamaguchi) * Status: Open * ruby -v: ruby 3.5.0dev (2025-08-09T11:32:53Z master 2a6345e957) +PRISM [x64-mswin64_140] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following script hangs at `GC.start` indefinitely. Pressing Ctrl+C on the terminal interrupts the `sleep` and it appears to resume and prints "in_ractor". ```ruby Ractor.new { sleep 1 GC.start puts "in_ractor" } sleep ``` I also reproduced this with Ruby 3.0.7 from RubyInstaller2. Here is the stack trace with master: ``` 0:006> ~*k 0 Id: 1e88.36c4 Suspend: 1 Teb: 000000c6`92478000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`929fef18 00007ffa`9e4edf43 ntdll!NtWaitForMultipleObjects+0x14 01 000000c6`929fef20 00007ffa`9e4ede11 KERNELBASE!WaitForMultipleObjectsEx+0x123 02 000000c6`929ff210 00007ff6`756b8164 KERNELBASE!WaitForMultipleObjects+0x11 03 000000c6`929ff250 00007ff6`756b13af miniruby!w32_wait_events+0x108 [C:\w\ruby\thread_win32.c @ 239] 04 000000c6`929ff2d0 00007ff6`756b62a2 miniruby!native_sleep+0xc3 [C:\w\ruby\thread_win32.c @ 360] 05 000000c6`929ff310 00007ff6`75646353 miniruby!sleep_forever+0x82 [C:\w\ruby\thread.c @ 1374] 06 000000c6`929ff350 00007ff6`756e5f4b miniruby!rb_f_sleep+0x53 [C:\w\ruby\process.c @ 4975] 07 000000c6`929ff380 00007ff6`756e5df9 miniruby!vm_call_cfunc_with_frame_+0x14b [C:\w\ruby\vm_insnhelper.c @ 3850] 08 000000c6`929ff460 00007ff6`756e5dbb miniruby!vm_call_cfunc_with_frame+0x29 [C:\w\ruby\vm_insnhelper.c @ 3895] 09 000000c6`929ff4a0 00007ff6`756e5ab7 miniruby!vm_call_cfunc_other+0xc7 [C:\w\ruby\vm_insnhelper.c @ 3922] 0a 000000c6`929ff4e0 00007ff6`756e8363 miniruby!vm_call_cfunc+0x10b [C:\w\ruby\vm_insnhelper.c @ 4003] 0b 000000c6`929ff510 00007ff6`756e7cfe miniruby!vm_call_method_each_type+0x637 [C:\w\ruby\vm_insnhelper.c @ 4827] 0c 000000c6`929ff610 00007ff6`756f39b4 miniruby!vm_call_method+0x152 [C:\w\ruby\vm_insnhelper.c @ 4991] 0d 000000c6`929ff680 00007ff6`756ee003 miniruby!vm_sendish+0x1f4 [C:\w\ruby\vm_insnhelper.c @ 6065] 0e 000000c6`929ff700 00007ff6`756e0f27 miniruby!vm_exec_core+0x25cb [C:\w\ruby\insns.def @ 900] 0f (Inline Function) --------`-------- miniruby!vm_exec_loop+0x8 [C:\w\ruby\vm.c @ 2653] 10 000000c6`929ff860 00007ff6`755b896f miniruby!rb_vm_exec+0x10b [C:\w\ruby\vm.c @ 2624] 11 000000c6`929ff9d0 00007ff6`755baf47 miniruby!rb_ec_exec_node+0x10f [C:\w\ruby\eval.c @ 284] 12 000000c6`929ffb50 00007ff6`75531069 miniruby!ruby_run_node+0x43 [C:\w\ruby\eval.c @ 320] 13 (Inline Function) --------`-------- miniruby!rb_main+0x25 [C:\w\ruby\main.c @ 42] 14 (Inline Function) --------`-------- miniruby!w32_main+0x5f [C:\w\ruby\main.c @ 62] 15 000000c6`929ffb80 00007ff6`7575e3ec miniruby!wmain+0x69 [C:\w\ruby\main.c @ 48] 16 (Inline Function) --------`-------- miniruby!invoke_main+0x22 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 90] 17 000000c6`929ffbb0 00007ffa`a03de8d7 miniruby!__scrt_common_main_seh+0x10c [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 18 000000c6`929ffbf0 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 19 000000c6`929ffc20 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 1 Id: 1e88.1468 Suspend: 1 Teb: 000000c6`9247a000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`92dff618 00007ffa`a103259e ntdll!NtWaitForWorkViaWorkerFactory+0x14 01 000000c6`92dff620 00007ffa`a03de8d7 ntdll!TppWorkerThread+0x37e 02 000000c6`92dff980 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 03 000000c6`92dff9b0 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 2 Id: 1e88.1058 Suspend: 1 Teb: 000000c6`9247c000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`931ff6a8 00007ffa`a103259e ntdll!NtWaitForWorkViaWorkerFactory+0x14 01 000000c6`931ff6b0 00007ffa`a03de8d7 ntdll!TppWorkerThread+0x37e 02 000000c6`931ffa10 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 03 000000c6`931ffa40 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 3 Id: 1e88.158c Suspend: 1 Teb: 000000c6`9247e000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`935ff998 00007ffa`a103259e ntdll!NtWaitForWorkViaWorkerFactory+0x14 01 000000c6`935ff9a0 00007ffa`a03de8d7 ntdll!TppWorkerThread+0x37e 02 000000c6`935ffd00 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 03 000000c6`935ffd30 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 4 Id: 1e88.3acc Suspend: 1 Teb: 000000c6`92480000 Unfrozen "ruby-timer-thread" # Child-SP RetAddr Call Site 00 000000c6`936ffbc8 00007ffa`9e4ecbbf ntdll!NtWaitForSingleObject+0x14 01 000000c6`936ffbd0 00007ff6`756b7e9d KERNELBASE!WaitForSingleObjectEx+0xaf 02 000000c6`936ffc70 00007ffa`9e0d37b0 miniruby!timer_thread_func+0x45 [C:\w\ruby\thread_win32.c @ 777] 03 000000c6`936ffca0 00007ffa`a03de8d7 ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x30 04 000000c6`936ffcd0 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 05 000000c6`936ffd00 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 5 Id: 1e88.2934 Suspend: 1 Teb: 000000c6`92482000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`937ff4f8 00007ffa`9e4ecbbf ntdll!NtWaitForSingleObject+0x14 01 000000c6`937ff500 00007ff6`756b1276 KERNELBASE!WaitForSingleObjectEx+0xaf 02 000000c6`937ff5a0 00007ff6`756f7f47 miniruby!native_cond_timedwait_ms+0x62 [C:\w\ruby\thread_win32.c @ 483] 03 (Inline Function) --------`-------- miniruby!vm_cond_wait+0x28 [C:\w\ruby\vm_sync.c @ 211] 04 000000c6`937ff5f0 00007ff6`756b2c83 miniruby!rb_vm_cond_wait+0x37 [C:\w\ruby\vm_sync.c @ 220] 05 000000c6`937ff620 00007ff6`756f7f02 miniruby!rb_ractor_sched_barrier_start+0x67 [C:\w\ruby\thread_win32.c @ 956] 06 000000c6`937ff650 00007ff6`755c7a78 miniruby!rb_vm_barrier+0x1e [C:\w\ruby\vm_sync.c @ 265] 07 (Inline Function) --------`-------- miniruby!rb_gc_vm_barrier+0x5 [C:\w\ruby\gc.c @ 179] 08 (Inline Function) --------`-------- miniruby!gc_enter+0x25 [C:\w\ruby\gc\default\default.c @ 6609] 09 000000c6`937ff680 00007ff6`755c442e miniruby!gc_start+0xc0 [C:\w\ruby\gc\default\default.c @ 6334] 0a 000000c6`937ff6e0 00007ff6`755cdd0f miniruby!garbage_collect+0x42 [C:\w\ruby\gc\default\default.c @ 6316] 0b 000000c6`937ff710 00007ff6`755c2cc3 miniruby!rb_gc_impl_start+0x4b [C:\w\ruby\gc\default\default.c @ 6767] 0c 000000c6`937ff740 00007ff6`756d5c7b miniruby!gc_start_internal+0x4f [C:\w\ruby\gc.c @ 3447] 0d 000000c6`937ff780 00007ff6`756ee237 miniruby!builtin_invoker4+0x23 [C:\w\ruby\vm_insnhelper.c @ 7373] 0e (Inline Function) --------`-------- miniruby!invoke_bf+0x32 [C:\w\ruby\vm_insnhelper.c @ 7485] 0f (Inline Function) --------`-------- miniruby!vm_invoke_builtin+0x32 [C:\w\ruby\vm_insnhelper.c @ 7493] 10 000000c6`937ff7c0 00007ff6`756e0f27 miniruby!vm_exec_core+0x27ff [C:\w\ruby\build-debug\vm.inc @ 4621] 11 (Inline Function) --------`-------- miniruby!vm_exec_loop+0x8 [C:\w\ruby\vm.c @ 2653] 12 000000c6`937ff920 00007ff6`756f08b0 miniruby!rb_vm_exec+0x10b [C:\w\ruby\vm.c @ 2624] 13 (Inline Function) --------`-------- miniruby!invoke_iseq_block_from_c+0x1e3 [C:\w\ruby\vm.c @ 1651] 14 (Inline Function) --------`-------- miniruby!invoke_block_from_c_proc+0x2f2 [C:\w\ruby\vm.c @ 1745] 15 000000c6`937ffa90 00007ff6`756b6bf9 miniruby!vm_invoke_proc+0x324 [C:\w\ruby\vm.c @ 1775] 16 000000c6`937ffbd0 00007ff6`756b7987 miniruby!thread_do_start_proc+0x131 [C:\w\ruby\thread.c @ 584] 17 (Inline Function) --------`-------- miniruby!thread_do_start+0x37 [C:\w\ruby\thread.c @ 626] 18 000000c6`937ffc40 00007ff6`756b7720 miniruby!thread_start_func_2+0x243 [C:\w\ruby\thread.c @ 677] 19 000000c6`937ffe90 00007ffa`9e0d37b0 miniruby!thread_start_func_1+0x74 [C:\w\ruby\thread_win32.c @ 659] 1a 000000c6`937ffec0 00007ffa`a03de8d7 ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x30 1b 000000c6`937ffef0 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 1c 000000c6`937fff20 00000000`00000000 ntdll!RtlUserThreadStart+0x2c # 6 Id: 1e88.4f4 Suspend: 1 Teb: 000000c6`92486000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`93bff768 00007ffa`a10d793e ntdll!DbgBreakPoint 01 000000c6`93bff770 00007ffa`a03de8d7 ntdll!DbgUiRemoteBreakin+0x4e 02 000000c6`93bff7a0 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 03 000000c6`93bff7d0 00000000`00000000 ntdll!RtlUserThreadStart+0x2c ``` -- https://bugs.ruby-lang.org/

1 0