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

[ruby-core:123484] [Ruby Bug#21640] Core Pathname is missing 3 methods / is partially-defined
by Eregon (Benoit Daloze) 01 Dec '25

01 Dec '25

Issue #21640 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21640: Core Pathname is missing 3 methods / is partially-defined https://bugs.ruby-lang.org/issues/21640 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 3.5.0dev (2025-10-09T08:06:20Z master a29c90c3b0) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` $ ruby -e 'puts Pathname.instance_methods(false).sort; puts Pathname.singleton_methods.sort' > core_pathname_methods.txt $ ruby -rpathname -e 'puts Pathname.instance_methods(false).sort; puts Pathname.singleton_methods.sort' > require_pathname_methods.txt $ diff core_pathname_methods.txt require_pathname_methods.txt 36a37 > find 72a74 > rmtree 98a101 > mktmpdir ``` So `#find`, `#rmtree` and `.mktmpdir` are missing from core Pathname. And indeed, they give NoMethodError, e.g. ``` $ ruby -ve 'Pathname.new("doesnotexist").rmtree' ruby 3.5.0dev (2025-10-09T08:06:20Z master a29c90c3b0) +PRISM [x86_64-linux] -e:1:in '<main>': undefined method 'rmtree' for an instance of Pathname (NoMethodError) ``` I think this is confusing and unexpected for most users. Either Pathname should be fully defined or not at all, having a partially-defined Pathname seems particularly confusing (a bit like an autoload that failed in the middle or so). AFAIK the only core class which used to have this was Fiber with `alive?` and `transfer`, that certainly caused its share of confusion, and Fiber has since been fixed, now even without `require "fiber"` Fiber has all methods. Furthermore these 3 methods are not documented as needing `require 'pathname'` in their documentation: https://github.com/ruby/ruby/blob/master/lib/pathname.rb The reason these 3 methods are not in core pathname seems to be (from [this comment](https://github.com/ruby/pathname/issues/64#issuecomment-3388907046)) > That's consensus with akr and me. We should avoid loading other libraries by simply calling methods from the embedded core classes. I understand that concern and I share it, but I think the situation of having a partially-defined Pathname in core is quite problematic. I think there are 2 solutions: * Define all Pathname methods in core. The `require` are done lazily inside the methods so AFAIK there is no technical issue blocking that, but it's not ideal design-wise that a core class can load default gems (i.e. give up that concern for this particular case). * Do not define Pathname in core and let it be a default gem as it was in Ruby 3.4. I discuss the second in more details, because I found more problems than I would have imagined with core Pathname: ## Should Pathname be in core? #17473 proposed to make Pathname core. That sounded great to me at first thought, but as I realize the practical problems with it I'm thinking it's actually better to keep Pathname non-core and as a default gems. Here are concerns with having Pathname in core: 1. Pathname inherently depends on other default gems/stdlib like `find`, `fileutils` and `tmpdir`. This is important to make Pathname useful. The docs even phrase it like this: `ri Pathname` > ... > All functionality from File, FileTest, and some from Dir and > FileUtils is included, in an unsurprising way. It is essentially a > facade for all of these, and more. 2. core Pathname is missing 3 methods compared to gem Pathname (shown above) 3. the pathname gem is likely to gain extra features, methods and bug fixes. For example I see [4 PRs](https://github.com/ruby/pathname/pulls) adding new methods. It means core Pathname will always be outdated and potentially missing some new methods. 4. One can still use the pathname gem even if it's in core, but surprisingly just `require 'pathname'` is not enough: ``` $ gem install pathname Building native extensions. This could take a while... Successfully installed pathname-0.4.0 1 gem installed $ ruby -e 'require "pathname"; puts $".grep(/pathname/)' pathname.so /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4/pathname.rb ^ wrong that's the stdlib pathname $ ruby -e 'gem "pathname"; require "pathname"; puts $".grep(/pathname/)' # some warnings, reported in https://github.com/ruby/pathname/issues/66 pathname.so /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+4/gems/pathname-0.4.0/lib/pathname.rb ^ correct ``` This is another source of confusion caused by core pathname. It even happens with Bundler! ``` $ cat Gemfile source "https://rubygems.org" gem "pathname" $ bundle install $ ruby -e 'require "bundler/setup"; require "pathname"; puts $".grep(/pathname/); puts; puts $:' pathname.so /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4/pathname.rb /home/eregon/tmp/bundler-pathname/vendor/bundle/ruby/3.5.0+4/gems/pathname-0.4.0/lib /home/eregon/tmp/bundler-pathname/vendor/bundle/ruby/3.5.0+4/extensions/x86_64-linux/3.5.0+4-static/pathname-0.4.0 /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+4/gems/bundler-2.8.0.dev/lib /home/eregon/prefix/ruby-master/lib/ruby/site_ruby/3.5.0+4 /home/eregon/prefix/ruby-master/lib/ruby/site_ruby/3.5.0+4/x86_64-linux /home/eregon/prefix/ruby-master/lib/ruby/site_ruby /home/eregon/prefix/ruby-master/lib/ruby/vendor_ruby/3.5.0+4 /home/eregon/prefix/ruby-master/lib/ruby/vendor_ruby/3.5.0+4/x86_64-linux /home/eregon/prefix/ruby-master/lib/ruby/vendor_ruby /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4 /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4/x86_64-linux $ bundle exec ruby -e 'require "pathname"; puts $".grep(/pathname/); puts; puts $:' same as above ``` I'm not sure why, but that seems a serious bug that the `pathname` gem apparently can't be used at all with Bundler. 4. due to this difference in terms of methods for core & gem pathname it seems complicated to keep core Pathname and gem Pathname in sync, since e.g. everything is naturally in one `.rb` file in the gem, but in two `.rb` files in core 5. the pathname gem has to `remove_const :Pathname` to avoid conflicts and warnings in https://github.com/ruby/pathname/blob/4689b0b78d081ae855f325e086d95803fa5bd…. This is bad for Ruby JITs, especially if core Pathname methods might have been used, as it will invalidate JITs compilations, invalidate some inline caches (also bad for the interpreter), caused the JIT to do more compilations which means slower warmup, makes it much harder to persist JITed code across process executions, etc. Based on all of these I think it would actually be better to not have Pathname in core, and let it be a default gem. Having to `require "pathname"` as one always needed to do so far seems far better than a partially-defined core Pathname with rough edge cases (those concerns). -- https://bugs.ruby-lang.org/

6 21

[ruby-core:117618] [Ruby master Feature#20437] Could be the licensing conditions be made less ambiguous?
by vo.x (Vit Ondruch) 01 Dec '25

01 Dec '25

Issue #20437 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Feature #20437: Could be the licensing conditions be made less ambiguous? https://bugs.ruby-lang.org/issues/20437 * Author: vo.x (Vit Ondruch) * Status: Open ---------------------------------------- # Current state The current [COPYING](https://github.com/ruby/ruby/blob/6cfd929034f1fe3d93160365505a8b88… file says the following: ~~~ Ruby is copyrighted free software by Yukihiro Matsumoto <matz(a)netlab.jp>. You can redistribute it and/or modify it under either the terms of the 2-clause BSDL (see the file BSDL), or the conditions below: 1. You may make and give away verbatim copies of the source form of the ... snip ... ~~~ And this is quite ambiguous. Let me show a few examples: # Ambiguous examples ## lib/net/protocol.rb https://github.com/ruby/ruby/blob/6cfd929034f1fe3d93160365505a8b88bef56159/… ~~~ # This program is free software. You can re-distribute and/or # modify this program under the same terms as Ruby itself, # Ruby Distribute License or GNU General Public License. ~~~ So what is the license? Is it 2-clause BSDL + Ruby + GPL? Or is is just Ruby + GPL but not 2-clause BSDL? ## Racc https://github.com/ruby/racc/blob/d52fb64d166046bfde81e6e9c424fcd884ebcabf/… ~~~ Racc is distributed under the same terms of ruby. (see the file COPYING). ~~~ where the [COPYING](https://github.com/ruby/racc/blob/d52fb64d166046bfde81e6e9c424fcd8… contains just 2-clause BSDL. Not even mentioning that Ruby used to be GPLv2 licensed: https://github.com/ruby/racc/commit/cc7fe952a6b1fc2ef43477674fa13f2d9d99e818 ## Rubygems https://github.com/rubygems/rubygems/blob/master/LICENSE.txt The license is obviously modeled after Ruby COPYING file, but if it could say "licensed under MIT or Ruby", it would be much better. ## Gettext https://github.com/ruby-gettext/gettext/blob/8d84132efd888e68fffbce41331645… The license note is so old that it is not obvious what that means and what was the intention. Did the Ruby relicensing from "GPLv2 or Ruby" to "GPLv2 or BSD" influenced this project? ## SPDX https://spdx.org/licenses/Ruby.html It quotes just the "conditions below" as a Ruby license, while referring to [Ruby license file](https://www.ruby-lang.org/en/about/license.txt) mentioning also 2-clause BSDL # Proposal To me it seems that the whole world recognizes "Ruby" license, except Ruby. Therefore I think it would be nice if Ruby project recognized the "Ruby" license. There are two possibilities I can think of: ## Refer the license by name ~~~diff $ git diff diff --git a/COPYING b/COPYING index 48e5a96de7..a2d179a8a9 100644 --- a/COPYING +++ b/COPYING @@ -1,6 +1,6 @@ Ruby is copyrighted free software by Yukihiro Matsumoto <matz(a)netlab.jp>. You can redistribute it and/or modify it under either the terms of the -2-clause BSDL (see the file BSDL), or the conditions below: +2-clause BSDL (see the file BSDL), or the conditions of the Ruby license below: 1. You may make and give away verbatim copies of the source form of the software without restriction, provided that you duplicate all of the ~~~ ## Extract the "conditions below" into "Ruby" license file The "conditions below" text could be extracted into separate file (e.g. "RUBY_LICENSE") and the "COPYING" file rephrased to say: ~~~ Ruby is copyrighted free software by Yukihiro Matsumoto <matz(a)netlab.jp>. You can redistribute it and/or modify it under either the terms of the 2-clause BSDL (see the file BSDL), or Ruby license (see the file RUBY_LICENSE) ~~~ -- https://bugs.ruby-lang.org/

3 7

[ruby-core:123569] [Ruby Bug#21652] Marshal#dump documentation out-of-date/unclear regarding Data class
by ryannevell (Ryan Nevell) 28 Nov '25

28 Nov '25

Issue #21652 has been reported by ryannevell (Ryan Nevell). ---------------------------------------- Bug #21652: Marshal#dump documentation out-of-date/unclear regarding Data class https://bugs.ruby-lang.org/issues/21652 * Author: ryannevell (Ryan Nevell) * Status: Open * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- With the introduction of the `Data` class in Ruby 3.2, the `Marshal#dump` documentation is confusing since it claims that "Marshal can’t dump ... an instance of ... Data". It is even cross-linked to the new `Data` class. However, and thankfully, `Marshal#dump` does not have any issues serializing instances of `Data` or objects of the defined `Data` types. This message predates the introduction of the `Data` class, and likely refers to wrapped C data (`T_DATA`), instead. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122900] [Ruby Bug#21529] Deprecate the /o modifier and warn against using it
by jpcamara (JP Camara) 28 Nov '25

28 Nov '25

Issue #21529 has been reported by jpcamara (JP Camara). ---------------------------------------- Bug #21529: Deprecate the /o modifier and warn against using it https://bugs.ruby-lang.org/issues/21529 * Author: jpcamara (JP Camara) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I recently ran into a bug in some code because it was using the /o modifier as an optimization, not realizing it created a permanent, immutable value after the first time it gets evaluated. I dug into how the modifier works in CRuby and the history of it here: https://jpcamara.com/2025/08/02/the-o-in-ruby-regex.html. The feature seems like a total footgun with almost no upside. If I run a benchmark between a local regex, and a regex cached by /o, there is no real difference. ```rb require "benchmark" def letters "A-Za-z" end words = %w[the quick brown fox jumped over the lazy dog] Benchmark.bm do |bm| bm.report("without /o:") do regex = /\A[A-Za-z]+\z/ words.each do |word| word.match(regex) end end bm.report("with /o: ") do words.each do |word| word.match(/\A[#{letters}]+\z/o) end end end ``` Most of the time I found that "without /o" actually came out ahead. ``` user system total real without /o: 0.000019 0.000003 0.000022 ( 0.000014) with /o: 0.000020 0.000001 0.000021 ( 0.000020) ``` I'd like to deprecate the feature and update the docs to warn against using it. I'd be happy to submit a PR doing that. Thanks! -- https://bugs.ruby-lang.org/

7 10

[ruby-core:122798] [Ruby Bug#21516] Segfault in String#succ! on 32-bit i686
by leahneukirchen (Leah Neukirchen) 26 Nov '25

26 Nov '25

Issue #21516 has been reported by leahneukirchen (Leah Neukirchen). ---------------------------------------- Bug #21516: Segfault in String#succ! on 32-bit i686 https://bugs.ruby-lang.org/issues/21516 * Author: leahneukirchen (Leah Neukirchen) * Status: Open * ruby -v: 3.4.5 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I noticed segfaults in the test suite of Ruby 3.4.5, related to String#succ! A very easy reproducer is: ./miniruby -e 'puts "ZZZZ999".succ!' $ ./miniruby -e 'puts "ZZZZ999".succ!' -e:1: [BUG] Segmentation fault at 0x9e968041 ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [x86_64-linux-x32] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0011 e:000010 CFUNC :succ! c:0002 p:0005 s:0007 e:000005 EVAL -e:1 [FINISH] c:0001 p:0000 s:0003 E:0017b8 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- -e:1:in '<main>' -e:1:in 'succ!' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ GS: 0x00000063 FS: 0x00000000 ES: 0x0000002b DS: 0x0000002b EDI: 0x9e968049 ESI: 0x9e968041 EBP: 0x5896c1a0 ESP: 0xff97d638 EBX: 0x9e968046 EDX: 0x9e968049 ECX: 0x5896c1a0 EAX: 0x9e968041 TRA: 0x0000000e ERR: 0x00000004 EIP: 0x5681ea07 CS: 0x00000023 EFL: 0x00010293 UES: 0xff97d638 SS: 0x0000002b -- C level backtrace information ------------------------------------------- /builddir/ruby/ruby/miniruby(rb_print_backtrace+0x14) [0x568ae631] /builddir/ruby/ruby/vm_dump.c:823 /builddir/ruby/ruby/miniruby(rb_vm_bugreport) /builddir/ruby/ruby/vm_dump.c:1155 /builddir/ruby/ruby/miniruby(rb_bug_for_fatal_signal+0x86) [0x566e4ee6] /builddir/ruby/ruby/error.c:1130 /builddir/ruby/ruby/miniruby(sigsegv+0x4f) [0x5680e98f] /builddir/ruby/ruby/signal.c:934 linux-gate.so.1(__kernel_rt_sigreturn+0x0) [0xf7f475a0] /builddir/ruby/ruby/miniruby(search_nonascii+0x17) [0x5681ea07] /builddir/ruby/ruby/string.c:728 /builddir/ruby/ruby/miniruby(coderange_scan+0x59) [0x56821d09] /builddir/ruby/ruby/string.c:767 /builddir/ruby/ruby/miniruby(rbimpl_fl_unset_raw_raw+0x0) [0x56824715] /builddir/ruby/ruby/string.c:895 /builddir/ruby/ruby/miniruby(RB_FL_UNSET_RAW) ./include/ruby/internal/fl_type.h:669 /builddir/ruby/ruby/miniruby(RB_ENC_CODERANGE_SET) ./include/ruby/internal/encoding/coderange.h:131 /builddir/ruby/ruby/miniruby(rb_enc_str_coderange) /builddir/ruby/ruby/string.c:911 /builddir/ruby/ruby/miniruby(str_succ+0x69c) [0x5682545c] /builddir/ruby/ruby/string.c:5364 /builddir/ruby/ruby/miniruby(rb_str_succ_bang+0x15) [0x56829f85] /builddir/ruby/ruby/string.c:5380 /builddir/ruby/ruby/miniruby(vm_call_cfunc_with_frame_+0x106) [0x568860e6] /builddir/ruby/ruby/vm_insnhelper.c:3794 /builddir/ruby/ruby/miniruby(vm_call_method_each_type+0x76) [0x56894636] /builddir/ruby/ruby/vm_insnhelper.c:4772 /builddir/ruby/ruby/miniruby(vm_sendish+0xa2) [0x5689fecb] /builddir/ruby/ruby/vm_insnhelper.c:5961 /builddir/ruby/ruby/miniruby(vm_exec_core) /builddir/ruby/ruby/insns.def:898 /builddir/ruby/ruby/miniruby(vm_exec_loop+0x38) [0x56893d68] /builddir/ruby/ruby/vm.c:2622 /builddir/ruby/ruby/miniruby(rb_vm_exec) /builddir/ruby/ruby/vm.c:2598 /builddir/ruby/ruby/miniruby(rb_ec_exec_node+0x7f) [0x566eb0ef] /builddir/ruby/ruby/eval.c:281 /builddir/ruby/ruby/miniruby(ruby_run_node+0x58) [0x566ee558] /builddir/ruby/ruby/eval.c:319 /builddir/ruby/ruby/miniruby(main+0x70) [0x56648460] ./main.c:43 -- Other runtime information ----------------------------------------------- * Loaded script: -e * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb * Process memory map: 56622000-56642000 r--p 00000000 fe:02 9210459 /builddir/ruby/ruby/miniruby 56642000-56941000 r-xp 00020000 fe:02 9210459 /builddir/ruby/ruby/miniruby 56941000-56b4c000 r--p 0031f000 fe:02 9210459 /builddir/ruby/ruby/miniruby 56b4c000-56b54000 r--p 0052a000 fe:02 9210459 /builddir/ruby/ruby/miniruby 56b54000-56b55000 rw-p 00532000 fe:02 9210459 /builddir/ruby/ruby/miniruby 56b55000-56b5e000 rw-p 00000000 00:00 0 58967000-58abb000 rw-p 00000000 00:00 0 [heap] f43b8000-f5a48000 r--s 00000000 fe:02 9210459 /builddir/ruby/ruby/miniruby f5a48000-f5a4b000 r--p 00000000 fe:02 11307369 /usr/lib/libgcc_s.so.1 f5a4b000-f5a79000 r-xp 00003000 fe:02 11307369 /usr/lib/libgcc_s.so.1 f5a79000-f5a7e000 r--p 00031000 fe:02 11307369 /usr/lib/libgcc_s.so.1 f5a7e000-f5a7f000 r--p 00035000 fe:02 11307369 /usr/lib/libgcc_s.so.1 f5a7f000-f5a80000 rw-p 00036000 fe:02 11307369 /usr/lib/libgcc_s.so.1 f5a80000-f5ab0000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] f5abf000-f5ac0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5ac0000-f5b11000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5b11000-f5b12000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5b12000-f5b63000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5b63000-f5b64000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5b64000-f5bb5000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5bb5000-f5bb6000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5bb6000-f5c07000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5c07000-f5c08000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5c08000-f5c59000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5c59000-f5c5a000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5c5a000-f5cab000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5cab000-f5cac000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5cac000-f5cfd000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5cfd000-f5cfe000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5cfe000-f5d4f000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5d4f000-f5d50000 ---p 00000000 00:00 0 f5d50000-f6550000 rw-p 00000000 00:00 0 f6550000-f6590000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] f659f000-f759f000 rw-p 00000000 00:00 0 [anon:Ruby:Init_default_shapes:shape_cache] f759f000-f765f000 rw-p 00000000 00:00 0 [anon:Ruby:Init_default_shapes:shape_list] f765f000-f7690000 rw-p 00000000 00:00 0 f7690000-f76a0000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] f76a9000-f772a000 rw-p 00000000 00:00 0 f772a000-f79a4000 r--p 00074000 fe:02 11307480 /usr/lib/locale/locale-archive f79a4000-f7ba4000 r--p 00000000 fe:02 11307480 /usr/lib/locale/locale-archive f7ba4000-f7ba6000 rw-p 00000000 00:00 0 f7ba6000-f7bc9000 r--p 00000000 fe:02 11307064 /usr/lib/libc.so.6 f7bc9000-f7d69000 r-xp 00023000 fe:02 11307064 /usr/lib/libc.so.6 f7d69000-f7dc5000 r--p 001c3000 fe:02 11307064 /usr/lib/libc.so.6 f7dc5000-f7dc7000 r--p 0021f000 fe:02 11307064 /usr/lib/libc.so.6 f7dc7000-f7dc8000 rw-p 00221000 fe:02 11307064 /usr/lib/libc.so.6 f7dc8000-f7dd2000 rw-p 00000000 00:00 0 f7dd2000-f7de0000 r--p 00000000 fe:02 11307059 /usr/lib/libm.so.6 f7de0000-f7ead000 r-xp 0000e000 fe:02 11307059 /usr/lib/libm.so.6 f7ead000-f7edf000 r--p 000db000 fe:02 11307059 /usr/lib/libm.so.6 f7edf000-f7ee0000 r--p 0010c000 fe:02 11307059 /usr/lib/libm.so.6 f7ee0000-f7ee1000 rw-p 0010d000 fe:02 11307059 /usr/lib/libm.so.6 f7ee1000-f7ee2000 r--p 00000000 fe:02 11307767 /usr/lib/libcrypt.so.2.0.0 f7ee2000-f7efe000 r-xp 00001000 fe:02 11307767 /usr/lib/libcrypt.so.2.0.0 f7efe000-f7f18000 r--p 0001d000 fe:02 11307767 /usr/lib/libcrypt.so.2.0.0 f7f18000-f7f19000 r--p 00036000 fe:02 11307767 /usr/lib/libcrypt.so.2.0.0 f7f19000-f7f1a000 rw-p 00037000 fe:02 11307767 /usr/lib/libcrypt.so.2.0.0 f7f1a000-f7f22000 rw-p 00000000 00:00 0 f7f22000-f7f24000 r--p 00000000 fe:02 11307365 /usr/lib/libz.so.1.3.1 f7f24000-f7f34000 r-xp 00002000 fe:02 11307365 /usr/lib/libz.so.1.3.1 f7f34000-f7f3a000 r--p 00012000 fe:02 11307365 /usr/lib/libz.so.1.3.1 f7f3a000-f7f3b000 r--p 00017000 fe:02 11307365 /usr/lib/libz.so.1.3.1 f7f3b000-f7f3c000 rw-p 00018000 fe:02 11307365 /usr/lib/libz.so.1.3.1 f7f41000-f7f43000 rw-p 00000000 00:00 0 f7f43000-f7f45000 r--p 00000000 00:00 0 [vvar] f7f45000-f7f47000 r--p 00000000 00:00 0 [vvar_vclock] f7f47000-f7f49000 r-xp 00000000 00:00 0 [vdso] f7f49000-f7f4a000 r--p 00000000 fe:02 11307070 /usr/lib/ld-linux.so.2 f7f4a000-f7f72000 r-xp 00001000 fe:02 11307070 /usr/lib/ld-linux.so.2 f7f72000-f7f7d000 r--p 00029000 fe:02 11307070 /usr/lib/ld-linux.so.2 f7f7d000-f7f7f000 r--p 00034000 fe:02 11307070 /usr/lib/ld-linux.so.2 f7f7f000-f7f80000 rw-p 00036000 fe:02 11307070 /usr/lib/ld-linux.so.2 ff95d000-ff97e000 rw-p 00000000 00:00 0 [stack] Segmentation fault Backtrace in gdb: Thread 1 "miniruby" received signal SIGSEGV, Segmentation fault. search_nonascii (p=<optimized out>, e=0xb3b91049 <error: Cannot access memory at address 0xb3b91049>) at string.c:729 729 if (*s & NONASCII_MASK) { (gdb) bt #0 search_nonascii (p=<optimized out>, e=0xb3b91049 <error: Cannot access memory at address 0xb3b91049>) at string.c:729 #1 0x56754d09 in coderange_scan (p=0xb3b91041 <error: Cannot access memory at address 0xb3b91041>, len=8, enc=0x56a961a0) at string.c:767 #2 0x56757715 in enc_coderange_scan (str=4122077840, enc=<optimized out>) at ./include/ruby/internal/core/rstring.h:430 #3 rb_enc_str_coderange (str=4122077840) at string.c:910 #4 0x5675845c in str_succ (str=str@entry=4122077840) at string.c:5364 #5 0x5675cf85 in rb_str_succ_bang (str=4122077840) at string.c:5380 #6 0x567b90e6 in vm_call_cfunc_with_frame_ (ec=0x56a9598c, reg_cfp=0xf77a6fd8, calling=<optimized out>, argc=0, argv=0xf7727030, stack_bottom=0xf772702c) at /builddir/ruby/ruby/vm_insnhelper.c:3794 #7 0x567c7636 in vm_call_method_each_type (ec=0x56a9598c, cfp=0xf77a6fd8, calling=0xffffd9e8) at /builddir/ruby/ruby/vm_insnhelper.c:4772 #8 0x567d2ecb in vm_sendish (ec=<optimized out>, reg_cfp=<optimized out>, cd=<optimized out>, block_handler=<optimized out>, method_explorer=<optimized out>) at /builddir/ruby/ruby/vm_callinfo.h:415 #9 vm_exec_core (ec=0xb3b91041, ec@entry=0x56a9598c) at /builddir/ruby/ruby/insns.def:898 #10 0x567c6d68 in vm_exec_loop (ec=<optimized out>, state=<optimized out>, tag=<optimized out>, result=10) at vm.c:2622 #11 rb_vm_exec (ec=0x56a9598c) at vm.c:2598 #12 0x5661e0ef in rb_ec_exec_node (ec=ec@entry=0x56a9598c, n=n@entry=0xf5b1eaf4) at eval.c:281 #13 0x56621558 in ruby_run_node (n=0xf5b1eaf4) at eval.c:319 #14 0x5657b460 in rb_main (argc=5, argv=0xffffdc34) at ./main.c:43 #15 main (argc=<optimized out>, argv=<optimized out>) at ./main.c:68 I can trigger this with "./configure CFLAGS="-O2 -g" The -O2 is important. With -flto=auto it goes away, with -O0 or -O3 too. I use gcc (GCC) 14.2.1 20250405 on Void Linux with glibc 2.41. On 64-bit x86_64 it works fine with same versions. I have bisected the issue to https://github.com/ruby/ruby/commit/14d154076876 but I don't see how this can introduce the bug. I assume it's some undefined behavior that is potentially triggered. (However reverting that patch works...) I think the behavior is related to the embedded string being expanded into a proper string, but my internal-fu isn't good enough. I hope this helps to debug the issue. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:122643] [Ruby Bug#21498] Windows - Ruby Overrides C Library APIs thus breaking them
by cfis (Charlie Savage) 24 Nov '25

24 Nov '25

Issue #21498 has been reported by cfis (Charlie Savage). ---------------------------------------- Bug #21498: Windows - Ruby Overrides C Library APIs thus breaking them https://bugs.ruby-lang.org/issues/21498 * Author: cfis (Charlie Savage) * Status: Open * ruby -v: *all* on windows (testing with ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x64-mswin64_140]) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I am trying to wrap a simple C++ library, https://github.com/baderouaich/BitmapPlusPlus, as a Ruby extension. However when I use the extension to write a bitmap to disk the bitmap is corrupted. This is because the library uses std::ofstream which eventually uses the C API fclose to write the final bytes to the bitmap file and then closes it. The problem is that Ruby overrides `fclose` and replaces it with `rb_w32_fclose`. It then *exports* its custom version from from x64-vcruntime140-ruby340.dll. And the exported version is broken (at least from the standpoint of the C standard library). Note this has been a long standing issue. The first report I see is from 2013: https://bugs.ruby-lang.org/issues/8569 More recently in 2020 (which explains the issue very well): https://github.com/NREL/OpenStudio/issues/3942#issuecomment-610673401 I understand that Ruby is trying to provide a platform independent API. But the problem is this solution breaks any third party libraries that rely on these C APIs (which of course are very common). And there is no good workaround (see https://github.com/NREL/OpenStudio/issues/3942#issuecomment-611072774) So would it be possible for Ruby to stop exporting custom versions of basic C APIs? The code that does it is here: https://github.com/ruby/ruby/blob/master/win32/mkexports.rb#L41 Ruby of course could still use its custom versions of fclose, read, write etc within ruby.exe and x64-vcruntime140-ruby340.dll. But they should not be exported from x64-vcruntime140-ruby340.dll and thus be off limits to extensions. If a case comes up where an extension really needs access to rb_w32_fclose instead of fclose then an extension developer can use an `#ifdef _WIN32` to do so and work across platforms. That at least puts the developer in control versus now where I don't see any way I can to wrap the bitmap library for usage in Ruby. From my experience the biggest problem is the replacing of fclose with rb_w32_fclose. But I propose removing all such mappings, which include: FD_CLR=rb_w32_fdclr FD_ISSET=rb_w32_fdisset Sleep=rb_w32_Sleep accept=rb_w32_accept access=rb_w32_uaccess bind=rb_w32_bind close=rb_w32_close connect=rb_w32_connect dup2=rb_w32_dup2 fclose=rb_w32_fclose fstat=rb_w32_fstati128 get_osfhandle=rb_w32_get_osfhandle getcwd=rb_w32_ugetcwd getenv=rb_w32_ugetenv gethostbyaddr=rb_w32_gethostbyaddr gethostbyname=rb_w32_gethostbyname gethostname=rb_w32_gethostname getpeername=rb_w32_getpeername getpid=rb_w32_getpid getppid=rb_w32_getppid getprotobyname=rb_w32_getprotobyname getprotobynumber=rb_w32_getprotobynumber getservbyname=rb_w32_getservbyname getservbyport=rb_w32_getservbyport getsockname=rb_w32_getsockname getsockopt=rb_w32_getsockopt inet_ntop=rb_w32_inet_ntop inet_pton=rb_w32_inet_pton ioctlsocket=rb_w32_ioctlsocket isatty=rb_w32_isatty listen=rb_w32_listen lseek=rb_w32_lseek lstat=rb_w32_ulstati128 mkdir=rb_w32_umkdir mmap=rb_w32_mmap mprotect=rb_w32_mprotect munmap=rb_w32_munmap pipe=rb_w32_pipe pread=rb_w32_pread pwrite=rb_w32_pwrite read=rb_w32_read recv=rb_w32_recv recvfrom=rb_w32_recvfrom rename=rb_w32_urename rmdir=rb_w32_urmdir select=rb_w32_select send=rb_w32_send sendmsg sendto=rb_w32_sendto setsockopt=rb_w32_setsockopt shutdown=rb_w32_shutdown socket=rb_w32_socket stati128=rb_w32_ustati128 strcasecmp=msvcrt.stricmp strerror=rb_w32_strerror strncasecmp=msvcrt.strnicmp times=rb_w32_times unlink=rb_w32_uunlink utime=rb_w32_uutime utimensat=rb_w32_uutimensat utimes=rb_w32_uutimes write=rb_w32_write -- https://bugs.ruby-lang.org/

6 32

[ruby-core:122296] [Ruby Bug#21374] FrozenError message is inconsistent when a singleton method is defined on a frozen object
by andrykonchin (Andrew Konchin) 23 Nov '25

23 Nov '25

Issue #21374 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #21374: FrozenError message is inconsistent when a singleton method is defined on a frozen object https://bugs.ruby-lang.org/issues/21374 * Author: andrykonchin (Andrew Konchin) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I would expect a message to contain an object class (e.g. `can't modify frozen <class>: <object#inspect>`) when an ordinary frozen object (non a module or class) is being modified. It works this way in the following example: ```ruby object = []; object.freeze; object.instance_variable_set(:@a, 42) # (irb):5:in `instance_variable_set': can't modify frozen Array: [] (FrozenError) ``` But it doesn't in the following example: ```ruby object = []; object.freeze; def object.x; end # (irb):4:in `<main>': can't modify frozen object: [] (FrozenError) ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:119239] [Ruby master Feature#20750] Expose ruby_thread_has_gvl_p in ruby/thread.h
by kbrock (Keenan Brock) 19 Nov '25

19 Nov '25

Issue #20750 has been reported by kbrock (Keenan Brock). ---------------------------------------- Feature #20750: Expose ruby_thread_has_gvl_p in ruby/thread.h https://bugs.ruby-lang.org/issues/20750 * Author: kbrock (Keenan Brock) * Status: Open ---------------------------------------- Hello All, I'm hoping we can make `ruby_thread_has_gvl_p` a public method and no longer experimental. I saw the following code in a gem that was not compiling with ruby 3.3: ``` c // int ruby_thread_has_gvl_p(void); // <== line of concern if (ruby_thread_has_gvl_p()) { method_call(&context); } else { rb_thread_call_with_gvl(method_call, &context); } ``` 400 unique projects on github added the line listed above to fix compilation. [1] Some of the projects detected the method first in `extconf.rb`, but a majority just referenced it. `ffi` used to have the detection code but dropped it since the method was in all supported ruby versions. It feels like this method is now part of the undocumented public interface. My suggestion is to add the method to the real public interface in `ruby/thread.h`. PR with possible solution: https://github.com/ruby/ruby/pull/11619 Also included a patch if that is easier Thank you for your consideration, Keenan Timeline: - Dec 30 2008 - `rb_thread_call_with_gvl` introduced via 9c04a06 [2] - Jan 12 2009 - `ruby_thread_has_gvl_p` introduced via 6f09fc2 [4] - Jul 18 2012 - `rb_thread_call_with_gvl` made public via e9a91d2 [3] Current references to code: `rb_thread_call_with_gvl` [5] `ruby_thread_has_gvl_p` [6]: [1]: https://github.com/search?q=ruby_thread_has_gvl_p+language%3AC++NOT+is%3Afo… [2]: https://github.com/ruby/ruby/commit/9c04a0647fb99f7554cb2e04385ddbb970631e02 [3]: https://github.com/ruby/ruby/commit/e9a91d2c95dfe22ad0487952f7a1053ef9a5fd16 [4]: https://github.com/ruby/ruby/commit/6f09fc2efd1915c4337ce6dded52a8a8771c3222 [5]: https://github.com/ruby/ruby/blob/master/thread.c#L1878 [6]: https://github.com/ruby/ruby/blob/master/thread.c#L1923 ---Files-------------------------------- 11618.patch (3.18 KB) -- https://bugs.ruby-lang.org/

3 8

[ruby-core:121837] [Ruby Feature#21311] Namespace on read (revised)
by tagomoris (Satoshi Tagomori) 18 Nov '25

18 Nov '25

Issue #21311 has been reported by tagomoris (Satoshi Tagomori). ---------------------------------------- Feature #21311: Namespace on read (revised) https://bugs.ruby-lang.org/issues/21311 * Author: tagomoris (Satoshi Tagomori) * Status: Open ---------------------------------------- This replaces #19744 ## Concept This proposes a new feature to define virtual top-level namespaces in Ruby. Those namespaces can require/load libraries (either .rb or native extension) separately from other namespaces. Dependencies of required/loaded libraries are also required/loaded in the namespace. This feature will be disabled by default at first, and will be enabled by an env variable `RUBY_NAMESPACE=1` as an experimental feature. (It could be enabled by default in the future possibly.) ### "on read" approach The "on write" approach here is the design to define namespaces on the loaded side. For example, Java packages are defined in the .java files and it is required to separate namespaces from each other. It can be implemented very easily, but it requires all libraries to be updated with the package declaration. (In my opinion, it's almost impossible in the Ruby ecosystem.) The "on read" approach is to create namespaces and then require/load applications and libraries in them. Programmers can control namespace separation at the "read" time. So, we can introduce the namespace separation incrementally. ## Motivation The "namespace on read" can solve the 2 problems below, and can make a path to solve another problem: * Avoiding name conflicts between libraries * Applications can require two different libraries safely which use the same module name. * Avoiding unexpected globally shared modules/objects * Applications can make an independent/unshared module instance. * Multiple versions of gems can be required * Application developers will have fewer version conflicts between gem dependencies if rubygems/bundler will support the namespace on read. (Support from RubyGems/Bundler and/or other packaging systems will be needed) For the motivation details, see [Feature #19744]. ## How we can use Namespace ```ruby # app1.rb PORT = 2048 class App def self.port = ::PORT def val = PORT.to_s end p App.port # 2048 # app2.rb class Number def double = self * 2 end PORT = 2048.double class App def self.port = ::PORT def val = PORT.double.to_s end p App.port # 4096 # main.rb - executed as `ruby main.rb` ns1 = Namespace.new ns1.require('./app1') # 2048 ns2 = Namespace.new ns2.require('./app2') # 4096 PORT = 8080 class App def self.port = ::PORT def val = PORT.to_s end p App.port # 8080 p App.val # "8080" p ns1::App.port # 2048 p ns1::App.val # "2048" p ns2::App.port # 4096 p ns2::App.val # "8192" 1.double # NoMethodError ``` ## Namespace specification ### Types of namespaces There are two namespace types, "root" and "user" namespace. "Root" namespace exists solely in a Ruby process, and "user" namespaces can be created as many as Ruby programmers want. ### Root namespace Root namespace is a unique namespace to be defined when a Ruby process starts. It only contains built-in classes/modules/constants, which are available without any `require` calls, including RubyGems itself (when `--disable-gems` is not specified). ### User namespace User namespace is a namespace to run users' Ruby scripts. The "main" namespace is the namespace to run the user's `.rb` script specified by the `ruby` command-line argument. Other user namespaces ("optional" namespaces) can be created by `Namespace.new` call. In user namespace (both main and optional namespaces), built-in class/module definitions are copied from the root namespace, and other new classes/modules are defined in the namespace, separately from other (root/user) namespaces. The newly defined classes/modules are top-level classes/modules in the main namespace like `App`, but in optional namespaces, classes/modules are defined under the namespace (subclass of Module), like `ns::App`. In that namespace `ns`, `ns::App` is accessible as `App` (or `::App`). There is no way to access `App` in the main namespace from the code in the different namespace `ns`. ### Constants, class variables and global variables Constants, Class variables of built-in classes and global variables are also separated by namespace. Values set to class/global variables in a namespace are invisible in other namespaces. ### Methods and procs Methods defined in a namespace run with the defined namespace, even when called from other namespaces. Procs created in a namespace run with the defined namespace too. ### Dynamic link libraries Dynamic link libraries (typically .so files) are also loaded in namespaces as well as .rb files. ### Open class (Changes on built-in classes) In user namespaces, built-in class definitions can be modified. But those operations are processed as copy-on-write of class definition from the root namespace, and the changed definitions are visible only in the (user) namespace. Definitions in the root namespace are not modifiable from other namespaces. Methods defined in the root namespace run only with root-namespace definitions. ## Enabling Namespace Specify `RUBY_NAMESPACE=1` environment variable when starting Ruby processes. `1` is the only valid value here. Namespace feature can be enabled only when Ruby processes start. Setting `RUBY_NAMESPACE=1` after starting Ruby scripts performs nothing. ## Pull-request https://github.com/ruby/ruby/pull/13226 -- https://bugs.ruby-lang.org/

19 110

[ruby-core:122303] [Ruby Bug#21375] Set[] does not call #initialize
by Ethan (Ethan -) 18 Nov '25

18 Nov '25

Issue #21375 has been reported by Ethan (Ethan -). ---------------------------------------- Bug #21375: Set[] does not call #initialize https://bugs.ruby-lang.org/issues/21375 * Author: Ethan (Ethan -) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-26T17:42:35Z master 909a0daab6) +PRISM [x86_64-darwin22] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I have a subclass of Set that overrides #initialize. Following #21216, .new does call #initialize but .[] does not. ```ruby class MySet < Set def initialize(enum = nil) compare_by_identity super end end MySet.new.compare_by_identity? # => true MySet[].compare_by_identity? # => false ``` -- https://bugs.ruby-lang.org/

6 10