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

[ruby-core:123207] [Ruby Bug#21568] Requiring core libraries when already requiring mutliple user defined libraries with the same name can error
by alexalexgriffith (Alex Griffith) 11 Oct '25

11 Oct '25

Issue #21568 has been reported by alexalexgriffith (Alex Griffith). ---------------------------------------- Bug #21568: Requiring core libraries when already requiring mutliple user defined libraries with the same name can error https://bugs.ruby-lang.org/issues/21568 * Author: alexalexgriffith (Alex Griffith) * Status: Open * ruby -v: ruby 3.1.7 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The simplest way to understand this error is that after requiring 2 or more files with the same name as some core libraries, any subsequent calls to require the core library will fail, ie ```ruby require '/Users/alex/foo/fiber' require '/Users/alex/bar/fiber' require 'fiber' ``` raises ``` cannot load such file -- fiber ``` More detailed instructions to repro this can be found in the code snippet below. Noting that I am on a Mac, OS 15.6. This is reproducible across my team on a few different OS versions, all Mac. The same underlying issue can also be seen in some other issues like: https://github.com/newrelic/newrelic-ruby-agent/issues/2001 The context this error is discovered in is that some gems may require their own libraries with the same name as core libraries, often wrapping the implementations of those core libraries to extend functionality, like the New Relic ruby agent does with fiber, for example (https://github.com/newrelic/newrelic-ruby-agent/tree/dev/lib/new_relic/agen…) Then, if 2 or more gems do something like that, and any other gem has `require 'fiber'` in it to support old ruby versions where this was necessary, the error occurs. **Full Steps to Reproduce:** ``` ruby # Setup # ===== # 1. Set this base_dir variable to be an absolute path to a dir # or something that can be found in your $LOAD_PATH. base_dir = # ex: "/Users/<you>/ruby_require_test" # 2. Within that base directory create 2 directories named `foo` and `bar` # 3. Within both `foo` and `bar` touch new files named # - complex.rb # - enumerator.rb # - fiber.rb # - rational.rb # - ruby2_keywords.rb # - set.rb # - thread.rb # Note - this list was generated by running: # `ruby -ve 'p $LOADED_FEATURES.reject { |feature| %r|/| =~ feature }'` # which returns: `["enumerator.so", "thread.rb", "fiber.so", "rational.so", "complex.so", "ruby2_keywords.rb"]` # Reproducing the error: # After requiring 2 (or more) user defined files with the same name as part of # the ruby core library that is required as a bare filename, requiring that part of # the core library will error, ex: `cannot load such file -- fiber`. # The erroring require statements are all .so files begin require "#{base_dir}/foo/complex" require "#{base_dir}/bar/complex" require 'complex' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/enumerator" require "#{base_dir}/bar/enumerator" require 'enumerator' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/fiber" require "#{base_dir}/bar/fiber" require 'fiber' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/rational" require "#{base_dir}/bar/rational" require 'rational' rescue LoadError => e puts e.message end # The following examples do not error. # The difference seems to be that the core lib files are defined as .rb not .so begin require "#{base_dir}/foo/ruby2_keywords" require "#{base_dir}/bar/ruby2_keywords" require 'ruby2_keywords' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/set" require "#{base_dir}/bar/set" require 'set' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/thread" require "#{base_dir}/bar/thread" require 'thread' rescue LoadError => e puts e.message end ``` -- https://bugs.ruby-lang.org/

5 8

[ruby-core:123453] [Ruby Bug#21634] Combining read(1) with eof? causes dropout of results unexpectedly on Windows.
by YO4 (Yoshinao Muramatsu) 11 Oct '25

11 Oct '25

Issue #21634 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21634: Combining read(1) with eof? causes dropout of results unexpectedly on Windows. https://bugs.ruby-lang.org/issues/21634 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * ruby -v: ruby 3.5.0dev (2025-10-03T08:59:54Z master 5b2ec0eb1b) +PRISM [x64-mingw-ucrt] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- On Windows, when reading a file containing EOF(\x1A), using read(1) with IO#eof? causes unexpected dropout of results. ```ruby irb(main):001> IO.binwrite("txt", "abcd\x1A") => 5 irb(main):002> open("txt", "r") { p _1.read(1) until _1.eof? }; # works fine "a" "b" "c" "d" "\x1A" irb(main):003> open("txt", "rt") { p _1.read(1) until _1.eof? }; # has failure "b" "d" irb(main):004> ``` The problem disappeared when I commented out one of the following lines (though this will break other things). * previous_mode = set_binary_mode_with_seek_cur(fptr); in io_read() * flush_before_seek(fptr, false); in set_binary_mode_with_seek_cur(() * io_unread(fptr, discard_rbuf); in flush_before_seek() Within io_unread(), rbuf.len should have changed as 5, 4, 3,... but instead changed as 4, 2,(end). Since inconsistencies already exist at this point, the problem appears to originate elsewhere. I found this in ruby master but the same issue was found at least in ruby-1.9.3-p551. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123445] [Ruby Bug#21631] Backport openssl gem bugfix releases
by Bo98 (Bo Anderson) 11 Oct '25

11 Oct '25

Issue #21631 has been reported by Bo98 (Bo Anderson). ---------------------------------------- Bug #21631: Backport openssl gem bugfix releases https://bugs.ruby-lang.org/issues/21631 * Author: Bo98 (Bo Anderson) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The openssl gem has made new patch releases for all supported release lines in order to fix a compatibility issue with OpenSSL 3.6.0 (along with other bug fixes such as one for a segfault). Without the compatibility fix, the openssl gem is largely broken for certificate verification with OpenSSL 3.6.0, which then affects other parts of Ruby like net-http. Ruby 3.4 PR (3.3.0 -> 3.3.1): https://github.com/ruby/ruby/pull/14792 Ruby 3.3 PR (3.2.0 -> 3.2.2): https://github.com/ruby/ruby/pull/14793 I'm not entirely sure what to do for Ruby 3.2. We can update the gem from 3.1.0 to 3.1.2 but that's perhaps out-of-scope for Ruby 3.2 being in security maintenance mode. Would cherry-picking the single compatibility fix commit be acceptable? The issue has been widely noticed already: https://github.com/ruby/openssl/issues/949 -- https://bugs.ruby-lang.org/

4 6

[ruby-core:122558] [Ruby Bug#21446] StackOverflow when changing visibility in reopened refinement
by luke-gru (Luke Gruber) 11 Oct '25

11 Oct '25

Issue #21446 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21446: StackOverflow when changing visibility in reopened refinement https://bugs.ruby-lang.org/issues/21446 * Author: luke-gru (Luke Gruber) * Status: Open * ruby -v: 3.5.0 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby class A def a :a end end class B < A end module R refine B do private :a end end module R refine B do public :a end end using R B.new.a # StackOverflow ``` I would expect it to change the visibility, not to overflow the stack. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123464] [Ruby Bug#21635] Reading code from STDIN unexpectedly sets $_ in 3.4.6+
by sisyphus (Sisyphus P) 10 Oct '25

10 Oct '25

Issue #21635 has been reported by sisyphus (Sisyphus P). ---------------------------------------- Bug #21635: Reading code from STDIN unexpectedly sets $_ in 3.4.6+ https://bugs.ruby-lang.org/issues/21635 * Author: sisyphus (Sisyphus P) * Status: Open * ruby -v: ruby 3.4.6 (2025-09-16 revision dbd83256b1) +PRISM [arm64-darwin23] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- It seems from Ruby 3.4.6+ if you pass in code that doesn't end with a newline to the ruby interpreter it sets `$_`: ``` # ruby -v ruby 3.4.6 (2025-09-16 revision dbd83256b1) +PRISM [arm64-darwin23] # printf 'p $_' | ruby "p $_" ``` This only happens if the code passed in doesn't end with a newline and doesn't happen in ruby 3.4.5 or earlier: ``` # ruby -v ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [arm64-darwin23] # printf 'p $_' | ruby nil ``` I would expect that `$_` is nil at the start of program execution. NB. this does result in the world's shortest Ruby quine (`printf 'print' | ruby`) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123463] PAY OR BE EXPOSED ❗️
by Ruby-core 10 Oct '25

10 Oct '25

1 0

[ruby-core:123462] PAY OR BE EXPOSED ❗️
by Ruby-core 10 Oct '25

10 Oct '25

1 0

[ruby-core:123460] PAY OR BE EXPOSED ❗️
by Ruby-core 10 Oct '25

10 Oct '25

1 0

[ruby-core:123459] PAY OR BE EXPOSED ❗️
by Ruby-core 10 Oct '25

10 Oct '25

1 0

[ruby-core:123458] PAY OR BE EXPOSED ❗️
by Ruby-core 10 Oct '25

10 Oct '25

1 0