June 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:115422] [Ruby master Bug#20009] Marshal.load raises exception when load dumped class include non-ASCII
by ippachi (Kazuya Hatanaka) 19 Jul '25

19 Jul '25

Issue #20009 has been reported by ippachi (Kazuya Hatanaka). ---------------------------------------- Bug #20009: Marshal.load raises exception when load dumped class include non-ASCII https://bugs.ruby-lang.org/issues/20009 * Author: ippachi (Kazuya Hatanaka) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ## Reproduction code ```ruby class Cクラス; end Marshal.load(Marshal.dump(Cクラス)) ``` ## Actual result ``` <internal:marshal>:34:in `load': undefined class/module C\xE3\x82\xAF\xE3\x83\xA9\xE3\x82\xB9 (ArgumentError) from marshal.rb:2:in `<main>' ``` ## Expected result Returns `Cクラス` ## Impacted area An exception is raised in Rails under the following conditions * minitest is used with default settings * Parallel execution with parallelize * test class names contain non-ASCII characters The default parallelization uses DRb, and Marshal is used inside DRb. ## Other After trying various things, I thought I could fix it by making `rb_path_to_class` support strings containing non-ASCII characters, but I couldn't find anything more than that. -- https://bugs.ruby-lang.org/

7 13

[ruby-core:112664] [Ruby master Bug#19473] can't be called from trap context (ThreadError) is too limiting
by Eregon (Benoit Daloze) 15 Jul '25

15 Jul '25

Issue #19473 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19473: can't be called from trap context (ThreadError) is too limiting https://bugs.ruby-lang.org/issues/19473 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Simple reproducer: ``` $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] -e:1:in `synchronize': can't be called from trap context (ThreadError) from -e:1:in `block in <main>' from -e:1:in `kill' from -e:1:in `<main>' ``` Expected behavior: ``` $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' truffleruby 22.3.1, like ruby 3.0.3, GraalVM CE Native [x86_64-linux] :OK $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' jruby 9.4.0.0 (3.1.0) 2022-11-23 95c0ec159f OpenJDK 64-Bit Server VM 17.0.6+10 on 17.0.6+10 +jit [x86_64-linux] :OK ``` This exception is highly problematic, for instance it breaks `Timeout.timeout` in `trap`: https://github.com/ruby/timeout/issues/17#issuecomment-1142035939 I suppose this behavior is because *sometimes* it's problematic to lock a Mutex in trap, e.g., if it's already locked by the main thread/fiber. However, that's just one case, not all, so we should not raise an exception early like that. There seems to be no valid reason to prevent *all* `Mutex#synchronize` in `trap`. After all, if the Mutex for instance is only used in `trap`, it's well-defined AFAIK. For instance a given trap handler does not seem executed concurrently: ``` $ ruby -ve 'trap(:HUP) { puts "in trap\n"+caller.join("\n")+"\n\n"; sleep 0.1 }; pid = Process.pid; Process.wait fork { 20.times { Process.kill :HUP, pid } }; sleep 1' ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' ``` And if the trap handler using the Mutex is never called while the Mutex is held by the main thread/fiber, there is also no problem. -- https://bugs.ruby-lang.org/

8 27

[ruby-core:111027] [Ruby master Bug#19154] Specify require and autoload guarantees in ractors
by fxn (Xavier Noria) 14 Jul '25

14 Jul '25

Issue #19154 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #19154: Specify require and autoload guarantees in ractors https://bugs.ruby-lang.org/issues/19154 * Author: fxn (Xavier Noria) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0preview3 (2022-11-27) [x86_64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Given a file `c.rb`: ```ruby class C end ``` the following script: ```ruby r1 = Ractor.new do require './c.rb' end r2 = Ractor.new do require './c.rb' end r1.take r2.take ``` raises: ``` % ruby -v foo.rb ruby 3.2.0preview3 (2022-11-27) [x86_64-darwin22] foo.rb:1: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. #<Thread:0x000000010fee2928 run> terminated with exception (report_on_exception is true): #<Thread:0x00000001102acfe0 run> terminated with exception (report_on_exception is true): <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:164:in `ensure in require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:167:in `require' from foo.rb:6:in `block in <main>' <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:37:in `require'<internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:164:in `ensure in require': : can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:167:in `require' can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from foo.rb:2:in `block in <main>' <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:37:in `require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from foo.rb:2:in `block in <main>' from foo.rb:6:in `block in <main>' <internal:ractor>:698:in `take': thrown by remote Ractor. (Ractor::RemoteError) from foo.rb:9:in `<main>' <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:164:in `ensure in require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:167:in `require' from foo.rb:2:in `block in <main>' <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:37:in `require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from foo.rb:2:in `block in <main>' ``` Would it be possible to have documentation about their interaction? This is important also to understand autoloading within ractors, since constant references may trigger `require` calls. -- https://bugs.ruby-lang.org/

5 13

[ruby-core:116382] [Ruby master Feature#20205] Enable `frozen_string_literal` by default
by byroot (Jean Boussier) 10 Jul '25

10 Jul '25

Issue #20205 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20205: Enable `frozen_string_literal` by default https://bugs.ruby-lang.org/issues/20205 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context The `frozen_string_literal: true` pragma was introduced in Ruby 2.3, and as far as I'm aware the plan was initially to make it the default for Ruby 3.0, but this plan was abandoned because it would be too much of a breaking change without any real further notice. According to Matz, he still wishes to enable `frozen_string_literal` by default in the future, but a reasonable migration plan is required. The main issue is backward compatibility, flipping the switch immediately would break a lot of code, so there must be some deprecation period. The usual the path forward for this kind of change is to emit deprecation warnings one of multiple versions in advance. One example of that was the Ruby 2.7 keyword argument deprecation. It was quite verbose, and some users were initially annoyed, but I think the community pulled through it and I don't seem to hear much about it anymore. So for frozen string literals, the first step would be to start warning when a string that would be frozen in the future is mutated. ### Deprecation Warning Implementation I implemented a quick proof of concept with @etienne in https://github.com/Shopify/ruby/pull/549 In short: - Files with `# frozen_string_literal: true` or `# frozen_string_literal: false` don't change in behavior at all. - Files with no `# frozen_string_literal` comment are compiled to use `putchilledstring` opcode instead of regular `putstring`. - This opcode mark the string with a user flag, when these strings are mutated, a warning is issued. Currently the proof of concept issue the warning at the mutation location, which in some case can make locating where the string was allocated a bit hard. But it is possible to improve it so the message also include the location at which the literal string was allocated, and learning from the keyword argument warning experience, we can record which warnings were already issued to avoid spamming users with duplicated warnings. As currently implemented, there is almost no overhead. If we modify the implementation to record the literal location, we'd incur a small memory overhead for each literal string in a file without an explicit `frozen_string_literal` pragma. But I believe we could do it in a way that has no overhead if `Warning[:deprecated] = false`. ### Timeline The migration would happen in 3 steps, each step can potentially last multiple releases. e.g. `R0` could be `3.4`, `R1` be `3.7` and `R2` be `4.0`. I don't have a strong opinion on the pace. - Release `R0`: introduce the deprecation warning (only if deprecation warnings enabled). - Release `R1`: make the deprecation warning show up regardless of verbosity level. - Release `R2`: make string literals frozen by default. ### Impact Given that `rubocop` is quite popular in the community and it has enforced the usage of `# frozen_string_literal: true` for years now, I suspect a large part of the actively maintained codebases in the wild wouldn't see any warnings. And with recent versions of `minitest` enabling deprecation warnings by default (and [potentially RSpec too](https://github.com/rspec/rspec-core/issues/2867)) the few that didn't migrate will likely be made compatible quickly. The real problem of course are the less actively developed libraries and applications. For such cases, any codebase can remain compatible by setting `RUBYOPT="--disable=frozen_string_literal"`, and so even after `R2` release. The flag would never be removed any legacy codebase can continue upgrading Ruby without changing a single line of cod by just flipping this flag. ### Workflow for library maintainers As a library maintainer, fixing the deprecation warnings can be as simple as prepending `# frozen_string_literal: false` at the top of all their source files, and this will keep working forever. Alternatively they can of course make their code compatible with frozen string literals. Code that is frozen string literal compatible doesn't need to explicitly declare it. Only code that need it turned of need to do so. ### Workflow for application owners For application owners, the workflow is the same than for libraries. However if they depend on a gem that hasn't updated, or that they can't upgrade it, they can run their application with `RUBYOPT="--disable=frozen_string_literal"` and it will keep working forever. Any user running into an incompatibility issue can set `RUBYOPT="--disable=frozen_string_literal"` forever, even in `4.x`, the only thing changing is the default value. And any application for which all dependencies have been made fully frozen string literal compatible can set `RUBYOPT="--enable=frozen_string_literal"` and start immediately removing magic comment from their codebase. -- https://bugs.ruby-lang.org/

20 73

[ruby-core:117392] [Ruby master Feature#20405] Inline comments
by nobu (Nobuyoshi Nakada) 08 Jul '25

08 Jul '25

Issue #20405 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #20405: Inline comments https://bugs.ruby-lang.org/issues/20405 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- I propose a new inline comment syntax. ```ruby p (| This is a comment (| and nested one |) /:|) (:|) #=> :| ``` -- https://bugs.ruby-lang.org/

7 10

[ruby-core:115203] [Ruby master Bug#19981] bootstraptest/test_ractor.rb: Segmentation fault on arm32
by jaruga (Jun Aruga) 02 Jul '25

02 Jul '25

Issue #19981 has been reported by jaruga (Jun Aruga). ---------------------------------------- Bug #19981: bootstraptest/test_ractor.rb: Segmentation fault on arm32 https://bugs.ruby-lang.org/issues/19981 * Author: jaruga (Jun Aruga) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I faced the following segmentation fault on Ubuntu jammy arm32 (emulated environment by `SETARCH='setarch linux32 --verbose --32bit'`) in both Travis CI arm64 [log](https://app.travis-ci.com/github/ruby/ruby/jobs/612418476#L2422 ) and RubyCI arm64-neoverse server. I tested it on the latest ruby master branch `14fa5e39d72c84d3e12e10dc5d77a6e6200c10f5`. I was able to reproduce this issue on RubyCI arm64-neoverse server, and prepared the reproducing script. So, you can try to debug on the server. It seems that the `-O3` flag triggered the issue. Because I didn't see the issue when Travis CI setting `- optflags=-O1` in `.travis.yml` on the current master branch. https://github.com/junaruga/report-ruby-ractor-segmentation-fault ``` + arm-linux-gnueabihf-gcc --version arm-linux-gnueabihf-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 + setarch linux32 --verbose --32bit make -s test Switching on ADDR_LIMIT_32BIT. Execute command `make'. Fstderr output is not empty <internal:ractor>:760: [BUG] Segmentation fault at 0x0000000c ruby 3.3.0dev (2023-10-30T09:27:06Z master 14fa5e39d7) [armv8l-linux-eabihf] -- Control frame information ----------------------------------------------- c:0005 p:0003 s:0021 e:000020 METHOD <internal:ractor>:760 c:0004 p:0008 s:0014 e:000013 BLOCK bootstraptest.test_ractor.rb_541_1260.rb:4 c:0003 p:0018 s:0011 e:000010 METHOD <internal:kernel>:187 c:0002 p:0004 s:0006 e:000005 BLOCK bootstraptest.test_ractor.rb_541_1260.rb:3 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- bootstraptest.test_ractor.rb_541_1260.rb:3:in `block in <main>' <internal:kernel>:187:in `loop' bootstraptest.test_ractor.rb_541_1260.rb:4:in `block (2 levels) in <main>' <internal:ractor>:760:in `yield' -- Threading information --------------------------------------------------- Total ractor count: 2 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ r0: 0x00000000 r1: 0x00000001 r2: 0x00000007 r3: 0x00000000 r4: 0x00c935c8 r5: 0x00000002 r6: 0x00000002 r7: 0x00000000 r8: 0x00000004 r9: 0x00c646b0 r10: 0x00000002 sp: 0xd5d91c90 fau: 0x0000000c -- Other runtime information ----------------------------------------------- * Loaded script: bootstraptest.test_ractor.rb_541_1260.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb 6 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/encdb.so 7 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/trans/transdb.so * Process memory map: 00640000-0093a000 r-xp 00000000 103:03 29263803 /home/jaruga/git/ruby/ruby/build/ruby 0094a000-0094e000 r--p 002fa000 103:03 29263803 /home/jaruga/git/ruby/ruby/build/ruby 0094e000-0094f000 rw-p 002fe000 103:03 29263803 /home/jaruga/git/ruby/ruby/build/ruby 0094f000-00956000 rw-p 00000000 00:00 0 00bf3000-00cba000 rw-p 00000000 00:00 0 [heap] d5700000-d5721000 rw-p 00000000 00:00 0 d5721000-d5800000 ---p 00000000 00:00 0 d5900000-d5921000 rw-p 00000000 00:00 0 d5921000-d5a00000 ---p 00000000 00:00 0 d5a00000-d5a21000 rw-p 00000000 00:00 0 d5a21000-d5b00000 ---p 00000000 00:00 0 d5b00000-d5b21000 rw-p 00000000 00:00 0 d5b21000-d5c00000 ---p 00000000 00:00 0 d5c5f000-d5c60000 ---p 00000000 00:00 0 d5c60000-d5c90000 rw-p 00000000 00:00 0 d5c9f000-d5ca0000 ---p 00000000 00:00 0 d5ca0000-d5cd0000 rw-p 00000000 00:00 0 d5cde000-d5cdf000 ---p 00000000 00:00 0 d5cdf000-d5cef000 rw-p 00000000 00:00 0 d5cef000-d5cf0000 ---p 00000000 00:00 0 d5cf0000-d5d81000 rw-p 00000000 00:00 0 d5d81000-d5d82000 ---p 00000000 00:00 0 d5d82000-d5e12000 rw-p 00000000 00:00 0 d5e12000-d5e13000 ---p 00000000 00:00 0 d5e13000-d5ea3000 rw-p 00000000 00:00 0 d5ea3000-d5ea4000 ---p 00000000 00:00 0 d5ea4000-d5f34000 rw-p 00000000 00:00 0 d5f34000-d5f35000 ---p 00000000 00:00 0 d5f35000-d5fc5000 rw-p 00000000 00:00 0 d5fc5000-d5fc6000 ---p 00000000 00:00 0 d5fc6000-d6056000 rw-p 00000000 00:00 0 d6056000-d6057000 ---p 00000000 00:00 0 d6057000-d60e7000 rw-p 00000000 00:00 0 d60e7000-d60e8000 ---p 00000000 00:00 0 d60e8000-d6178000 rw-p 00000000 00:00 0 d6178000-d6179000 ---p 00000000 00:00 0 d6179000-d6209000 rw-p 00000000 00:00 0 d6209000-d620a000 ---p 00000000 00:00 0 d620a000-d629a000 rw-p 00000000 00:00 0 d629a000-d629b000 ---p 00000000 00:00 0 d629b000-d632b000 rw-p 00000000 00:00 0 d632b000-d632c000 ---p 00000000 00:00 0 d632c000-f5d10000 rw-p 00000000 00:00 0 f5d10000-f5d12000 r-xp 00000000 103:03 29263555 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/trans/transdb.so f5d12000-f5d21000 ---p 00002000 103:03 29263555 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/trans/transdb.so f5d21000-f5d22000 r--p 00001000 103:03 29263555 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/trans/transdb.so f5d22000-f5d23000 rw-p 00002000 103:03 29263555 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/trans/transdb.so f5d30000-f5d32000 r-xp 00000000 103:03 29263548 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/encdb.so f5d32000-f5d41000 ---p 00002000 103:03 29263548 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/encdb.so f5d41000-f5d42000 r--p 00001000 103:03 29263548 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/encdb.so f5d42000-f5d43000 rw-p 00002000 103:03 29263548 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/encdb.so f5d4f000-f5d50000 ---p 00000000 00:00 0 f5d50000-f5d71000 rw-p 00000000 00:00 0 f5d71000-f5d72000 ---p 00000000 00:00 0 f5d72000-f5d93000 rw-p 00000000 00:00 0 f5d93000-f5d94000 ---p 00000000 00:00 0 f5d94000-f5db5000 rw-p 00000000 00:00 0 f5db5000-f5db6000 ---p 00000000 00:00 0 f5db6000-f5dd7000 rw-p 00000000 00:00 0 f5dd7000-f5dd8000 ---p 00000000 00:00 0 f5dd8000-f5df9000 rw-p 00000000 00:00 0 f5df9000-f5dfa000 ---p 00000000 00:00 0 f5dfa000-f5e1b000 rw-p 00000000 00:00 0 f5e1b000-f5e1c000 ---p 00000000 00:00 0 f5e1c000-f5e3d000 rw-p 00000000 00:00 0 f5e3d000-f5e3e000 ---p 00000000 00:00 0 f5e3e000-f5e5f000 rw-p 00000000 00:00 0 f5e5f000-f5e60000 ---p 00000000 00:00 0 f5e60000-f66a0000 rw-p 00000000 00:00 0 f66af000-f73b0000 rw-p 00000000 00:00 0 f73b5000-f7436000 rw-p 00000000 00:00 0 f7436000-f76b0000 r--p 0006f000 103:03 11802136 /usr/lib/locale/locale-archive f76b0000-f78b0000 r--p 00000000 103:03 11802136 /usr/lib/locale/locale-archive f78b0000-f79bc000 r-xp 00000000 103:03 11670018 /usr/lib/arm-linux-gnueabihf/libc.so.6 f79bc000-f79cc000 ---p 0010c000 103:03 11670018 /usr/lib/arm-linux-gnueabihf/libc.so.6 f79cc000-f79ce000 r--p 0010c000 103:03 11670018 /usr/lib/arm-linux-gnueabihf/libc.so.6 f79ce000-f79cf000 rw-p 0010e000 103:03 11670018 /usr/lib/arm-linux-gnueabihf/libc.so.6 f79cf000-f79d9000 rw-p 00000000 00:00 0 f79e0000-f7a21000 r-xp 00000000 103:03 11670021 /usr/lib/arm-linux-gnueabihf/libm.so.6 f7a21000-f7a30000 ---p 00041000 103:03 11670021 /usr/lib/arm-linux-gnueabihf/libm.so.6 f7a30000-f7a31000 r--p 00040000 103:03 11670021 /usr/lib/arm-linux-gnueabihf/libm.so.6 f7a31000-f7a32000 rw-p 00041000 103:03 11670021 /usr/lib/arm-linux-gnueabihf/libm.so.6 f7a40000-f7a6b000 r-xp 00000000 103:03 11670013 /usr/lib/arm-linux-gnueabihf/libcrypt.so.1.1.0 f7a6b000-f7a7b000 ---p 0002b000 103:03 11670013 /usr/lib/arm-linux-gnueabihf/libcrypt.so.1.1.0 f7a7b000-f7a7c000 r--p 0002b000 103:03 11670013 /usr/lib/arm-linux-gnueabihf/libcrypt.so.1.1.0 f7a7c000-f7a7d000 rw-p 0002c000 103:03 11670013 /usr/lib/arm-linux-gnueabihf/libcrypt.so.1.1.0 f7a7d000-f7a85000 rw-p 00000000 00:00 0 f7a88000-f7aa7000 r-xp 00000000 103:03 11670015 /usr/lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 f7aac000-f7ab3000 r--s 00000000 103:03 11670285 /usr/lib/arm-linux-gnueabihf/gconv/gconv-modules.cache f7ab3000-f7ab5000 rw-p 00000000 00:00 0 f7ab5000-f7ab6000 r-xp 00000000 00:00 0 [sigpage] f7ab6000-f7ab8000 r--p 0001e000 103:03 11670015 /usr/lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 f7ab8000-f7ab9000 rw-p 00020000 103:03 11670015 /usr/lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 ff7dd000-fffdc000 rw-p 00000000 00:00 0 [stack] ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors] ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:117684] [Ruby master Bug#20452] Ruby 3.3 on Alpine Linux results in a relatively shallow SystemStackError exception
by Earlopain (A S) 17 Jun '25

17 Jun '25

Issue #20452 has been reported by Earlopain (A S). ---------------------------------------- Bug #20452: Ruby 3.3 on Alpine Linux results in a relatively shallow SystemStackError exception https://bugs.ruby-lang.org/issues/20452 * Author: Earlopain (A S) * Status: Open * ruby -v: 3.3.1 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- This is a redo of https://bugs.ruby-lang.org/issues/14387, reported against a non-eol version. The same issue still applies on recent rubies, though I personally only have tested 3.3 and 3.2: ```rb n = 100000 res = {} 1.upto(n).to_a.inject(res) do |r, i| r[i] = {} end def f(x) x.each_value { |v| f(v) } end f(res) ``` The patch from https://bugs.ruby-lang.org/issues/14387#note-13 still works, though as per https://bugs.ruby-lang.org/issues/14387#note-16 it can't be accepted as is. With the patch applied: ``` (irb):8:in `block in f': stack level too deep (SystemStackError) from (irb):8:in `each_value' from (irb):8:in `f' from (irb):8:in `block in f' from (irb):8:in `each_value' from (irb):8:in `f' from (irb):8:in `block in f' from (irb):8:in `each_value' from (irb):8:in `f' ... 11549 levels... from /usr/local/lib/ruby/gems/3.3.0/gems/irb-1.11.0/exe/irb:9:in `<top (required)>' from /usr/local/bin/irb:25:in `load' from /usr/local/bin/irb:25:in `<main>' ``` Without the patch: ``` (irb):8:in `each_value': stack level too deep (SystemStackError) from (irb):8:in `f' from (irb):8:in `block in f' from (irb):8:in `each_value' from (irb):8:in `f' from (irb):8:in `block in f' from (irb):8:in `each_value' from (irb):8:in `f' from (irb):8:in `block in f' ... 286 levels... from /usr/local/lib/ruby/gems/3.3.0/gems/irb-1.11.0/exe/irb:9:in `<top (required)>' from /usr/local/bin/irb:25:in `load' from /usr/local/bin/irb:25:in `<main>' ``` To reproduce, I have removed lines 102-105 from https://github.com/docker-library/ruby/blob/f5753434bb23041dd9913bb7b650e7b…. Check out the previous ticket for more information, there are a few conversations about possible solutions. -- https://bugs.ruby-lang.org/

4 11

[ruby-core:115981] [Ruby master Bug#20105] Introduce `IO::Stream` or something similar.
by ioquatix (Samuel Williams) 07 Jun '25

07 Jun '25

Issue #20105 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #20105: Introduce `IO::Stream` or something similar. https://bugs.ruby-lang.org/issues/20105 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Ruby's IO class has a general model for streaming IO, including some hidden classes like `IO::generic_readable` and `IO::generic_writable`. As Ruby's core IO classes evolve, gems like `openssl` (see `OpenSSL::Buffering`) need to be updated to support changes to the interface. As it stands, there are changes in `IO` which are not copied to `OpenSSL::Buffering`. I'd like to propose we introduce some shared interface for streams that is used by `IO`, `Socket`, and `OpenSSL` to start with. The general interface would be similar to `IO` and allow code like `OpenSSL` to avoid re-implementing the `IO` interface. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:117216] [Ruby master Bug#20346] FiberScheduler.unblock not called by Thread#join when Thread body contains Ractor.take
by forthoney (Seong-Heon Jung) 05 Jun '25

05 Jun '25

Issue #20346 has been reported by forthoney (Seong-Heon Jung). ---------------------------------------- Bug #20346: FiberScheduler.unblock not called by Thread#join when Thread body contains Ractor.take https://bugs.ruby-lang.org/issues/20346 * Author: forthoney (Seong-Heon Jung) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When using a `Ractor.take` inside a different thread, `Thread#join` on the thread running `Ractor.take` fails to call `FiberScheduler.unblock`. The below code can replicate this behavior ```ruby require "async" class RactorWrapper def initialize @ractor = Ractor.new do Ractor.recv # Ractor doesn't start until explicitly told to # Do some calculations fib = ->(x) { x < 2 ? 1 : fib.call(x - 1) + fib.call(x - 2) } fib.call(20) end end def take_async @ractor.send(nil) Thread.new { @ractor.take }.join.value end end Async do |task| 10000.times do |i| task.async do RactorWrapper.new.take_async puts i end end end ``` The above code deadlocks, and when we leave a debugging print statement inside of `Async`'s scheduler's `block` and `unblock` method, we can confirm that we only call `Scheduler.block`, and never `Scheduler.unblock` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:118191] [Ruby master Bug#20560] make install - skipped bundled gems - minor issue
by MSP-Greg (Greg L) 04 Jun '25

04 Jun '25

Issue #20560 has been reported by MSP-Greg (Greg L). ---------------------------------------- Bug #20560: make install - skipped bundled gems - minor issue https://bugs.ruby-lang.org/issues/20560 * Author: MSP-Greg (Greg L) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- See most recent job: https://github.com/ruby/ruby/actions/runs/9389674968/job/25857719333#step:9… Which is logging the following during `make install`: ``` skipped bundled gems: power_assert-2.0.4dev.gem not found in bundled_gems syslog-0.1.2.gem not found in bundled_gems ``` Not sure what the correct versioning should be. Or, should bundled gems use 'dev' versions, etc... -- https://bugs.ruby-lang.org/

2 3