July 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:125705] [Ruby Bug#22105] Cannot initialize a WeakRef in a Ractor
by miles-georgi (Miles Georgi) 28 Jul '26

28 Jul '26

Issue #22105 has been reported by miles-georgi (Miles Georgi). ---------------------------------------- Bug #22105: Cannot initialize a WeakRef in a Ractor https://bugs.ruby-lang.org/issues/22105 * Author: miles-georgi (Miles Georgi) * Status: Open * ruby -v: ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hey hey! If I try to create a WeakRef in a Ractor, like in this script: ``` ruby require "weakref" Ractor.new { WeakRef.new("asdf") }.join ``` Then I get this error: ``` 4.1-dev/lib/ruby/4.1.0+3/weakref.rb:40:in 'WeakRef#initialize': can not read non-shareable class variable @@__map from non-main Ractors (WeakRef) (Ractor::IsolationError) ``` This happens in both a local build of 4.1-dev and 4.0.5 and likely other versions. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126181] [Ruby Bug#18947] Unexpected Errno::ENAMETOOLONG on Windows
by hsbt (Hiroshi SHIBATA) 28 Jul '26

28 Jul '26

Issue #18947 has been updated by hsbt (Hiroshi SHIBATA). https://github.com/ruby/ruby/pull/18088 ---------------------------------------- Bug #18947: Unexpected Errno::ENAMETOOLONG on Windows https://bugs.ruby-lang.org/issues/18947#change-118257 * 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:126180] [Ruby Bug#18947] Unexpected Errno::ENAMETOOLONG on Windows
by hsbt (Hiroshi SHIBATA) 28 Jul '26

28 Jul '26

Issue #18947 has been updated by hsbt (Hiroshi SHIBATA). There is another way that does not need the registry key. Go's runtime sets the undocumented `IsLongPathAwareProcess` bit (0x80 at PEB offset 3) at startup, which `RtlAreLongPathsEnabled` reads, so long paths work per-process regardless of `LongPathsEnabled` ([os_windows.go](https://go.dev/src/runtime/os_windows.go), Windows 10.0.15063+). I tried it on my machine with `LongPathsEnabled=0` and 260+ character paths worked for `File`, `Dir`, `Dir.glob`, `require`, and even `Dir.chdir`, which `\\?\` cannot handle. Being undocumented is the obvious catch ([golang/go#66560](https://github.com/golang/go/issues/66560)) and the 255 character limit per component stays. ---------------------------------------- Bug #18947: Unexpected Errno::ENAMETOOLONG on Windows https://bugs.ruby-lang.org/issues/18947#change-118254 * 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:112045] [Ruby master Bug#19378] Windows: Use less syscalls for faster require of big gems
by aidog (Andi Idogawa) 27 Jul '26

27 Jul '26

Issue #19378 has been reported by aidog (Andi Idogawa). ---------------------------------------- Bug #19378: Windows: Use less syscalls for faster require of big gems https://bugs.ruby-lang.org/issues/19378 * Author: aidog (Andi Idogawa) * Status: Open * Priority: Normal * ruby -v: 3.2.0 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hello 🙂 ## Problem require is slow on windows for big gems. (example: require 'gtk3'=> 3 seconds+). This is a problem for people who want to make cross platform GUI apps with ruby. ## Possible Reason As touched on in [#15797](https://bugs.ruby-lang.org/issues/15797) it seems like require uses realpath, which is emulated on windows. It checks every parent directory. The same syscalls run many times. ## Testfile C:\tmp\speedtest\testrequire.rb: ``` ruby require __dir__ + "/helloworld1.rb" require __dir__ + "/helloworld2.rb" ``` ``` shell ruby --disable-gems C:\tmp\speedtest\testrequire.rb ``` ### Syscalls per File/Directory: 1. CreateFile 2. QueryInformationVolume 3. QueryIdInformation 4. QueryAllInformationFile 5. QueryNameInformationFile 6. QueryNameInformationFile 7. QueryNormalizedNameInformationFile 8. CloseFile ### Files/Directories checked 1. C:\tmp 2. C:\tmp\speedtest 3. C:\tmp\speedtest\helloworld1.rb 4. C:\tmp 5. C:\tmp\speedtest 6. C:\tmp\speedtest\helloworld2.rb For two required files Ruby had to do 8*6 = **48** syscalls. The syscalls orginate from rb_w32_reparse_symlink_p / lstat Rubygems live in subfolders with 9+ parts: "C:\Ruby32-x64\lib\ruby\gems\3.2.0\gems\glib2-4.0.8\lib\glib2\variant.rb" Each file takes 8 * 9 = **72**+ calls. For variant.rb it is **80** calls. The result for the syscalls don't change in such a short time, so it should be possible to cache it. With require_relative it's twice as many calls. ## Other testcases Same result: ``` ruby File.realpath __dir__ + "/helloworld1.rb" File.realpath __dir__ + "/helloworld2.rb" ``` ``` ruby File.stat __dir__ + "/helloworld1.rb" File.stat __dir__ + "/helloworld2.rb" ``` It does not happen in $LOAD_PATH.resolve_feature_path(__dir__ + "/helloworld1.rb") ## Request Would it be possible to cache the stat calls when using require? I tried to implement a cache inside the ruby source code, but failed. If not, is there now a way to combine ruby files into one? I previously talked about require here: [YJIT: Windows support lacking.](https://bugs.ruby-lang.org/issues/19325#note-11) ## How to reproduce Ruby versions: At least 3.0+, most likely older ones too. Tested using Ruby Installer 3.1 and 3.2. [Procmon Software by Sysinternals](https://learn.microsoft.com/en-us/sysinternals/downloads/proc… -- https://bugs.ruby-lang.org/

6 9

[ruby-core:125704] [Ruby Bug#22104] Segfault in PRISM compiler while Bootsnap compiles aws-sdk client_api.rb
by Morred (Laura Eck) 27 Jul '26

27 Jul '26

Issue #22104 has been reported by Morred (Laura Eck). ---------------------------------------- Bug #22104: Segfault in PRISM compiler while Bootsnap compiles aws-sdk client_api.rb https://bugs.ruby-lang.org/issues/22104 * Author: Morred (Laura Eck) * Status: Open * ruby -v: 4.0.4 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I'm seeing intermittent segmentation faults on aarch64-linux when Ruby compiles large auto-generated AWS SDK files, triggered through Bootsnap's ISeq compile cache. Observed while compiling: aws-sdk-dynamodb-*/lib/aws-sdk-dynamodb/client_api.rb aws-sdk-rds-*/lib/aws-sdk-rds/client_api.rb **Environment:** ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +YJIT +PRISM [aarch64-linux] I'm attaching two full backtraces including C level backtrace information: **Backtrace 1:** ``` /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-dynamodb-1.165.0/lib/aws-sdk-dynamodb/client_api.rb: [BUG] Segmentation fault at 0x0000aaab1cc9e000 ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +YJIT +PRISM [aarch64-linux] -- Control frame information ----------------------------------------------- c:0073 p:---- s:0441 e:000440 l:y b:---- DUMMY [FINISH] c:0072 p:---- s:0438 e:000437 l:y b:---- CFUNC :compile_file c:0071 p:0009 s:0432 e:000431 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/compile_cache/iseq.rb:77 [FINISH] c:0070 p:---- s:0426 e:000425 l:y b:---- CFUNC :fetch c:0069 p:0106 s:0417 e:000416 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/compile_cache/iseq.rb:135 c:0068 p:0008 s:0409 e:000408 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/compile_cache/iseq.rb:166 [FINISH] c:0067 p:---- s:0403 e:000402 l:y b:---- CFUNC :require c:0066 p:0033 s:0398 e:000397 l:n b:---- BLOCK /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60 c:0065 p:0145 s:0392 e:000391 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33 c:0064 p:0057 s:0383 e:000382 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/core_ext/kernel.rb:34 [FINISH] c:0063 p:0014 s:0375 e:000373 l:y b:0001 CLASS /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-dynamodb-1.165.0/lib/aws-sdk-dynamodb/client.rb:61 c:0062 p:0008 s:0371 e:000370 l:y b:0001 CLASS /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-dynamodb-1.165.0/lib/aws-sdk-dynamodb/client.rb:55 c:0061 p:0193 s:0368 e:000367 l:y b:0001 TOP /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-dynamodb-1.165.0/lib/aws-sdk-dynamodb/client.rb:42 [FINISH] c:0060 p:---- s:0365 e:000364 l:y b:---- CFUNC :require c:0059 p:0033 s:0360 e:000359 l:n b:---- BLOCK /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60 c:0058 p:0145 s:0354 e:000353 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33 c:0057 p:0057 s:0345 e:000344 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/core_ext/kernel.rb:34 [FINISH] c:0056 p:0007 s:0337 e:000336 l:y b:0001 CLASS /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-dynamodb-1.165.0/lib/aws-sdk-dynamodb/customizations/client.rb:5 c:0055 p:0007 s:0334 e:000333 l:y b:0001 CLASS /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-dynamodb-1.165.0/lib/aws-sdk-dynamodb/customizations/client.rb:4 c:0054 p:0007 s:0331 e:000330 l:y b:0001 TOP /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-dynamodb-1.165.0/lib/aws-sdk-dynamodb/customizations/client.rb:3 [FINISH] c:0053 p:---- s:0328 e:000327 l:y b:---- CFUNC :require c:0052 p:0033 s:0323 e:000322 l:n b:---- BLOCK /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60 c:0051 p:0145 s:0317 e:000316 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33 c:0050 p:0057 s:0308 e:000307 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/core_ext/kernel.rb:34 c:0049 p:0011 s:0300 e:000299 l:y b:0001 TOP /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-dynamodb-1.165.0/lib/aws-sdk-dynamodb/customizations.rb:4 [FINISH] c:0048 p:---- s:0297 e:000296 l:y b:---- CFUNC :require_relative c:0047 p:0032 s:0292 e:000291 l:y b:0001 TOP /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-dynamodb-1.165.0/lib/aws-sdk-dynamodb.rb:63 [FINISH] c:0046 p:---- s:0289 e:000288 l:y b:---- CFUNC :require c:0045 p:0033 s:0284 e:000283 l:n b:---- BLOCK /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60 c:0044 p:0145 s:0278 e:000277 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33 c:0043 p:0057 s:0269 e:000268 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/core_ext/kernel.rb:34 c:0042 p:0005 s:0261 e:000260 l:y b:0001 TOP /jeancaisse/packs/utils/app/lib/aws/dynamo_d_b.rb:3 [FINISH] c:0041 p:---- s:0258 e:000257 l:y b:---- CFUNC :require c:0040 p:0033 s:0253 e:000252 l:n b:---- BLOCK /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60 c:0039 p:0145 s:0247 e:000246 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33 c:0038 p:0026 s:0238 e:000237 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/core_ext/kernel.rb:26 [FINISH] c:0037 p:---- s:0230 e:000229 l:y b:---- CFUNC :const_get c:0036 p:0010 s:0224 e:000223 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/cref.rb:62 c:0035 p:0039 s:0220 e:000219 l:n b:---- BLOCK /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:175 c:0034 p:0063 s:0212 e:000211 l:n b:---- BLOCK /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/file_system.rb:51 [FINISH] c:0033 p:0027 s:0206 e:000205 l:y b:0001 METHOD <internal:array>:228 c:0032 p:0020 s:0200 e:000199 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/file_system.rb:40 c:0031 p:0048 s:0191 e:000190 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:170 c:0030 p:0010 s:0180 e:000179 l:n b:---- BLOCK /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:18 [FINISH] c:0029 p:---- s:0175 e:000174 l:y b:---- CFUNC :each c:0028 p:0032 s:0171 e:000170 l:n b:---- BLOCK /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:17 [FINISH] c:0027 p:0018 s:0168 e:000167 l:y b:0001 METHOD <internal:thread_sync>:130 c:0026 p:0006 s:0164 e:000163 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:11 c:0025 p:0005 s:0158 e:000157 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/autoloaders.rb:32 c:0024 p:0009 s:0154 e:000153 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/application.rb:556 c:0023 p:0085 s:0150 e:000149 l:y b:0001 METHOD /jeancaisse/spec/account_copy_e2e_tests.rb:91 c:0022 p:0019 s:0137 e:000136 l:n b:---- BLOCK /jeancaisse/spec/account_copy_e2e_tests.rb:128 c:0021 p:0006 s:0134 e:000133 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/rspec-mocks-3.13.8/lib/rspec/mocks.rb:96 c:0020 p:0043 s:0129 E:002088 l:y b:0001 TOP /jeancaisse/spec/account_copy_e2e_tests.rb:127 [FINISH] c:0019 p:---- s:0125 e:000124 l:y b:---- CFUNC :load c:0018 p:0006 s:0120 e:000119 l:n b:---- BLOCK /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/commands/runner/runner_command.rb:44 c:0017 p:0015 s:0117 e:000116 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/activesupport-8.1.3/lib/active_support/execution_wrapper.rb:91 c:0016 p:0019 s:0109 e:000108 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/commands/runner/runner_command.rb:70 c:0015 p:0090 s:0102 e:000101 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/commands/runner/runner_command.rb:43 c:0014 p:0054 s:0093 e:000092 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/thor-1.5.0/lib/thor/command.rb:28 c:0013 p:0040 s:0085 e:000084 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/thor-1.5.0/lib/thor/invocation.rb:127 c:0012 p:0032 s:0078 e:000077 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/command/base.rb:176 c:0011 p:0246 s:0071 e:000070 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/thor-1.5.0/lib/thor.rb:538 c:0010 p:0049 s:0058 e:000057 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/command/base.rb:71 c:0009 p:0024 s:0051 e:000050 l:n b:---- BLOCK /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/command.rb:65 c:0008 p:0015 s:0048 e:000047 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/command.rb:143 c:0007 p:0048 s:0042 e:000041 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/command.rb:63 c:0006 p:0038 s:0031 e:000030 l:y b:0001 TOP /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/commands.rb:18 [FINISH] c:0005 p:---- s:0026 e:000025 l:y b:---- CFUNC :require c:0004 p:0033 s:0021 e:000020 l:n b:---- BLOCK /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60 c:0003 p:0145 s:0015 e:000014 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33 c:0002 p:0024 s:0006 e:000005 l:n b:---- EVAL bin/rails:6 [FINISH] c:0001 p:0000 s:0003 E:0019e0 l:y b:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- bin/rails:6:in '<main>' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in 'require' /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/commands.rb:18:in '<main>' /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/command.rb:63:in 'invoke' /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/command.rb:143:in 'with_argv' /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/command.rb:65:in 'block in invoke' /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/command/base.rb:71:in 'perform' /usr/local/bundle/ruby/4.0.0/gems/thor-1.5.0/lib/thor.rb:538:in 'dispatch' /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/command/base.rb:176:in 'invoke_command' /usr/local/bundle/ruby/4.0.0/gems/thor-1.5.0/lib/thor/invocation.rb:127:in 'invoke_command' /usr/local/bundle/ruby/4.0.0/gems/thor-1.5.0/lib/thor/command.rb:28:in 'run' /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/commands/runner/runner_command.rb:43:in 'perform' /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/commands/runner/runner_command.rb:70:in 'conditional_executor' /usr/local/bundle/ruby/4.0.0/gems/activesupport-8.1.3/lib/active_support/execution_wrapper.rb:91:in 'wrap' /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/commands/runner/runner_command.rb:44:in 'block in perform' /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/commands/runner/runner_command.rb:44:in 'load' /jeancaisse/spec/account_copy_e2e_tests.rb:127:in '<main>' /usr/local/bundle/ruby/4.0.0/gems/rspec-mocks-3.13.8/lib/rspec/mocks.rb:96:in 'with_temporary_scope' /jeancaisse/spec/account_copy_e2e_tests.rb:128:in 'block in <main>' /jeancaisse/spec/account_copy_e2e_tests.rb:91:in 'run' /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/application.rb:556:in 'eager_load!' /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/autoloaders.rb:32:in 'each' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:11:in 'eager_load' <internal:thread_sync>:130:in 'synchronize' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:17:in 'block in eager_load' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:17:in 'each' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:18:in 'block (2 levels) in eager_load' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:170:in 'actual_eager_load_dir' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/file_system.rb:40:in 'ls' <internal:array>:228:in 'each' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/file_system.rb:51:in 'block in ls' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:175:in 'block in actual_eager_load_dir' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/cref.rb:62:in 'get' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/cref.rb:62:in 'const_get' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/core_ext/kernel.rb:26:in 'require' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in 'require' /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' /jeancaisse/packs/utils/app/lib/aws/dynamo_d_b.rb:3:in '<main>' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/core_ext/kernel.rb:34:in 'require' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in 'require' /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-dynamodb-1.165.0/lib/aws-sdk-dynamodb.rb:63:in '<main>' /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-dynamodb-1.165.0/lib/aws-sdk-dynamodb.rb:63:in 'require_relative' /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-dynamodb-1.165.0/lib/aws-sdk-dynamodb/customizations.rb:4:in '<main>' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/core_ext/kernel.rb:34:in 'require' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in 'require' /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-dynamodb-1.165.0/lib/aws-sdk-dynamodb/customizations/client.rb:3:in '<main>' /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-dynamodb-1.165.0/lib/aws-sdk-dynamodb/customizations/client.rb:4:in '<module:Aws>' /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-dynamodb-1.165.0/lib/aws-sdk-dynamodb/customizations/client.rb:5:in '<module:DynamoDB>' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/core_ext/kernel.rb:34:in 'require' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in 'require' /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-dynamodb-1.165.0/lib/aws-sdk-dynamodb/client.rb:42:in '<main>' /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-dynamodb-1.165.0/lib/aws-sdk-dynamodb/client.rb:55:in '<module:DynamoDB>' /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-dynamodb-1.165.0/lib/aws-sdk-dynamodb/client.rb:61:in '<class:Client>' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/core_ext/kernel.rb:34:in 'require' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in 'require' /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/compile_cache/iseq.rb:166:in 'load_iseq' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/compile_cache/iseq.rb:135:in 'fetch' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/compile_cache/iseq.rb:135:in 'fetch' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/compile_cache/iseq.rb:77:in 'input_to_storage' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.4/lib/bootsnap/compile_cache/iseq.rb:77:in 'compile_file' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 3 -- Machine register context ------------------------------------------------ x0: 0x0415f704e8c1b50c x1: 0x30e2222405b75990 x2: 0x4cf5ad432745937f x3: 0x87c37b91114253d5 x4: 0x0000ffffa33963b0 x5: 0x0000000000000000 x6: 0x0000aaaaef82a400 x7: 0x0000aaab1c626b50 x18: 0x0000aaaaef82a778 x19: 0x0000aaab1cc9dff8 x20: 0x0000aaabffa64400 x21: 0x0000ffffde70e050 x22: 0x0000aaaaef830c20 x23: 0x0000ffffa33d5000 x24: 0x0000ffffa2ed3020 x25: 0x0000ffffde70e050 x26: 0x0000aaab1c67d480 x27: 0x0000000000000049 x28: 0x0000000000000001 x29: 0x0000ffffde70dfa0 sp: 0x0000ffffde70dfa0 fau: 0x0000aaab1cc9e000 -- C level backtrace information ------------------------------------------- /usr/local/lib/libruby.so.4.0(fprintf+0x0) [0xffffa2f123f4] /usr/src/ruby/vm_dump.c:1105 /usr/local/lib/libruby.so.4.0(rb_vm_bugreport) /usr/src/ruby/vm_dump.c:1453 /usr/local/lib/libruby.so.4.0(rb_bug_for_fatal_signal+0xd4) [0xffffa2cddc04] /usr/src/ruby/error.c:1131 /usr/local/lib/libruby.so.4.0(sigsegv+0x58) [0xffffa2e48328] /usr/src/ruby/signal.c:948 linux-vdso.so.1(__kernel_rt_sigreturn+0x0) [0xffffa3424838] /usr/local/lib/libruby.so.4.0(vm_ci_hash+0x50) [0xffffa2ed3800] /usr/src/ruby/vm_method.c:632 /usr/local/lib/libruby.so.4.0(normalize_hash_value+0x0) [0xffffa2e546a0] /usr/src/ruby/st.c:331 /usr/local/lib/libruby.so.4.0(do_hash) /usr/src/ruby/st.c:332 /usr/local/lib/libruby.so.4.0(rb_st_update) /usr/src/ruby/st.c:1472 /usr/local/lib/libruby.so.4.0(rb_vm_ci_lookup+0xac) [0xffffa2edd038] /usr/src/ruby/vm_method.c:712 /usr/local/lib/libruby.so.4.0(vm_ci_new_+0x4) [0xffffa2c4c208] /usr/src/ruby/vm_callinfo.h:219 /usr/local/lib/libruby.so.4.0(new_callinfo) /usr/src/ruby/compile.c:1486 /usr/local/lib/libruby.so.4.0(new_insn_send+0xfc) [0xffffa2c4e848] /usr/src/ruby/compile.c:1495 /usr/local/lib/libruby.so.4.0(ADD_ELEM+0x0) [0xffffa2c959d0] /usr/src/ruby/prism_compile.c:3789 /usr/local/lib/libruby.so.4.0(pm_compile_call) /usr/src/ruby/prism_compile.c:3789 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x1218) [0xffffa2c83598] /usr/src/ruby/prism_compile.c:8790 /usr/local/lib/libruby.so.4.0(pm_compile_constant_write_node+0x12c) [0xffffa2c91bcc] /usr/src/ruby/prism_compile.c:5809 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x54c) [0xffffa2c828cc] /usr/src/ruby/prism_compile.c:9055 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x3698) [0xffffa2c85a18] /usr/src/ruby/prism_compile.c:10324 /usr/local/lib/libruby.so.4.0(pm_compile_scope_node+0x1b0c) [0xffffa2c9c974] /usr/src/ruby/prism_compile.c:7044 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x1a00) [0xffffa2c83d80] /usr/src/ruby/prism_compile.c:10197 /usr/local/lib/libruby.so.4.0(pm_iseq_compile_node+0x60) [0xffffa2c9e240] /usr/src/ruby/prism_compile.c:10508 /usr/local/lib/libruby.so.4.0(pm_iseq_new_with_opt_try+0x1c) [0xffffa2d576fc] /usr/src/ruby/iseq.c:1105 /usr/local/lib/libruby.so.4.0(rb_protect+0xb8) [0xffffa2ce9d58] /usr/src/ruby/eval.c:1127 /usr/local/lib/libruby.so.4.0(pm_iseq_new_with_opt+0x150) [0xffffa2d50138] /usr/src/ruby/iseq.c:1158 /usr/local/lib/libruby.so.4.0(pm_new_child_iseq+0xb8) [0xffffa2c4a440] /usr/src/ruby/prism_compile.c:1276 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x328c) [0xffffa2c8560c] /usr/src/ruby/prism_compile.c:9869 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x36c8) [0xffffa2c85a48] /usr/src/ruby/prism_compile.c:10326 /usr/local/lib/libruby.so.4.0(pm_compile_scope_node+0x1b0c) [0xffffa2c9c974] /usr/src/ruby/prism_compile.c:7044 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x1a00) [0xffffa2c83d80] /usr/src/ruby/prism_compile.c:10197 /usr/local/lib/libruby.so.4.0(pm_iseq_compile_node+0x60) [0xffffa2c9e240] /usr/src/ruby/prism_compile.c:10508 /usr/local/lib/libruby.so.4.0(pm_iseq_new_with_opt_try+0x1c) [0xffffa2d576fc] /usr/src/ruby/iseq.c:1105 /usr/local/lib/libruby.so.4.0(rb_protect+0xb8) [0xffffa2ce9d58] /usr/src/ruby/eval.c:1127 /usr/local/lib/libruby.so.4.0(pm_iseq_new_with_opt+0x150) [0xffffa2d50138] /usr/src/ruby/iseq.c:1158 /usr/local/lib/libruby.so.4.0(pm_new_child_iseq+0xb8) [0xffffa2c4a440] /usr/src/ruby/prism_compile.c:1276 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x328c) [0xffffa2c8560c] /usr/src/ruby/prism_compile.c:9869 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x36c8) [0xffffa2c85a48] /usr/src/ruby/prism_compile.c:10326 /usr/local/lib/libruby.so.4.0(pm_compile_scope_node+0x1b0c) [0xffffa2c9c974] /usr/src/ruby/prism_compile.c:7044 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x1a00) [0xffffa2c83d80] /usr/src/ruby/prism_compile.c:10197 /usr/local/lib/libruby.so.4.0(APPEND_LIST+0x0) [0xffffa2c9e2b4] /usr/src/ruby/prism_compile.c:10498 /usr/local/lib/libruby.so.4.0(pm_iseq_compile_node) /usr/src/ruby/prism_compile.c:10502 /usr/local/lib/libruby.so.4.0(pm_iseq_new_with_opt_try+0x1c) [0xffffa2d576fc] /usr/src/ruby/iseq.c:1105 /usr/local/lib/libruby.so.4.0(rb_protect+0xb8) [0xffffa2ce9d58] /usr/src/ruby/eval.c:1127 /usr/local/lib/libruby.so.4.0(pm_iseq_new_with_opt+0x150) [0xffffa2d50138] /usr/src/ruby/iseq.c:1158 /usr/local/lib/libruby.so.4.0(iseqw_s_compile_file_prism+0x1c4) [0xffffa2d5076c] /usr/src/ruby/iseq.c:1925 [0xffff602d3254] ``` **Backtrace 2:** ``` /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-rds-1.314.0/lib/aws-sdk-rds/client_api.rb: [BUG] Segmentation fault at 0x0000aaab3c709000 ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +YJIT +PRISM [aarch64-linux] -- Control frame information ----------------------------------------------- c:0061 p:---- s:0367 e:000366 l:y b:---- DUMMY [FINISH] c:0060 p:---- s:0364 e:000363 l:y b:---- CFUNC :compile_file c:0059 p:0009 s:0358 e:000357 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.6/lib/bootsnap/compile_cache/iseq.rb:91 [FINISH] c:0058 p:---- s:0352 e:000351 l:y b:---- CFUNC :fetch c:0057 p:0099 s:0343 e:000342 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.6/lib/bootsnap/compile_cache/iseq.rb:154 c:0056 p:0008 s:0335 e:000334 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.6/lib/bootsnap/compile_cache/iseq.rb:185 [FINISH] c:0055 p:---- s:0329 e:000328 l:y b:---- CFUNC :require c:0054 p:0033 s:0324 e:000323 l:n b:---- BLOCK /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60 c:0053 p:0145 s:0318 e:000317 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33 c:0052 p:0057 s:0309 e:000308 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/core_ext/kernel.rb:34 [FINISH] c:0051 p:0014 s:0301 e:000299 l:y b:0001 CLASS /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-rds-1.314.0/lib/aws-sdk-rds/client.rb:59 c:0050 p:0008 s:0297 e:000296 l:y b:0001 CLASS /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-rds-1.314.0/lib/aws-sdk-rds/client.rb:53 c:0049 p:0181 s:0294 e:000293 l:y b:0001 TOP /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-rds-1.314.0/lib/aws-sdk-rds/client.rb:40 [FINISH] c:0048 p:---- s:0291 e:000290 l:y b:---- CFUNC :require c:0047 p:0033 s:0286 e:000285 l:n b:---- BLOCK /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60 c:0046 p:0145 s:0280 e:000279 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33 c:0045 p:0057 s:0271 e:000270 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/core_ext/kernel.rb:34 [FINISH] c:0044 p:0017 s:0263 e:000262 l:y b:0001 TOP /jeancaisse/packs/utils/app/lib/aws/rds.rb:12 [FINISH] c:0043 p:---- s:0260 e:000259 l:y b:---- CFUNC :require c:0042 p:0033 s:0255 e:000254 l:n b:---- BLOCK /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60 c:0041 p:0145 s:0249 e:000248 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33 c:0040 p:0026 s:0240 e:000239 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/core_ext/kernel.rb:26 [FINISH] c:0039 p:---- s:0232 e:000231 l:y b:---- CFUNC :const_get c:0038 p:0010 s:0226 e:000225 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/cref.rb:62 c:0037 p:0039 s:0222 e:000221 l:n b:---- BLOCK /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:175 c:0036 p:0063 s:0214 e:000213 l:n b:---- BLOCK /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/file_system.rb:51 [FINISH] c:0035 p:0027 s:0208 e:000207 l:y b:0001 METHOD <internal:array>:228 c:0034 p:0020 s:0202 e:000201 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/file_system.rb:40 c:0033 p:0048 s:0193 e:000192 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:170 c:0032 p:0010 s:0182 e:000181 l:n b:---- BLOCK /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:18 [FINISH] c:0031 p:---- s:0177 e:000176 l:y b:---- CFUNC :each c:0030 p:0032 s:0173 e:000172 l:n b:---- BLOCK /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:17 [FINISH] c:0029 p:0018 s:0170 e:000169 l:y b:0001 METHOD <internal:thread_sync>:130 c:0028 p:0006 s:0166 e:000165 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:11 c:0027 p:0005 s:0160 e:000159 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/autoloaders.rb:32 c:0026 p:0009 s:0156 e:000155 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/application.rb:556 c:0025 p:0014 s:0152 e:000151 l:y b:0001 METHOD /jeancaisse/spec/support/eager_load.rb:29 c:0024 p:0132 s:0143 e:000142 l:n b:---- BLOCK /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:273 c:0023 p:0013 s:0132 E:000fa0 l:n b:---- BLOCK /jeancaisse/spec/config/initializers/0_custom_load_hooks_spec.rb:8 [FINISH] c:0022 p:---- s:0129 e:000128 l:y b:---- CFUNC :module_exec c:0021 p:0047 s:0125 e:000124 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:405 c:0020 p:0012 s:0115 e:000114 l:n b:---- BLOCK /jeancaisse/spec/support/eager_load.rb:30 c:0019 p:0023 s:0112 e:000111 l:y b:0001 METHOD /jeancaisse/spec/support/eager_load.rb:10 c:0018 p:0020 s:0107 e:000106 l:y b:0001 METHOD /jeancaisse/spec/support/eager_load.rb:30 c:0017 p:0132 s:0098 e:000097 l:n b:---- BLOCK /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:273 c:0016 p:0013 s:0087 e:000086 l:n b:---- BLOCK /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/dsl.rb:43 c:0015 p:0014 s:0080 e:000079 l:n b:---- BLOCK /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/dsl.rb:84 c:0014 p:0006 s:0074 E:000aa0 l:y b:0001 TOP /jeancaisse/spec/config/initializers/0_custom_load_hooks_spec.rb:3 [FINISH] c:0013 p:---- s:0071 e:000070 l:y b:---- CFUNC :load c:0012 p:0007 s:0066 e:000065 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/configuration.rb:2144 c:0011 p:0015 s:0057 e:000056 l:n b:---- BLOCK /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/configuration.rb:1643 [FINISH] c:0010 p:0027 s:0052 e:000051 l:y b:0001 METHOD <internal:array>:228 c:0009 p:0017 s:0046 e:000045 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/configuration.rb:1641 c:0008 p:0029 s:0042 e:000041 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:102 c:0007 p:0007 s:0036 e:000035 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:86 c:0006 p:0080 s:0030 e:000029 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:71 c:0005 p:0013 s:0022 e:000021 l:y b:0001 METHOD /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:45 c:0004 p:0010 s:0017 e:000016 l:y b:0001 TOP /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/exe/rspec:4 [FINISH] c:0003 p:---- s:0014 e:000013 l:y b:---- CFUNC :load c:0002 p:0301 s:0009 E:002438 l:n b:---- EVAL bin/rspec:59 [FINISH] c:0001 p:0000 s:0003 E:001170 l:y b:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- bin/rspec:59:in '<main>' bin/rspec:59:in 'load' /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/exe/rspec:4:in '<top (required)>' /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:45:in 'invoke' /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:71:in 'run' /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:86:in 'run' /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:102:in 'setup' /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/configuration.rb:1641:in 'load_spec_files' <internal:array>:228:in 'each' /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/configuration.rb:1643:in 'block in load_spec_files' /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/configuration.rb:2144:in 'load_file_handling_errors' /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/configuration.rb:2144:in 'load' /jeancaisse/spec/config/initializers/0_custom_load_hooks_spec.rb:3:in '<main>' /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/dsl.rb:84:in 'block (2 levels) in expose_example_group_alias_globally' /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/dsl.rb:43:in 'block in expose_example_group_alias' /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:273:in 'block in define_example_group_method' /jeancaisse/spec/support/eager_load.rb:30:in 'subclass' /jeancaisse/spec/support/eager_load.rb:10:in 'within_eager_load_example_group' /jeancaisse/spec/support/eager_load.rb:30:in 'block in subclass' /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:405:in 'subclass' /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:405:in 'module_exec' /jeancaisse/spec/config/initializers/0_custom_load_hooks_spec.rb:8:in 'block in <main>' /usr/local/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:273:in 'block in define_example_group_method' /jeancaisse/spec/support/eager_load.rb:29:in 'subclass' /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/application.rb:556:in 'eager_load!' /usr/local/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/autoloaders.rb:32:in 'each' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:11:in 'eager_load' <internal:thread_sync>:130:in 'synchronize' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:17:in 'block in eager_load' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:17:in 'each' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:18:in 'block (2 levels) in eager_load' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:170:in 'actual_eager_load_dir' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/file_system.rb:40:in 'ls' <internal:array>:228:in 'each' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/file_system.rb:51:in 'block in ls' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/loader/eager_load.rb:175:in 'block in actual_eager_load_dir' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/cref.rb:62:in 'get' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/cref.rb:62:in 'const_get' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/core_ext/kernel.rb:26:in 'require' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in 'require' /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' /jeancaisse/packs/utils/app/lib/aws/rds.rb:12:in '<main>' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/core_ext/kernel.rb:34:in 'require' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in 'require' /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-rds-1.314.0/lib/aws-sdk-rds/client.rb:40:in '<main>' /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-rds-1.314.0/lib/aws-sdk-rds/client.rb:53:in '<module:RDS>' /usr/local/bundle/ruby/4.0.0/gems/aws-sdk-rds-1.314.0/lib/aws-sdk-rds/client.rb:59:in '<class:Client>' /usr/local/bundle/ruby/4.0.0/gems/zeitwerk-2.8.0/lib/zeitwerk/core_ext/kernel.rb:34:in 'require' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in 'require' /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' /usr/local/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.6/lib/bootsnap/compile_cache/iseq.rb:185:in 'load_iseq' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.6/lib/bootsnap/compile_cache/iseq.rb:154:in 'fetch' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.6/lib/bootsnap/compile_cache/iseq.rb:154:in 'fetch' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.6/lib/bootsnap/compile_cache/iseq.rb:91:in 'input_to_storage' /usr/local/bundle/ruby/4.0.0/gems/bootsnap-1.24.6/lib/bootsnap/compile_cache/iseq.rb:91:in 'compile_file' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 3 -- Machine register context ------------------------------------------------ x0: 0xbd7a2588f4a9410c x1: 0xf19e26916fea2c46 x2: 0x4cf5ad432745937f x3: 0x87c37b91114253d5 x4: 0x0000ffffb68963b0 x5: 0x0000000000000000 x6: 0x0000aaab0d7d0400 x7: 0x0000aaab3c026af0 x18: 0x0000aaab0d7d0778 x19: 0x0000aaab3c708ff8 x20: 0x0000aaad0c2c1180 x21: 0x0000ffffc6ff6dd0 x22: 0x0000aaab0d7d6c20 x23: 0x0000ffffb68d5000 x24: 0x0000ffffb63d3020 x25: 0x0000ffffc6ff6dd0 x26: 0x0000aaab3a3dcf00 x27: 0x0000000000000041 x28: 0x0000000000000001 x29: 0x0000ffffc6ff6d20 sp: 0x0000ffffc6ff6d20 fau: 0x0000aaab3c709000 -- C level backtrace information ------------------------------------------- /usr/local/lib/libruby.so.4.0(fprintf+0x0) [0xffffb64123f4] /usr/src/ruby/vm_dump.c:1105 /usr/local/lib/libruby.so.4.0(rb_vm_bugreport) /usr/src/ruby/vm_dump.c:1453 /usr/local/lib/libruby.so.4.0(rb_bug_for_fatal_signal+0xd4) [0xffffb61ddc04] /usr/src/ruby/error.c:1131 /usr/local/lib/libruby.so.4.0(sigsegv+0x58) [0xffffb6348328] /usr/src/ruby/signal.c:948 linux-vdso.so.1(__kernel_rt_sigreturn+0x0) [0xffffb691b838] /usr/local/lib/libruby.so.4.0(vm_ci_hash+0x50) [0xffffb63d3800] /usr/src/ruby/vm_method.c:632 /usr/local/lib/libruby.so.4.0(normalize_hash_value+0x0) [0xffffb63546a0] /usr/src/ruby/st.c:331 /usr/local/lib/libruby.so.4.0(do_hash) /usr/src/ruby/st.c:332 /usr/local/lib/libruby.so.4.0(rb_st_update) /usr/src/ruby/st.c:1472 /usr/local/lib/libruby.so.4.0(rb_vm_ci_lookup+0xac) [0xffffb63dd038] /usr/src/ruby/vm_method.c:712 /usr/local/lib/libruby.so.4.0(vm_ci_new_+0x4) [0xffffb614c208] /usr/src/ruby/vm_callinfo.h:219 /usr/local/lib/libruby.so.4.0(new_callinfo) /usr/src/ruby/compile.c:1486 /usr/local/lib/libruby.so.4.0(new_insn_send+0xfc) [0xffffb614e848] /usr/src/ruby/compile.c:1495 /usr/local/lib/libruby.so.4.0(pm_compile_call+0x930) [0xffffb6195a58] /usr/src/ruby/prism_compile.c:3794 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x1218) [0xffffb6183598] /usr/src/ruby/prism_compile.c:8790 /usr/local/lib/libruby.so.4.0(pm_setup_args_core+0xe4) [0xffffb6191cf0] /usr/src/ruby/prism_compile.c:1816 /usr/local/lib/libruby.so.4.0(pm_setup_args+0xdc) [0xffffb61927e4] /usr/src/ruby/prism_compile.c:2020 /usr/local/lib/libruby.so.4.0(ISEQ_COMPILE_DATA+0x0) [0xffffb6195210] /usr/src/ruby/prism_compile.c:3706 /usr/local/lib/libruby.so.4.0(pm_compile_call) /usr/src/ruby/prism_compile.c:3707 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x1218) [0xffffb6183598] /usr/src/ruby/prism_compile.c:8790 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x3698) [0xffffb6185a18] /usr/src/ruby/prism_compile.c:10324 /usr/local/lib/libruby.so.4.0(pm_compile_scope_node+0x1b0c) [0xffffb619c974] /usr/src/ruby/prism_compile.c:7044 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x1a00) [0xffffb6183d80] /usr/src/ruby/prism_compile.c:10197 /usr/local/lib/libruby.so.4.0(pm_iseq_compile_node+0x60) [0xffffb619e240] /usr/src/ruby/prism_compile.c:10508 /usr/local/lib/libruby.so.4.0(pm_iseq_new_with_opt_try+0x1c) [0xffffb62576fc] /usr/src/ruby/iseq.c:1105 /usr/local/lib/libruby.so.4.0(rb_protect+0xb8) [0xffffb61e9d58] /usr/src/ruby/eval.c:1127 /usr/local/lib/libruby.so.4.0(pm_iseq_new_with_opt+0x150) [0xffffb6250138] /usr/src/ruby/iseq.c:1158 /usr/local/lib/libruby.so.4.0(pm_new_child_iseq+0xb8) [0xffffb614a440] /usr/src/ruby/prism_compile.c:1276 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x328c) [0xffffb618560c] /usr/src/ruby/prism_compile.c:9869 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x36c8) [0xffffb6185a48] /usr/src/ruby/prism_compile.c:10326 /usr/local/lib/libruby.so.4.0(pm_compile_scope_node+0x1b0c) [0xffffb619c974] /usr/src/ruby/prism_compile.c:7044 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x1a00) [0xffffb6183d80] /usr/src/ruby/prism_compile.c:10197 /usr/local/lib/libruby.so.4.0(pm_iseq_compile_node+0x60) [0xffffb619e240] /usr/src/ruby/prism_compile.c:10508 /usr/local/lib/libruby.so.4.0(pm_iseq_new_with_opt_try+0x1c) [0xffffb62576fc] /usr/src/ruby/iseq.c:1105 /usr/local/lib/libruby.so.4.0(rb_protect+0xb8) [0xffffb61e9d58] /usr/src/ruby/eval.c:1127 /usr/local/lib/libruby.so.4.0(pm_iseq_new_with_opt+0x150) [0xffffb6250138] /usr/src/ruby/iseq.c:1158 /usr/local/lib/libruby.so.4.0(pm_new_child_iseq+0xb8) [0xffffb614a440] /usr/src/ruby/prism_compile.c:1276 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x328c) [0xffffb618560c] /usr/src/ruby/prism_compile.c:9869 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x36c8) [0xffffb6185a48] /usr/src/ruby/prism_compile.c:10326 /usr/local/lib/libruby.so.4.0(pm_compile_scope_node+0x1b0c) [0xffffb619c974] /usr/src/ruby/prism_compile.c:7044 /usr/local/lib/libruby.so.4.0(pm_compile_node+0x1a00) [0xffffb6183d80] /usr/src/ruby/prism_compile.c:10197 /usr/local/lib/libruby.so.4.0(APPEND_LIST+0x0) [0xffffb619e2b4] /usr/src/ruby/prism_compile.c:10498 /usr/local/lib/libruby.so.4.0(pm_iseq_compile_node) /usr/src/ruby/prism_compile.c:10502 /usr/local/lib/libruby.so.4.0(pm_iseq_new_with_opt_try+0x1c) [0xffffb62576fc] /usr/src/ruby/iseq.c:1105 /usr/local/lib/libruby.so.4.0(rb_protect+0xb8) [0xffffb61e9d58] /usr/src/ruby/eval.c:1127 /usr/local/lib/libruby.so.4.0(pm_iseq_new_with_opt+0x150) [0xffffb6250138] /usr/src/ruby/iseq.c:1158 /usr/local/lib/libruby.so.4.0(iseqw_s_compile_file_prism+0x1c4) [0xffffb625076c] /usr/src/ruby/iseq.c:1925 [0xffff77cb7e20] ``` -- https://bugs.ruby-lang.org/

6 17

[ruby-core:124616] [Ruby Bug#21848] GC compaction freezes during code reload with 100% CPU in rb_vm_ci_free -> st_general_delete
by henrik (Henrik A) 27 Jul '26

27 Jul '26

Issue #21848 has been reported by henrik (Henrik A). ---------------------------------------- Bug #21848: GC compaction freezes during code reload with 100% CPU in rb_vm_ci_free -> st_general_delete https://bugs.ruby-lang.org/issues/21848 * Author: henrik (Henrik A) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Ruby 4.0.1 freezes with 100% CPU usage when garbage collection runs during Rails code reloading (hot reload in development). The process becomes unresponsive and requires kill -9 to terminate. Environment: - Ruby: 4.0.1 (Homebrew, ARM64) - Platform: macOS 15.6.1 (Darwin 24.6.0, Apple Silicon) - Rails: 8.x with Puma 7.2.0 - Mode: Development with code reloading enabled Steps to reproduce: 1. Run a Rails application with Puma in development mode (bundle exec rails server -e development -b 0.0.0.0) 2. Make a several code change to trigger hot reload, reload the site in the browser in between 3. Process freezes with ~100% CPU Expected behavior: Code reloads successfully, GC completes normally. Actual behavior: Process freezes indefinitely at 100% CPU. Stack trace from sample shows GC stuck in hash table lookup while freeing VM call info: ``` gc_sweep (in libruby.4.0.dylib) gc_compact_plane gc_sweep_page gc_sweep_plane rb_gc_obj_free_vm_weak_references rb_vm_ci_free st_general_delete find_table_bin_ind vm_ci_hash_cmp <-- stuck here, spinning ``` Full relevant stack (Puma worker thread): ``` Thread: puma srv tp 005 rb_ary_each -> rb_yield -> invoke_block_from_c_bh -> rb_vm_exec -> int_upto -> rb_yield (nested loops) -> vm_search_method_slowpath0 -> rb_vm_search_method_slowpath -> newobj_of -> newobj_cache_miss -> gc_continue -> gc_sweep -> gc_compact_plane -> gc_sweep_page -> gc_sweep_plane -> rb_gc_obj_free_vm_weak_references -> rb_vm_ci_free -> st_general_delete -> find_table_bin_ind -> vm_ci_hash_cmp ``` Workaround: Disabling auto-compaction prevents the freeze: GC.auto_compact = false Analysis: The freeze occurs during GC sweep/compaction when freeing cached VM call info entries (rb_vm_ci_free). This is triggered by code reloading which invalidates method caches. The GC appears to get stuck in an infinite loop or extremely slow operation in find_table_bin_ind while looking up entries in the call info hash table. ---Files-------------------------------- rails_stuck.txt (159 KB) -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126172] Useless Copilot 'comments' (was: Fwd: [ruby/ruby] Reject reopening `false` when assigned to constant (PR #18064))
by Martin J. Dürst 27 Jul '26

27 Jul '26

The amount of mail I get as a Ruby committer is already significant, but lately, it has been getting worse. Copilot is producing additional mails. And most of them are useless: 1) There are the regurgitating mails. See the comment from Earlopain below for why we don't need these. 2) There are the mails that say it has no comment. No actual committer sends such mails. 3) There are the mails that say that it "was unable to review this pull request because the user who requested the review has reached their quota limit.". No actual committer sends out mails e.g. saying they are currently busy with their day job. Can we change the settings so that such emails are not sent anymore? Maybe just switch off Copilot, and have people who think it might produce useful comments activate it manually for specific commits? I don't really care too much about the specifics; any improvement to this situation is welcome. Regards, Martin. -------- Forwarded Message -------- Subject: Re: [ruby/ruby] Reject reopening `false` when assigned to constant (PR #18064) Date: Sat, 25 Jul 2026 02:57:24 -0700 From: Earlopain <notifications(a)github.com> Reply-To: ruby/ruby <reply+AAGHDTMCZMSKXP3WLV2J543K3XQJJEVBNHHQAAAAAEUIY3SX(a)reply.github.com> To: ruby/ruby <ruby(a)noreply.github.com> CC: Subscribed <subscribed(a)noreply.github.com> Earlopain left a comment (ruby/ruby#18064) Thanks to the stochastic model for regurgitating what I have already written in 10x the verbosity, much appreciated. -- Reply to this email directly or view it on GitHub: https://github.com/ruby/ruby/pull/18064#issuecomment-5078055845 You are receiving this because you are subscribed to this thread. Message ID: <ruby/ruby/pull/18064/c5078055845(a)github.com>

2 1

[ruby-core:126167] [Ruby Feature#17056] Array#index: Allow specifying the position to start search as in String#index
by Dan0042 (Daniel DeLorme) 25 Jul '26

25 Jul '26

Issue #17056 has been updated by Dan0042 (Daniel DeLorme). ### 1. Object, block, and Enumerator forms Imho there are two options here a) If block form is supported, the offset is a keyword argument. It was not requested by the OP (also not in my duplicate #19177), but it's more versatile and future-proof. Although it introduces incompatibility due to keyword extension (described below) ```ruby index(object, offset: 0) index(offset: 0){ |element| ... } index(offset: 0) ``` b) If block form is not supported, the offset should be a positional argument, for consistency and duck-typing with String#index It's more limited, and makes it hard to add offset to block form in the future. ```ruby index(object, offset = 0) ``` Overall a) seems better to me, even if not fully consistent with String#index ### 2. Compatibility with searching for a Hash Ah yes, this is the standard problem with [keyword extension](#14183#note-29) What would happen with this code? ```ruby [{ key: 2 }].index(key: 2) ``` Will it now raise "unknown keyword: :key" ? ### 3. Semantics of `Array#rindex` > I think the corresponding Array behavior should be: > > ```ruby > [:a, :b, :a, :b, :a].rindex(:a, offset: 2) # => 2 > [:a, :b, :a, :b, :a].rindex(:a, offset: -2) # => 2 > [:a, :b, :a, :b, :a].rindex(:a, offset: 100) # => 4 > ``` 100% agree. ### 4. Boundary and conversion behavior > Should `Array#index` and `Array#rindex` follow the corresponding String methods for all of these cases? In general I would say yes, simply because having consistency for this reduces gotchas and footguns. But I'm not sure about this behavior of String: ```ruby "0aaaaaaaaaa9".rindex("a", 999) #=> 10 "0aaaaaaaaaa9".index("a", -999) #=> nil ``` To me, these two results are inconsistent and I feel like the last case should return 1. Should Array#index follow the same pattern or not? ```ruby [:a, :b, :a, :b, :a].index(:a, offset: -100) #=> nil (like String#index) or 0 ? ``` ---------------------------------------- Feature #17056: Array#index: Allow specifying the position to start search as in String#index https://bugs.ruby-lang.org/issues/17056#change-118233 * Author: TylerRick (Tyler Rick) * Status: Open ---------------------------------------- I have a use case of finding the first matching line within a given section in a file. After finding the line number of the start of the section, I want to find the first match after that line. My workaround for now is to use `with_index`: ```ruby lines = pathname.read.lines section_start_line = lines.index {|line| line.start_with?(/#* #{section_name}/) } lines.index.with_index {|line, i| i > section_start_line && line.include?(sought) } ``` I'd like to do it in a more concise way using a feature of `Array#index` that I propose here, which is analogous to `String#index`. If the second parameter of `String#index` is present, it specifies the position in the string to begin the search: ```ruby 'abcabc'.index('a') # => 0 'abcabc'.index('a',2) # => 3 ``` I would expect to also be able to do: ```ruby 'abcabc'.chars.index('a') # => 0 'abcabc'.chars.index('a', 2) ``` Using such feature, I would be able to do: ```ruby lines.index(sought, section_start_line) ``` This would give Ruby better parity with other programming languages like Python: ```python >>> list('abcabc') ['a', 'b', 'c', 'a', 'b', 'c'] >>> list('abcabc').index('a') 0 >>> list('abcabc').index('a', 2) 3 ``` ## End index We can further think of an optional parameter to specify the position to end the search. The following languages allow specifying both start and end indexes: - [Python](https://docs.python.org/3/tutorial/datastructures.html) - [C#](https://docs.microsoft.com/en-us/dotnet/api/system.array.indexof?view=n… Ruby's `String#index` does not have one, so we could make a separate proposal to add `end` to both methods at the same time. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126166] [Ruby Feature#17056] Array#index: Allow specifying the position to start search as in String#index
by nobu (Nobuyoshi Nakada) 25 Jul '26

25 Jul '26

Issue #17056 has been updated by nobu (Nobuyoshi Nakada). Status changed from Closed to Open I think we should reopen this issue and clarify the API before fixing the implementation. There are several API details that I think need to be decided explicitly. ## Issues to clarify ### 1. Object, block, and Enumerator forms The discussion in #note-7 and #note-8 explicitly considered using an offset with the block form: ```ruby array.index(offset: 10) { |element| ... } ``` However, the reverted implementation only handled `offset:` when an object was given. The following calls raised `ArgumentError`, despite the documented Enumerator signatures: ```ruby array.index(offset: 2) array.index(offset: 2) { |element| ... } array.rindex(offset: -2) array.rindex(offset: -2) { |element| ... } ``` Should all three forms accept `offset:`? ```ruby array.index(object, offset: 2) array.index(offset: 2) { |element| ... } array.index(offset: 2) # => Enumerator ``` The same question applies to `Array#rindex`. Since `Array#find_index` is an alias of `Array#index`, it should have exactly the same behavior. If the block form accepts `offset:`, the Enumerator form should retain the keyword argument so that calling `each` performs the same search. ### 2. Compatibility with searching for a Hash Before this feature, the following searches for the Hash `{ offset: 2 }`: ```ruby [{ offset: 2 }].index(offset: 2) # => 0 ``` If a keyword-only call now means the block/Enumerator form, this behavior changes. Searching for the Hash would still be possible with explicit braces: ```ruby [{ offset: 2 }].index({ offset: 2 }) # => 0 ``` Is this compatibility change acceptable? The same ambiguity exists when a block is given. Previously the keyword-like Hash was the object and the block was ignored with a warning. ### 3. Semantics of `Array#rindex` The reverted implementation did not behave like `String#rindex`. It also documented the signature as `rindex(object, offset: nil)`, but an explicit `nil` was not accepted: ```ruby array.rindex(object, offset: nil) # => TypeError: no implicit conversion of nil into Integer ``` In the implementation, `nil` was only used internally to represent an omitted keyword. Documenting `offset: nil` makes it look like `nil` is an accepted default value. For an Array, `offset: -1` would express the actual default starting position while keeping an explicit `nil` invalid. `String#rindex(pattern, offset)` starts searching backward at `offset`. A non-negative offset is an absolute position. A negative offset is relative to the end. An offset greater than the string length is clamped to the end. For example: ```ruby "ababa".rindex("a", 2) # => 2 "ababa".rindex("a", -2) # => 2 "ababa".rindex("a", 100) # => 4 ``` I think the corresponding Array behavior should be: ```ruby [:a, :b, :a, :b, :a].rindex(:a, offset: 2) # => 2 [:a, :b, :a, :b, :a].rindex(:a, offset: -2) # => 2 [:a, :b, :a, :b, :a].rindex(:a, offset: 100) # => 4 ``` The reverted implementation instead treated a non-negative offset as the lower bound of a search starting at the end: ```ruby [:a, :b, :a, :b, :a].rindex(:a, offset: 2) # => 4 ``` This makes positive and negative offsets have different meanings and is not consistent with `String#rindex`. Should `Array#rindex` follow `String#rindex` exactly? ### 4. Boundary and conversion behavior Should `Array#index` and `Array#rindex` follow the corresponding String methods for all of these cases? - Negative offsets relative to the end - An offset smaller than `-array.size` - An offset equal to `array.size` - An offset greater than `array.size` - Objects accepted through numeric conversion - Explicit `nil` - Integers too large for the internal index type These should be specified and tested for both forward and backward searches. ## Proposed signatures If the above behavior is intended, the signatures would be: ```ruby index(object, offset: 0) -> integer or nil index(offset: 0) { |element| ... } -> integer or nil index(offset: 0) -> Enumerator find_index(object, offset: 0) -> integer or nil find_index(offset: 0) { |element| ... } -> integer or nil find_index(offset: 0) -> Enumerator rindex(object, offset: -1) -> integer or nil rindex(offset: -1) { |element| ... } -> integer or nil rindex(offset: -1) -> Enumerator ``` The implementation has been reverted. Once these points are agreed, I think we should add specs for the complete behavior before reimplementing it. ---------------------------------------- Feature #17056: Array#index: Allow specifying the position to start search as in String#index https://bugs.ruby-lang.org/issues/17056#change-118232 * Author: TylerRick (Tyler Rick) * Status: Open ---------------------------------------- I have a use case of finding the first matching line within a given section in a file. After finding the line number of the start of the section, I want to find the first match after that line. My workaround for now is to use `with_index`: ```ruby lines = pathname.read.lines section_start_line = lines.index {|line| line.start_with?(/#* #{section_name}/) } lines.index.with_index {|line, i| i > section_start_line && line.include?(sought) } ``` I'd like to do it in a more concise way using a feature of `Array#index` that I propose here, which is analogous to `String#index`. If the second parameter of `String#index` is present, it specifies the position in the string to begin the search: ```ruby 'abcabc'.index('a') # => 0 'abcabc'.index('a',2) # => 3 ``` I would expect to also be able to do: ```ruby 'abcabc'.chars.index('a') # => 0 'abcabc'.chars.index('a', 2) ``` Using such feature, I would be able to do: ```ruby lines.index(sought, section_start_line) ``` This would give Ruby better parity with other programming languages like Python: ```python >>> list('abcabc') ['a', 'b', 'c', 'a', 'b', 'c'] >>> list('abcabc').index('a') 0 >>> list('abcabc').index('a', 2) 3 ``` ## End index We can further think of an optional parameter to specify the position to end the search. The following languages allow specifying both start and end indexes: - [Python](https://docs.python.org/3/tutorial/datastructures.html) - [C#](https://docs.microsoft.com/en-us/dotnet/api/system.array.indexof?view=n… Ruby's `String#index` does not have one, so we could make a separate proposal to add `end` to both methods at the same time. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116456] [Ruby master Feature#20215] Introduce `IO#readable?`
by ioquatix (Samuel Williams) 25 Jul '26

25 Jul '26

Issue #20215 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #20215: Introduce `IO#readable?` https://bugs.ruby-lang.org/issues/20215 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- There are some cases where, as an optimisation, it's useful to know whether more data is potentially available. We already have `IO#eof?` but the problem with using `IO#eof?` is that it can block indefinitely for sockets. Therefore, code which uses `IO#eof?` to determine if there is potentially more data, may hang. ```ruby def make_request(path = "/") client = connect_remote_host # HTTP/1.0 request: client.write("GET #{path} HTTP/1.0\r\n\r\n") # Read response client.gets("\r\n") # => "HTTP/1.0 200 OK\r\n" # Assuming connection close, there are two things the server can do: # 1. peer.close # 2. peer.write(...); peer.close if client.eof? # <--- Can hang here! puts "Connection closed" # Avoid yielding as we know there definitely won't be any data. else puts "Connection open, data may be available..." # There might be data available, so yield. yield(client) end ensure client&.close end make_request do |client| puts client.read # <--- Prefer to wait here. end ``` The proposed `IO#readable?` is similar to `IO#eof?` but rather than blocking, would simply return false. The expectation is the user will subsequently call `read` which may then wait. The proposed implementation would look something like this: ```ruby class IO def readable? !!self.closed? end end class BasicSocket # Is it likely that the socket is still connected? # May return false positive, but won't return false negative. def readable? return false unless super # If we can wait for the socket to become readable, we know that the socket may still be open. result = self.recv_nonblock(1, MSG_PEEK, exception: false) # No data was available - newer Ruby can return nil instead of empty string: return false if result.nil? # Either there was some data available, or we can wait to see if there is data avaialble. return !result.empty? || result == :wait_readable rescue Errno::ECONNRESET # This might be thrown by recv_nonblock. return false end end ``` For `IO` itself, when there is buffered data, `readable?` would also return true immediately, similar to `eof?`. This is not shown in the above implementation as I'm not sure if there is any Ruby method which exposes "there is buffered data". -- https://bugs.ruby-lang.org/

8 19