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

[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:123768] [Ruby Bug#21679] Segfault when ruby calls pthread_detach in rb_getnameinfo
by luke-gru (Luke Gruber) 08 Dec '25

08 Dec '25

Issue #21679 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21679: Segfault when ruby calls pthread_detach in rb_getnameinfo https://bugs.ruby-lang.org/issues/21679 * Author: luke-gru (Luke Gruber) * Status: Open * ruby -v: 3.4.7 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- We're seeing an issue on our servers running ruby 3.4.7 where we get a SEGV after ruby calls `pthread_detach` on a short-lived pthread that calls `getaddrinfo`. I believe it's related to this glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19951. Our servers are using glibc version 2.39, which is from January 2024. This bug hasn't been fixed in glibc yet but I haven't been able to reproduce it on my Linux desktop. Regardless, there's a simple workaround for it that avoids calling `pthread_detach` on the thread. My PR is here: https://github.com/ruby/ruby/pull/15142. Thanks, Luke -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121629] [Ruby Bug#21265] Crash when proc from Symbol#to_proc called outside refinement scope
by alanwu (Alan Wu) 08 Dec '25

08 Dec '25

Issue #21265 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #21265: Crash when proc from Symbol#to_proc called outside refinement scope https://bugs.ruby-lang.org/issues/21265 * Author: alanwu (Alan Wu) * Status: Open * ruby -v: ruby 3.4.2 and trunk * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED ---------------------------------------- ```ruby class RefinedScope using(Module.new { refine(Kernel) { def itself = 0 } }) ITSELF = :itself.to_proc end RefinedScope::ITSELF[0] ``` ``` ../vm_method.c:1371: Assertion Failed: prepare_callable_method_entry:RB_TYPE_2_P(defined_class, RUBY_T_ICLASS, RUBY_T_MODULE): defined_class: T_FALSE ``` Or SEGV without `-DRUBY_DEBUG`. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:121142] [Ruby master Misc#21154] Document or change Module#autoload?
by fxn (Xavier Noria) 07 Dec '25

07 Dec '25

Issue #21154 has been reported by fxn (Xavier Noria). ---------------------------------------- Misc #21154: Document or change Module#autoload? https://bugs.ruby-lang.org/issues/21154 * Author: fxn (Xavier Noria) * Status: Open ---------------------------------------- The documentation of `Module#autoload?` says > Returns filename to be loaded if name is registered as autoload in the namespace of mod or one of its ancestors. Cool, but in the following snippet ```ruby autoload :Foo, 'foo' autoload?(:Foo) ``` the second line could evaluate to `nil`, and this does not seem to agree. I just registered an autoload, therefore (according to the documentation) I should get "foo" back in line 2. I'd like to ask for clarification from the Ruby team: 1. Is the documentation complete? Should that second line always return "foo"? 2. If the answer is no, which is the logic missing in the docs? Thank you! -- https://bugs.ruby-lang.org/

3 34