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

[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: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: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

[ruby-core:121791] [Ruby Bug#21298] `ObjectSpace.allocation_class_path` returns inconsistent results depending on `TracePoint` state
by mame (Yusuke Endoh) 05 Dec '25

05 Dec '25

Issue #21298 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #21298: `ObjectSpace.allocation_class_path` returns inconsistent results depending on `TracePoint` state https://bugs.ruby-lang.org/issues/21298 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: tenderlovemaking (Aaron Patterson) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `ObjectSpace.allocation_class_path` is an API that returns the class of `self` in the context where an object was allocated. However, due to recent optimizations in `Class#new` (#21254), the return value now changes depending on whether `TracePoint` is enabled. ```ruby require "objspace" class Foo def test obj = Object.new ObjectSpace.allocation_class_path(obj) end end ObjectSpace.trace_object_allocations_start p Foo.new.test #=> 3.4.2: "Class", master: "Foo" ``` Previously, this returned `"Class"` (from the `Class#new` call frame), but in the master branch, the result is now `"Foo"` because that frame is gone. I am ok for the incompatibility itself because I find the new behavior more intuitive and useful. However, there's an inconsistency: the optimization is disabled when `TracePoint` is enabled, causing the result to revert to the old behavior. ```ruby p Foo.new.test #=> master: "Foo" TracePoint.new {}.enable do p Foo.new.test #=> master: "Class", expected: "Foo" end ``` This makes behavior dependent on whether `TracePoint` is enabled, which can lead to confusion. @ko1 @tenderlovemaking Can we make `ObjectSpace.allocation_class_path` consistently return the class from the `.new` call context, regardless of the `TracePoint` state? --- I am facing a failure of the following test when code coverage (which uses `TracePoint`) is enabled: https://github.com/ruby/ruby/blob/e8ad728209ee22136e61054fea74096b49088b8a/… As a short-term workaround, I'm considering commenting out this test. -- https://bugs.ruby-lang.org/

3 6