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

[ruby-core:123813] [Ruby Misc#21688] Ruby::Box maturing path
by zverok (Victor Shepelev) 09 Dec '25

09 Dec '25

Issue #21688 has been reported by zverok (Victor Shepelev). ---------------------------------------- Misc #21688: Ruby::Box maturing path https://bugs.ruby-lang.org/issues/21688 * Author: zverok (Victor Shepelev) * Status: Open ---------------------------------------- A quick couple of questions in the light of upcoming Ruby 4.0 release and `Ruby::Box` being available there (even if as an experimental feature): 1. Should the documentation of the class be available as RDoc? I mean, as standard class documentation at https://docs.ruby-lang.org/en/master/Ruby/Box.html (404 currently). It seems like RDoc-formatted comments are present [in the code](https://github.com/ruby/ruby/blob/master/box.c#L1048) but never rendered. Are PRs to make the docs rendered and/or improve/expand them welcome, or would it be just distracting? 2. Should small(ish) problems/suggestions be reported? Can they be submitted as PRs? (I mean, things like "in some cases, `#inspect` of the class in the Box is weird", and other stuff like this) Or this would be just distracting from the main work? Thanks. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:123835] [Ruby Bug#21694] Crash when looking up super method from BasicObject
by byroot (Jean Boussier) 09 Dec '25

09 Dec '25

Issue #21694 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21694: Crash when looking up super method from BasicObject https://bugs.ruby-lang.org/issues/21694 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED ---------------------------------------- Initially reported on Reddit by easydwh https://old.reddit.com/r/ruby/comments/1ozhupr/is_a_ruby_segmentation_fault… Repro: ```ruby class BasicObject def basic_call_no_super super end end "test".basic_call_no_super ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123815] [Ruby Misc#21689] DevMeeting-2025-12-11
by mame (Yusuke Endoh) 09 Dec '25

09 Dec '25

Issue #21689 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21689: DevMeeting-2025-12-11 https://bugs.ruby-lang.org/issues/21689 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2025/12/11 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2025/12/08. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

8 11

[ruby-core:124075] [Ruby Bug#19112] Ractor garbage collection breaks/disables all active tracepoints
by jhawthorn (John Hawthorn) 09 Dec '25

09 Dec '25

Issue #19112 has been updated by jhawthorn (John Hawthorn). I think there are a couple problems interacting here. * First is that the GC hooks were being registered specifically on one Ractor, which doesn't make sense as GC could be run inside an arbitrary Ractor (and is global) * Second is that when a hook was disabled (or I believe a Ractor GC'd) we'd change the global flags for which events were being listened to without considering other Ractors might still be subscribed I've just merged https://github.com/ruby/ruby/pull/15396 which tracks the objspace events in a global list fixing the first issue, and in most cases will avoid clobbering the global flags (though that fix is incomplete and we'll want something like Luke's proper fix to handle the per-Ractor events). ---------------------------------------- Bug #19112: Ractor garbage collection breaks/disables all active tracepoints https://bugs.ruby-lang.org/issues/19112#change-115512 * Author: ivoanjo (Ivo Anjo) * Status: Assigned * Assignee: ractor * ruby -v: ruby 3.2.0dev (2022-11-08T08:08:48Z master cdb3ec3af8) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Howdy 👋! I work for Datadog [on the `ddtrace` gem](https://github.com/DataDog/dd-trace-rb) and I found an issue with Ractors + TracePoint. ### Background For tracking time spent in Garbage Collection on our Ruby profiler, we use a tracepoint that listens to the internal GC events. While doing other experiments around Ractors and profiling, I noticed that our tracepoint would suddenly stop working after Ractors were used in the application. I was able to reduce this down to the testcase below. ### How to reproduce (Ruby version & script) I was able to reproduce this on any Ruby 3 version, including master (`ruby 3.2.0dev (2022-11-08T08:08:48Z master cdb3ec3af8) [x86_64-linux]`). ```ruby puts RUBY_DESCRIPTION if ENV['RUN_RACTOR'] == 'true' Ractor.new { 10 }.take puts "Ractor ran!" else puts "Ractor DID NOT ran!" end puts "Enabling tracepoint" tracepoint = TracePoint.new(:line) { |tp| p [tp.path, tp.lineno, tp.event] }.tap(&:enable) 5.times { puts "Triggering gc!"; GC.start } puts "Tracepoint state is enabled? #{tracepoint.enabled?}" puts "Re-enabling tracepoint" tracepoint.enable puts "Finished!" ``` ### Expectation and result Without the Ractor, the tracepoint works as intended: ``` # RUN_RACTOR=false ./ruby ../ruby-3.1.2/triggergc.rb ruby 3.2.0dev (2022-11-08T08:08:48Z master cdb3ec3af8) [x86_64-linux] Ractor DID NOT ran! Enabling tracepoint ["<internal:kernel>", 91, :line] ["../ruby-3.1.2/triggergc.rb", 14, :line] ["../ruby-3.1.2/triggergc.rb", 14, :line] Triggering gc! ["<internal:gc>", 34, :line] ["../ruby-3.1.2/triggergc.rb", 14, :line] Triggering gc! ["<internal:gc>", 34, :line] ["../ruby-3.1.2/triggergc.rb", 14, :line] Triggering gc! ["<internal:gc>", 34, :line] ["../ruby-3.1.2/triggergc.rb", 14, :line] Triggering gc! ["<internal:gc>", 34, :line] ["../ruby-3.1.2/triggergc.rb", 14, :line] Triggering gc! ["<internal:gc>", 34, :line] ["../ruby-3.1.2/triggergc.rb", 16, :line] ["<internal:trace_point>", 257, :line] Tracepoint state is enabled? true ["../ruby-3.1.2/triggergc.rb", 17, :line] Re-enabling tracepoint ["../ruby-3.1.2/triggergc.rb", 18, :line] ["<internal:trace_point>", 213, :line] ["../ruby-3.1.2/triggergc.rb", 20, :line] ["../ruby-3.1.2/triggergc.rb", 20, :line] Finished! ``` ...but once the Ractor runs and is garbage collected, we see that the tracepoint breaks: ``` # RUN_RACTOR=true ./ruby ../ruby-3.1.2/triggergc.rb ruby 3.2.0dev (2022-11-08T08:08:48Z master cdb3ec3af8) [x86_64-linux] ../ruby-3.1.2/triggergc.rb:5: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. Ractor ran! Enabling tracepoint ["<internal:kernel>", 91, :line] ["../ruby-3.1.2/triggergc.rb", 14, :line] ["../ruby-3.1.2/triggergc.rb", 14, :line] Triggering gc! ["<internal:gc>", 34, :line] Triggering gc! Triggering gc! Triggering gc! Triggering gc! Tracepoint state is enabled? true Re-enabling tracepoint ["../ruby-3.1.2/triggergc.rb", 20, :line] ["../ruby-3.1.2/triggergc.rb", 20, :line] Finished ``` ### Additional notes This is a somewhat annoying bug, because it can break all gems that use tracepoints, including `ddtrace`. In particular for `ddtrace`, our plan is to disable the feature that uses tracepoints for Ruby 3 users, to avoid any issues from our tracepoints getting disabled. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121389] [Ruby Bug#21187] Strings concatenated with `\` getting frozen with literal hashes (PRISM only)
by LocoDelAssembly 09 Dec '25

09 Dec '25

Issue #21187 has been reported by LocoDelAssembly (Hernán Pereira). ---------------------------------------- Bug #21187: Strings concatenated with `\` getting frozen with literal hashes (PRISM only) https://bugs.ruby-lang.org/issues/21187 * Author: LocoDelAssembly (Hernán Pereira) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When the first elements of a literal hash are strings that are concatenated with `\`, those elements are flagged with `PM_NODE_FLAG_STATIC_LITERAL` and a special optimization that I believe was introduced in https://github.com/ruby/ruby/commit/8080de04be8e99e71309745822a9d436cc4ae37c causes the strings to be frozen. Reproduction === test.rb ``` a = { a: 'one' \ 'two', b: 'three' \ 'four', c: 'five', d: 'six' \ 'seven' } b = { a: 'one', b: 'two' \ 'three' } puts "a = #{a.map { |k,v| {k => v.frozen?} }}" puts "b = #{b.map { |k,v| {k => v.frozen?} }}" ``` With prism: ``` $ ruby test.rb a = [{a: true}, {b: true}, {c: false}, {d: false}] b = [{a: false}, {b: false}] ``` With parse.y: ``` $ ruby --parser=parse.y test.rb a = [{a: false}, {b: false}, {c: false}, {d: false}] b = [{a: false}, {b: false}] ``` (Notice `b` hash is unaffected in both parsers) Not sure if this is just part of undefined behavior or this is indeed a bug. Assigning a string concatenated with `\` to a variable doesn't make it frozen, to the best of my knowledge this seems to be hash-specific. -- https://bugs.ruby-lang.org/

6 13

[ruby-core:124028] [Ruby Bug#21764] encoding of warning for depreciated global variables is not set
by nobu (Nobuyoshi Nakada) 08 Dec '25

08 Dec '25

Issue #21764 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21764: encoding of warning for depreciated global variables is not set https://bugs.ruby-lang.org/issues/21764 * Author: nobu (Nobuyoshi Nakada) * Status: Open * ruby -v: 68a7edaa81 * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- The aliased name should be encoded properly. ```console $ ruby -v -e 'def Warning.warn(s) = p(s, s.encoding); alias $分行 $/; $分行 = "\n"' ruby 4.0.0dev (2025-11-27T12:05:45Z master 68a7edaa81) +PRISM [arm64-darwin25] "-e:1: warning: '$\xE5\x88\x86\xE8\xA1\x8C' is deprecated\n" #<Encoding:BINARY (ASCII-8BIT)> ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123884] [Ruby Bug#21705] `UNIXServer.open(nil)` segfaults on Windows
by nobu (Nobuyoshi Nakada) 08 Dec '25

08 Dec '25

Issue #21705 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21705: `UNIXServer.open(nil)` segfaults on Windows https://bugs.ruby-lang.org/issues/21705 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- It should check the type of the argument and coercion before converting the encoding. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123769] [Ruby Bug#21680] Integer#digits bug starting from Ruby 3.1
by sigsys (Math Ieu) 08 Dec '25

08 Dec '25

Issue #21680 has been reported by sigsys (Math Ieu). ---------------------------------------- Bug #21680: Integer#digits bug starting from Ruby 3.1 https://bugs.ruby-lang.org/issues/21680 * Author: sigsys (Math Ieu) * Status: Open * ruby -v: ruby 3.3.10 (2025-10-23 revision 343ea05002) [amd64-freebsd14] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` (2**512).digits(256).last ``` The result was 1 on Ruby 3.0. Starting from Ruby 3.1 it turned to 256 (which can't possibly be right). -- https://bugs.ruby-lang.org/

4 3

[ruby-core:123582] [Ruby Bug#21655] segfault when building 3.3.10, regression from 3.3.9
by kurly (Greg Kubaryk) 08 Dec '25

08 Dec '25

Issue #21655 has been reported by kurly (Greg Kubaryk). ---------------------------------------- Bug #21655: segfault when building 3.3.10, regression from 3.3.9 https://bugs.ruby-lang.org/issues/21655 * Author: kurly (Greg Kubaryk) * Status: Open * ruby -v: ruby 3.3.10 (2025-10-23 revision 343ea05002) [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ref downstream bug https://bugs.gentoo.org/965095 - reporting upstream because I was able to reproduce the problem from ruby-3.3.10.tar.xz manually build log excerpt; the rest will be provided as an attachment gcc -O2 -pipe -march=amdfam10 -L. -fstack-protector-strong -rdynamic -Wl,-export-dynamic -fstack-protector-strong -pie main.o dmydln.o miniinit.o dmyext.o array.o ast.o bignum.o class.o compar.o compile.o complex.o cont.o debug.o debug_counter.o dir.o dln_find.o encoding.o enum.o enumerator.o error.o eval.o file.o gc.o hash.o inits.o io.o io_buffer.o iseq.o load.o marshal.o math.o memory_view.o rjit.o rjit_c.o node.o node_dump.o numeric.o object.o pack.o parse.o parser_st.o proc.o process.o ractor.o random.o range.o rational.o re.o regcomp.o regenc.o regerror.o regexec.o regparse.o regsyntax.o ruby.o ruby_parser.o scheduler.o shape.o signal.o sprintf.o st.o strftime.o string.o struct.o symbol.o thread.o time.o transcode.o util.o variable.o version.o vm.o vm_backtrace.o vm_dump.o vm_sync.o vm_trace.o weakmap.o prism/api_node.o prism/api_pack.o prism/diagnostic.o prism/encoding.o prism/extension.o prism/node.o prism/options.o prism/pack.o prism/prettyprint.o prism/regexp.o prism/serialize.o prism/token_type.o prism/util/pm_buffer.o prism/util/pm_char.o prism/util/pm_constant_pool.o prism/util/pm_list.o prism/util/pm_memchr.o prism/util/pm_newline_list.o prism/util/pm_state_stack.o prism/util/pm_string.o prism/util/pm_string_list.o prism/util/pm_strncasecmp.o prism/util/pm_strpbrk.o prism/prism.o prism_init.o yjit.o yjit/target/release/libyjit.o coroutine/amd64/Context.o enc/ascii.o enc/us_ascii.o enc/unicode.o enc/utf_8.o enc/trans/newline.o setproctitle.o addr2line.o -lz -lrt -lrt -lgmp -ldl -lcrypt -lm -lpthread -o miniruby : ./miniruby -I./lib -I. -I.ext/common ./tool/generic_erb.rb -o builtin_binary.inc \ ./template/builtin_binary.inc.tmpl make: *** [uncommon.mk:1316: builtin_binary.inc] Segmentation fault (core dumped) ---Files-------------------------------- buildlog (76.5 KB) -- https://bugs.ruby-lang.org/

5 17

[ruby-core:123881] [Ruby Bug#21703] RUBY_CRASH_REPORT does not work when shelling out in some cases
by peterzhu2118 (Peter Zhu) 08 Dec '25

08 Dec '25

Issue #21703 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #21703: RUBY_CRASH_REPORT does not work when shelling out in some cases https://bugs.ruby-lang.org/issues/21703 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.2: DONTNEED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/15292 RUBY_CRASH_REPORT does not work in some cases when shelling out on Linux. For example, given the following shell script dump.sh: ```sh #!/usr/bin/env bash cat > /tmp/crash ``` And we see it fails like this: ``` $ RUBY_CRASH_REPORT="|dump.sh" ruby -rfiddle -e "Fiddle::Pointer.new(1, 10)[0]" cat: -: Resource temporarily unavailable ``` -- https://bugs.ruby-lang.org/

2 1