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

[ruby-core:126246] [Ruby Bug#22228] Do a major GC in YJIT test helper `assert_compiles` before running the test code
by jprokop (Jarek Prokop) 04 Aug '26

04 Aug '26

Issue #22228 has been reported by jprokop (Jarek Prokop). ---------------------------------------- Bug #22228: Do a major GC in YJIT test helper `assert_compiles` before running the test code https://bugs.ruby-lang.org/issues/22228 * Author: jprokop (Jarek Prokop) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-04T15:30:26Z master 036159508e) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I was debugging why a YJIT test added from backport to 3.3.11 with GC.stress fails downstream. This revealed an assumption in the assert_compiles, that the environment is "clean", or as default as possible. `assert_compiles` already sanitizes environment with `--disable-gems` and `reset_stats!` call. I'd like to propose the `assert_compiles` method to trigger a GC.start before executing the test proc, and before the stats reset. While the issue described below does not happen on default Rubies 3.4 and 4.0, it could enhance the YJIT test environment. I was investigating downstream test failure on Ruby 3.3.11 (and later 3.3.12) [0] that appeared after backport of: https://bugs.ruby-lang.org/issues/21266 Where the tests in YJIT expects no exits by default: Provided as a default here: https://github.com/ruby/ruby/blob/3e646aee/test/ruby/test_yjit.rb#L2015 Expected as part of condition here: https://github.com/ruby/ruby/blob/3e646aee/test/ruby/test_yjit.rb#L2080 Downstream we insert hook for optional ABRT error reporting for Ruby: https://src.fedoraproject.org/rpms/ruby/blob/11eb00c7bf5c87033a73301ca8dad5… Relevant patchfile: https://src.fedoraproject.org/rpms/ruby/blob/11eb00c7bf5c87033a73301ca8dad5… We create empty `abrt.rb` to test with later on: https://src.fedoraproject.org/rpms/ruby/blob/11eb00c7bf5c87033a73301ca8dad5… To reproduce the failure in 3.3, both the patch and the file are required to exist for the failure at [0] to appear. Later I found that parse.y opens a file to load the abrt.rb and registers it with Ruby GC, which causes zombie and interrupt on `GC.stress=true`, since prism parser became default, these failures no longer appear as the parser does not copy parse.y's approach of registering the opened file with Ruby GC. The note on #19921 https://bugs.ruby-lang.org/issues/19921#note-20 regarding this was correct and it's also the earliest known appearance of the issue. --- [0] Test failure result: TestYJIT#test_proc_block_with_kwrest = 0.08 s 1) Failure: TestYJIT#test_proc_block_with_kwrest [/builddir/build/BUILD/ruby-3.3.11/test/ruby/test_yjit.rb:1531]: Expected no exits, but got: {:send=>1} Reasons: method call fallback reasons: iseq_has_kwrest: 1 (100.0%) invokeblock fallback reasons: proc: 2 (100.0%) invokesuper fallback reasons: (all relevant counters are zero) method call exit reasons: interrupted: 1 (100.0%) invokeblock exit reasons: (all relevant counters are zero) invokesuper exit reasons: (all relevant counters are zero) getblockparamproxy exit reasons: (all relevant counters are zero) getinstancevariable exit reasons: (all relevant counters are zero) setinstancevariable exit reasons: (all relevant counters are zero) leave exit reasons: interp_return: 6 (100.0%) left shift (ltlt) exit reasons: (all relevant counters are zero) invalidation reasons: constant_ic_fill: 2 (100.0%) -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126237] [Ruby Bug#18947] Unexpected Errno::ENAMETOOLONG on Windows
by hsbt (Hiroshi SHIBATA) 04 Aug '26

04 Aug '26

Issue #18947 has been updated by hsbt (Hiroshi SHIBATA). Two questions before this goes further. * The bit is set in `rb_w32_sysinit`, so only hosts that call `ruby_sysinit` get it, which effectively means `ruby.exe`. Embedders that do their own initialization keep the 260 character limit. Should I move it somewhere every embedder reaches? * `IsLongPathAwareProcess` is undocumented. golang has set it since 1.23, but Microsoft's Go maintainers proposed removing it. The alternative is `\\?\` prefixing at about 15 call sites, which still cannot fix `Dir.chdir` or `require`. ---------------------------------------- Bug #18947: Unexpected Errno::ENAMETOOLONG on Windows https://bugs.ruby-lang.org/issues/18947#change-118323 * Author: inversion (Yura Babak) * Status: Open * Assignee: windows * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x64-mingw-ucrt] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- On Windows 10, I am working on a script to copy a complex folder structure. Pathname and FileUtils work fine for me until there is a folder with a **very long path** (>260 chars). Normally you cannot access such a folder with Ruby. The next operations will raise `Errno::ENOENT` ``` ruby Pathname.new(300_chars_path).children FileUtils.mkpath(300_chars_path) ``` But there is a way in Windows to remove the MAX_PATH limitation. You can find a small .reg file in this article: https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-lim… After changing this system option, things start to work strangely in Ruby. This will now raise `Errno::ENAMETOOLONG`: ``` ruby Pathname.new(300_chars_path).children ``` But at the same time, you can create a folder with such a long path and write-read a file in it ``` ruby FileUtils.mkpath(300_chars_path) file = Pathname.new(300_chars_path+'/file.txt') file.write 'oooooooooo' puts Pathname.new(300_chars_path+'/file.txt').read ``` So you can work with individual items but attempts to list such folders' content fail (`.children`, `.glob`, `.copy`, etc). In my case, deep `.glob` is broken for all the parent folders of that deep long-path folder (( The only way I found for listing is ``` ruby require 'win32ole' fso = WIN32OLE.new 'Scripting.FileSystemObject' for file in fso.GetFolder(300_chars_path).files file.name file.path.length end ``` But using this workaround breaks all my code workflow built on top of Pathname and FileUtils ((. So for me, it looks like some operations with long-path folders are not working just because in Ruby there is a check for the path length and not a real operation problem. And in some places (see .mkpath) there is no such check and all works fine. Also notice that other applications on Windows have no problems with long-path folders (like Total Commander). Please consider reviewing if we really need to raise `Errno::ENAMETOOLONG` if the `LongPathsEnabled` option is enabled in the Windows registry. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115016] [Ruby master Bug#19921] TestYJIT#test_bug_19316 test failure
by vo.x (Vit Ondruch) 03 Aug '26

03 Aug '26

Issue #19921 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19921: TestYJIT#test_bug_19316 test failure https://bugs.ruby-lang.org/issues/19921 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-12 master 52709a4862) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Testing with 52709a4862 on Fedora Rawhide, I observe following failure: ~~~ 94) Failure: TestYJIT#test_bug_19316 [/builddir/build/BUILD/ruby-3.3.0-52709a4862/test/ruby/test_yjit.rb:1126]: Expected no exits, but got {:opt_and=>1} ~~~ -- https://bugs.ruby-lang.org/

6 21

[ruby-core:126223] [Ruby Bug#15598] Deadlock on mutual reference of autoloaded constants
by wanabe (_ wanabe) 02 Aug '26

02 Aug '26

Issue #15598 has been updated by wanabe (_ wanabe). This issue appears to have been corrected at https://github.com/ruby/ruby/commit/6fbc32b5d0da31535cccc0eca1853273313a0b52. ``` $ (git checkout 6fbc32b5d0da31535cccc0eca1853273313a0b52~; make -j miniruby) >/dev/null && ./miniruby -v base_thread_const.rb ; echo $? HEAD is now at 30e5e7c005f Revert "Fix jump buffer leak in setjmp handler in WASI builds" ruby 3.5.0dev (2025-04-01T16:11:01Z v3_5_0_preview1~146 30e5e7c005) +PRISM [x86_64-linux] base_thread_const.rb:5:in 'Thread#join': No live threads left. Deadlock? (fatal) 3 threads, 3 sleeps current:0x000064627f26fd10 main thread:0x000064627f200ad0 * #<Thread:0x00007c9089d2a668 sleep_forever> rb_thread_t:0x000064627f200ad0 native:0x00007c908a2a07c0 int:0 base_thread_const.rb:5:in 'Thread#join' base_thread_const.rb:5:in '<main>' * #<Thread:0x00007c9089d12ae0 base_thread_const.rb:3 sleep_forever> rb_thread_t:0x000064627f269ea0 native:0x00007c906ebbe6c0 int:0 mutex:0x000064627f26fef0 cond:1 depended by: tb_thread_id:0x000064627f200ad0 /home/wanabe/work/prog/ruby/ruby/tmp/master/a.rb:3:in '<class:A>' /home/wanabe/work/prog/ruby/ruby/tmp/master/a.rb:1:in '<top (required)>' base_thread_const.rb:3:in 'Kernel#require' base_thread_const.rb:3:in 'block in <main>' * #<Thread:0x00007c9089d129c8 base_thread_const.rb:4 sleep_forever> rb_thread_t:0x000064627f26fd10 native:0x00007c906e9bc6c0 int:0 /home/wanabe/work/prog/ruby/ruby/tmp/master/b.rb:3:in '<class:B>' /home/wanabe/work/prog/ruby/ruby/tmp/master/b.rb:1:in '<top (required)>' base_thread_const.rb:4:in 'Kernel#require' base_thread_const.rb:4:in 'block in <main>' from base_thread_const.rb:5:in '<main>' 1 $ (git checkout 6fbc32b5d0da31535cccc0eca1853273313a0b52; make -j miniruby) >/dev/null && ./miniruby -v base_thread_const.rb ; echo $? Previous HEAD position was 30e5e7c005f Revert "Fix jump buffer leak in setjmp handler in WASI builds" HEAD is now at 6fbc32b5d0d GCC defines __linux__, not __LINUX__ ruby 3.5.0dev (2025-04-01T16:11:01Z v3_5_0_preview1~146 30e5e7c005) +PRISM [x86_64-linux] ["/home/wanabe/work/prog/ruby/ruby/tmp/master/b.rb", 3, [:a1]] ["/home/wanabe/work/prog/ruby/ruby/tmp/master/a.rb", 3, [:b1, :b2]] 0 ``` And for reasons unknown, it depends on the parser. This problem still occurs when using parse.y. ``` $ for parser in prism parse.y; do ./miniruby -v --parser=$parser; for i in $(seq 1 1 1000); do ./miniruby -v --parser=$parser base_thread_const.rb || break; done > /dev/null; done ruby 4.1.0dev (2026-08-02T09:00:37Z :detached: 63c7beb2ef) +PRISM [x86_64-linux] ruby 4.1.0dev (2026-08-02T09:00:37Z :detached: 63c7beb2ef) [x86_64-linux] base_thread_const.rb:5:in 'Thread#join': No live threads left. Deadlock? (fatal) 3 threads, 3 sleeps current:0x00005f6d13cab8c0 main thread:0x00005f6cf8483400 * #<Thread:0x00007dea51d58310 sleep_forever> rb_thread_t:0x00005f6cf8483400 native:0x00007dea522c97c0 int:0 base_thread_const.rb:5:in 'Thread#join' base_thread_const.rb:5:in '<main>' * #<Thread:0x00007dea51c9fe00 base_thread_const.rb:3 sleep_forever> rb_thread_t:0x00005f6d13cab8c0 native:0x00007dea36fbe6c0 int:0 depended by: tb_thread_id:0x00005f6cf8483400 /home/wanabe/work/prog/ruby/ruby/tmp/master/a.rb:3:in '<class:A>' /home/wanabe/work/prog/ruby/ruby/tmp/master/a.rb:1:in '<top (required)>' base_thread_const.rb:3:in 'Kernel#require' base_thread_const.rb:3:in 'block in <main>' * #<Thread:0x00007dea51c9ff18 base_thread_const.rb:4 sleep_forever> rb_thread_t:0x00005f6d13cabfc0 native:0x00007dea36ebd6c0 int:0 mutex:2 cond:1 /home/wanabe/work/prog/ruby/ruby/tmp/master/b.rb:3:in '<class:B>' /home/wanabe/work/prog/ruby/ruby/tmp/master/b.rb:1:in '<top (required)>' base_thread_const.rb:4:in 'Kernel#require' base_thread_const.rb:4:in 'block in <main>' from base_thread_const.rb:5:in '<main>' ``` ---------------------------------------- Bug #15598: Deadlock on mutual reference of autoloaded constants https://bugs.ruby-lang.org/issues/15598#change-118305 * Author: akr (Akira Tanaka) * Status: Open * ruby -v: ruby 2.7.0dev (2019-02-11 trunk 67049) [x86_64-linux] * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- Mutual reference of autoloaded constants can cause deadlock sporadically. Assume A is defined in a.rb and it uses B at loading time. Also, B is defined in b.rb and it uses A at loading time. ``` % cat a.rb class A def a1() end p [__FILE__, __LINE__, B.instance_methods(false)] def a2() end end % cat b.rb class B def b1() end p [__FILE__, __LINE__, A.instance_methods(false)] def b2() end end ``` If they are loaded via autoload and constants are referenced sequentially, it works (no error, at least). However, incomplete A (which a2 is not defined) is appear in b.rb, though. ``` % cat base_seq.rb autoload :A, "./a" autoload :B, "./b" A B % ruby base_seq.rb ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, [:b1, :b2]] ``` However, the constants are referenced in multi threads, deadlock can occur, or works like sequential version, sporadically. ``` % cat base_thread_const.rb autoload :A, "./a" autoload :B, "./b" t1 = Thread.new { A } t2 = Thread.new { B } t1.join t2.join % ruby base_thread_const.rb Traceback (most recent call last): 1: from base_thread_const.rb:5:in `<main>' base_thread_const.rb:5:in `join': No live threads left. Deadlock? (fatal) 3 threads, 3 sleeps current:0x000055f9e2fa1b00 main thread:0x000055f9e2ec14b0 * #<Thread:0x000055f9e2eef188 sleep_forever> rb_thread_t:0x000055f9e2ec14b0 native:0x00007f259bc54b40 int:0 base_thread_const.rb:5:in `join' base_thread_const.rb:5:in `<main>' * #<Thread:0x000055f9e31ece30@base_thread_const.rb:3 sleep_forever> rb_thread_t:0x000055f9e31403c0 native:0x00007f2597e99700 int:0 depended by: tb_thread_id:0x000055f9e2ec14b0 /tmp/h/a.rb:3:in `<class:A>' /tmp/h/a.rb:1:in `<top (required)>' /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' base_thread_const.rb:3:in `block in <main>' * #<Thread:0x000055f9e31ecbb0@base_thread_const.rb:4 sleep_forever> rb_thread_t:0x000055f9e2fa1b00 native:0x00007f258ffff700 int:0 /tmp/h/b.rb:3:in `<class:B>' /tmp/h/b.rb:1:in `<top (required)>' /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' base_thread_const.rb:4:in `block in <main>' % ruby base_thread_const.rb ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, [:b1, :b2]] ``` Also, if "require" is used instead of constant references in the threads, deadlock can occur (sporadically) too. Note that incomplete A can appear in b.rb and incomplete B can appear in a.rb. The incompleteness vary. ``` % cat base_thread_require.rb autoload :A, "./a" autoload :B, "./b" t1 = Thread.new { require './a' } t2 = Thread.new { require './b' } t1.join t2.join % ruby base_thread_require.rb Traceback (most recent call last): 1: from base_thread_require.rb:5:in `<main>' base_thread_require.rb:5:in `join': No live threads left. Deadlock? (fatal) 3 threads, 3 sleeps current:0x00005591a27f5190 main thread:0x00005591a24264b0 * #<Thread:0x00005591a24531a0 sleep_forever> rb_thread_t:0x00005591a24264b0 native:0x00007feced36ab40 int:0 base_thread_require.rb:5:in `join' base_thread_require.rb:5:in `<main>' * #<Thread:0x00005591a2754cc8@base_thread_require.rb:3 sleep_forever> rb_thread_t:0x00005591a27f5190 native:0x00007fece95af700 int:0 depended by: tb_thread_id:0x00005591a24264b0 /tmp/h/a.rb:1:in `<top (required)>' /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' base_thread_require.rb:3:in `block in <main>' * #<Thread:0x00005591a2754a98@base_thread_require.rb:4 sleep_forever> rb_thread_t:0x00005591a2506b00 native:0x00007fece13ad700 int:0 mutex:0x00005591a27f5190 cond:1 /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' /tmp/h/b.rb:3:in `<class:B>' /tmp/h/b.rb:1:in `<top (required)>' /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' base_thread_require.rb:4:in `block in <main>' % ruby base_thread_require.rb ["/tmp/h/b.rb", 3, []] ["/tmp/h/a.rb", 3, [:b1]] % repeat 100 (ruby base_thread_require.rb >& /tmp/z && cat /tmp/z) ["/tmp/h/a.rb", 3, []] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, []] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, []] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/b.rb", 3, []] ["/tmp/h/a.rb", 3, [:b1]] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, [:b1, :b2]] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, [:b1, :b2]] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, [:b1, :b2]] ["/tmp/h/a.rb", 3, []] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, []] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, []] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, []] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, []] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, []] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, []] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, [:b1, :b2]] ["/tmp/h/a.rb", 3, []] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, []] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, []] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, [:b1]] ["/tmp/h/b.rb", 3, [:a1, :a2]] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, [:b1, :b2]] ["/tmp/h/a.rb", 3, []] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, []] ["/tmp/h/b.rb", 3, [:a1]] ["/tmp/h/a.rb", 3, []] ["/tmp/h/b.rb", 3, [:a1]] ``` I think there are several ways to solve this issue. - Prohibit mutual reference. I.e. raise an error at autoload constant reference currently loading. Since mutual reference causes incomplete definition, it is dangerous even with single thread. However, if real application uses such code, this is incompatible. - More coarse locking. Since the deadlock is caused because two threads lock the constants in different order: A to B and B to A. I think it is possible to fix this issue by locking whole autoloading procedure by single lock, namely "global autoload lock". Note that it should also be locked by "require" method if it load a file for autoload. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123776] [Ruby Bug#21682] The result of IO#pos is inconsistent after using IO#ungetc.
by YO4 (Yoshinao Muramatsu) 31 Jul '26

31 Jul '26

Issue #21682 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21682: The result of IO#pos is inconsistent after using IO#ungetc. https://bugs.ruby-lang.org/issues/21682 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In this issue, I propose modifying `IO#ungetc` to never change the file position and explain the reasons for this change. The file location after using IO#ungetc may or may not change. This behavior is not documented. Since there are cases that the file position cannot be modified, I propose to unify the behavior so that the file position is not changed. ## Motivation Ensure file position behavior is independent of I/O setup. Avoid excessive exposure of implementation details. ## Current Details The file position after using IO#ungetc depends on the following conditions: When encoding conversion is not used: It changes. When encoding conversion is used: It does not change. This corresponds internally to whether the ungetc character is stored in the IO object's rbuf or cbuf. When using cbuf, the byte count of a character in cbuf may differ from its byte count in rbuf, making conversion from cbuf byte count to rbuf byte count potentially complex. Furthermore, even if one reverse-converts a character in cbuf to calculate its byte count in rbuf, the practical significance of this calculation is questionable. Therefore, it appears that adjusting the buffered byte count from the actual file position to calculate the file position in Ruby when a character exists in cbuf is not implemented. When stored in rbuf, its byte count can be used to calculate the file position, so the file position moves due to ungetc. ## Problems It seems relatively unknown that the side effects of ungetc can change depending on I/O setup. The Ruby community doesn't seem to discuss avoiding the use of file positions after ungetc. Behavior changing under little-known conditions reduces test coverage and leaves potential bugs. On Windows, files opened in "r" mode perform CRLF conversion but operate without encoding conversion, delegating conversion to the C runtime library (CRT). This is primarily for speed, but it modifies IO state in various places within io.c, reducing readability. It has also caused numerous bugs related to file position. Unfortunately, in Windows, "r" and "rt" are not equivalent depending on whether encoding conversion is used or not. This means the behavior of ungetc cannot be predicted within the context of 'text mode'. I'm working personally on switching to use encoding conversion instead of CRT read(), which means encoding conversion will be used for files opened with "r". This change will alter the behavior of ungetc. This impact occurs because implementation details are being exposed excessively, which is undesirable. ## Changes and Impact IO#ungetc will no longer change the file position. This affects not only IO#pos, but also implicitly impacts the file position when writing after ungetc. TestIO#test_copy_stream_dst_rbuf depends on this behavior. Changing the behavior of IO#ungetbyte is outside the scope of this issue. Changing it caused many tests to fail, but the details have not been investigated. Since IO#ungetbyte changes the file position while IO#ungetc does not, mixing their use is no longer possible. This means that performing ungetbyte after unetc before reading the entire data will cause an exception. /test/ruby/test_io.rb fails due to the above implicit dependency, and /spec/ruby/core/io/ungetc_spec.rb fails due to a test explicitly checking IO#pos. I have no idea about investigating the impact of real-world usage. ## Another approach Do not modify Ruby's behavior. Instead, document that the file position after using IO#ungetc cannot be trusted. Alternatively, it might be possible to issue a warning during specific operations when characters from IO#ungetc remain pending. In these cases, when Windows is switched to use encoding conversion for "r", io_unread() and rb_io_tell() will also take into account the number of bytes in cbuf in addition to rbuf to maintain compatibility. I prefer to minimize code for specific environments, so this is not to my ideal. -- https://bugs.ruby-lang.org/

2 5

[ruby-core:126214] [Ruby Feature#9779] Add Module#descendants
by shugo (Shugo Maeda) 31 Jul '26

31 Jul '26

Issue #9779 has been updated by shugo (Shugo Maeda). I've added specs to the pull request: https://github.com/ruby/ruby/pull/17807/changes/ed81db60a57ec586d4c5300282b… ---------------------------------------- Feature #9779: Add Module#descendants https://bugs.ruby-lang.org/issues/9779#change-118296 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- Now classes have links to their subclasses, so how about to add Module#descendents? ```ruby class X end class Y < X end class Z < Y end p X.descendents #=> [X, Y, Z] module A end module B include A end module C include A end p A.descendents #=> [A, C, B] ``` One of my own use cases is to implement AspectJ like pointcut which matches all subclasses of the given class. Considerations: * Should the return value of Module#descendents include self? * Should the return value of Module#descendents include singleton classes? I attach a patch, where the return value includes both self and singleton classes. ---Files-------------------------------- 0001-Add-Module-descendents.patch (3.75 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126209] [Ruby Bug#15980] Coverage shows while/until after raise if/unless as uncovered line
by ioquatix (Samuel Williams) 31 Jul '26

31 Jul '26

Issue #15980 has been updated by ioquatix (Samuel Williams). Fixed in https://github.com/ruby/ruby/pull/18122 ---------------------------------------- Bug #15980: Coverage shows while/until after raise if/unless as uncovered line https://bugs.ruby-lang.org/issues/15980#change-118287 * Author: jeremyevans0 (Jeremy Evans) * Status: Closed * Assignee: mame (Yusuke Endoh) * ruby -v: ruby 2.7.0dev (2019-07-03) [x86_64-openbsd6.5] * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: DONE ---------------------------------------- The following code shows line 2 (`while true`) as uncovered: ```ruby raise if 1 == 2 while true break end ``` Coverage reports the following for this file: `[1, 0, 1, nil]`. Note that `true` isn't important, any `while` condition will work. However, if you change line 1 to `raise if false`, line 1 shows `nil` coverage, and line 2 shows as covered (`[nil, 1, 1, nil]`). That leads me to believe this issue is related to the optimizer. I bisected this to commit:100bf2757468439106775a7d95a791a8c10b874a, which certainly appears related. This is not a theoretical case, it affected three lines in Sequel. While not a major problem, I do think a fix should be backported to 2.6. Note that this only affects line coverage. Branch coverage shows: ```ruby {"file.rb"=> {:branches=> {[:if, 0, 1, 0, 1, 15]=> {[:then, 1, 1, 0, 1, 5]=>0, [:else, 2, 1, 0, 1, 15]=>1}, [:while, 3, 2, 0, 4, 3]=>{[:body, 4, 3, 2, 3, 7]=>1}}}} ``` If you run with both branch and line coverage, line coverage shows correctly. This affects `while`/`until` after a line with `raise ... if ...` or `raise ... unless ...`. If you switch to `if ...; raise ...; end`, then line coverage shows correctly. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126200] [Ruby Bug#22219] IO::Buffer#free, #resize and #transfer should raise FrozenError if the receiver is frozen
by himura467 (Akito Shitara) 31 Jul '26

31 Jul '26

Issue #22219 has been reported by himura467 (Akito Shitara). ---------------------------------------- Bug #22219: IO::Buffer#free, #resize and #transfer should raise FrozenError if the receiver is frozen https://bugs.ruby-lang.org/issues/22219 * Author: himura467 (Akito Shitara) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Currently `IO::Buffer#free`, `#resize` and `#transfer` can be called even if the receiver is frozen. All three release, reallocate or hand away the memory the buffer references, so they change the state of the buffer. Therefore it seems a bug to me, and these methods should raise `FrozenError` if the receiver is frozen. ```ruby # Current IO::Buffer.new(4).freeze.free # succeeds, the buffer becomes null IO::Buffer.new(4).freeze.resize(8) # succeeds, the memory is reallocated IO::Buffer.new(4).freeze.transfer # succeeds, the receiver becomes null # Expected IO::Buffer.new(4).freeze.free # raise FrozenError IO::Buffer.new(4).freeze.resize(8) # raise FrozenError IO::Buffer.new(4).freeze.transfer # raise FrozenError ``` Methods to fix: * `IO::Buffer#free` * `IO::Buffer#resize` * `IO::Buffer#transfer` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126185] [Ruby Feature#22215] Introduce narrow internal interfaces for bundled extensions
by nobu (Nobuyoshi Nakada) 28 Jul '26

28 Jul '26

Issue #22215 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #22215: Introduce narrow internal interfaces for bundled extensions https://bugs.ruby-lang.org/issues/22215 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- ## Abstract Introduce narrow internal interfaces for bundled extensions so that they do not need to depend on VM implementation headers such as `vm_core.h` or thread implementation files such as `thread_pthread.h`. These interfaces are declared in `internal/` headers and are not intended to be stable APIs for third-party extensions. ## Background Some bundled extensions currently include private implementation headers to access a small part of CRuby internals. For example, `ext/coverage` needs to enumerate method coverage data. Doing that directly requires knowledge of method entries, IMEMOs, the object space, and VM-private structures. Consequently, the extension depends on `internal/gc.h` and `vm_core.h`. Likewise, `ext/objspace` accesses fields of call-info and call-cache IMEMOs directly. These dependencies expose the extensions to much more of the VM implementation than they actually need. They also cause extensions to depend transitively on thread implementation files through `vm_core.h`. ## Proposal Add narrow internal interfaces for the bundled extensions: * Collect coverage constants and declarations in `internal/coverage.h`. * Perform method-entry traversal in the core and pass normalized method coverage data to `ext/coverage` through `rb_coverage_each_method`. * Add `rb_imemo_callinfo_mid` and `rb_imemo_callcache_get_data` for the information required by `ext/objspace`. * Keep these declarations in `internal/` headers rather than public `ruby/` headers. * Remove the transitive inclusion of `vm_core.h` from `internal/gc.h`. The new interfaces must be exported because the bundled extensions can be built as shared libraries. They are internal implementation interfaces, not supported extension APIs. With these interfaces, extensions under `ext` no longer depend on `vm_core.h` or `thread_pthread.[ch]`. ## Compatibility There is no intended Ruby-level behavior change. The new interfaces are internal to CRuby and are not intended to provide API or ABI compatibility guarantees for third-party extensions. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126183] [Ruby Bug#22214] SEGV when struct ractor_port.r is referenced after Ractor::Port.allocate
by himura467 (Akito Shitara) 28 Jul '26

28 Jul '26

Issue #22214 has been reported by himura467 (Akito Shitara). ---------------------------------------- Bug #22214: SEGV when struct ractor_port.r is referenced after Ractor::Port.allocate https://bugs.ruby-lang.org/issues/22214 * Author: himura467 (Akito Shitara) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `Ractor::Port` has a public allocator, so `Ractor::Port.allocate` returns a port whose owner Ractor (`struct ractor_port.r`) is still NULL; only `ractor_port_init()` fills it in. Methods dereference it without a check. ```ruby Ractor::Port.allocate.closed? ``` ``` <internal:ractor>:829: [BUG] Segmentation fault at 0x0000000000000060 ruby 4.1.0dev (2026-07-26T18:55:18Z master eb9d72aea1) +PRISM [arm64-darwin25] -- Ruby level backtrace information ---------------------------------------- -e:1:in '<main>' <internal:ractor>:829:in 'closed?' -- C level backtrace information ------------------------------------------- ruby(rb_native_mutex_lock+0xc) [0x104f922fc] ../thread_pthread.c:127 ruby(ractor_port_closed_p+0x30) [0x104efc2f8] ../ractor.c:74 ruby(builtin_inline_class_829) ../ractor.rb:830 ruby(builtin_invoker0+0x8) [0x104fd76ac] ../vm_insnhelper.c:7392 ``` `#send` and `Ractor#monitor` / `#unmonitor` fault at the same address, `#inspect` at 0x8 in `rb_ractor_id()`. `#receive` and `#close` happen to raise `Ractor::Error`, but only because their `rp->r != current ractor` check catches NULL by accident, so they report the port as belonging to another Ractor. `Ractor.select` does not crash, because `ractor_try_receive()` keys only on `rp->id_`. That field is 0 for an uninitialized port, which is also the id of the current Ractor's default port, so the port takes messages from it: ```ruby port = Ractor::Port.allocate Ractor.current.default_port.send(:hello) p Ractor.select(port)[1] #=> :hello ``` -- https://bugs.ruby-lang.org/

1 1