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

[ruby-core:118270] [Ruby master Bug#20571] Compile error on for loop
by kddnewton (Kevin Newton) 02 Sep '24

02 Sep '24

Issue #20571 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20571: Compile error on for loop https://bugs.ruby-lang.org/issues/20571 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby for _ in 1.5 or _ in [] end ``` raises a compile error for the current compiler only with ``` -- raw disasm-------- trace: 1 <L000> [sp: 0, unremovable: 1, refcnt: 1] 0000 putobject 1.5 ( 1) 0002 jump <L002> ( 1) <L006> [sp: 1, unremovable: 1, refcnt: 1] <L004> [sp: 1, unremovable: 0, refcnt: 0] 0004 pop ( 1) * 0005 pop ( 1) 0006 putobject false ( 1) <L002> [sp: 1, unremovable: 0, refcnt: 1] 0008 send <calldata:each, 0>, nil ( 1) <L001> [sp: -1, unremovable: 0, refcnt: 2] 0011 leave ( 1) --------------------- test.rb:1: argument stack underflow (-1) test.rb: compile error (SyntaxError) ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:118681] [Ruby master Bug#20651] `false && (1 in 1)` produces argument stack underflow (-1)
by tompng (tomoya ishida) 02 Sep '24

02 Sep '24

Issue #20651 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20651: `false && (1 in 1)` produces argument stack underflow (-1) https://bugs.ruby-lang.org/issues/20651 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.4.0dev (2024-07-24T19:55:04Z master 30eba40f9c) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- `false && (1 in 1)` and `true || (1 in 1)` produces argument stack underflow since ruby 3.0 ~~~ # ruby -v ruby 3.4.0dev (2024-07-24T19:55:04Z master 30eba40f9c) [x86_64-linux] # ruby -e "false && (1 in 1)" -- raw disasm-------- trace: 1 0000 putobject false ( 1) 0002 leave ( 1) <L004> [sp: 1, unremovable: 1, refcnt: 1] <L002> [sp: 1, unremovable: 0, refcnt: 0] 0003 pop ( 1) * 0004 pop ( 1) 0005 putobject false ( 1) 0007 leave ( 1) --------------------- -e:1: argument stack underflow (-1) -e: compile error (SyntaxError) ~~~ -- https://bugs.ruby-lang.org/

3 3

[ruby-core:118797] [Ruby master Bug#20668] [3.3] shareable_constant_value: literal crash
by byroot (Jean Boussier) 02 Sep '24

02 Sep '24

Issue #20668 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #20668: [3.3] shareable_constant_value: literal crash https://bugs.ruby-lang.org/issues/20668 * Author: byroot (Jean Boussier) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [arm64-darwin23] * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- The following test script crashes in the parser: ```ruby # shareable_constant_value: literal FORM_STRATEGIES = { 'product' => Object, 'storefront_password' => String, 'contact' => Class, } ``` The entire 3.3.x series is affected but not `master` nor 3.2. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:118686] [Ruby master Bug#20653] Memory leak in String#start_with? when regexp times out
by peterzhu2118 (Peter Zhu) 02 Sep '24

02 Sep '24

Issue #20653 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #20653: Memory leak in String#start_with? when regexp times out https://bugs.ruby-lang.org/issues/20653 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: WONTFIX, 3.3: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/11247 This commit refactors how Onigmo handles timeout. Instead of raising a timeout error, onig_search will return a ONIGERR_TIMEOUT which the caller can free memory, and then raise a timeout error. This fixes a memory leak in String#start_with when the regexp times out. For example: ```ruby regex = Regexp.new("^#{"(a*)" * 10_000}x$", timeout: 0.000001) str = "a" * 1000000 + "x" 10.times do 100.times do str.start_with?(regex) rescue end puts `ps -o rss= -p #{$$}` end ``` Before: ``` 33216 51936 71152 81728 97152 103248 120384 133392 133520 133616 ``` After: ``` 14912 15376 15824 15824 16128 16128 16144 16144 16160 16160 ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:118637] [Ruby master Bug#20641] `lib/bundled_gems.rb` makes `Kernel.require` over 100x slower
by byroot (Jean Boussier) 02 Sep '24

02 Sep '24

Issue #20641 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #20641: `lib/bundled_gems.rb` makes `Kernel.require` over 100x slower https://bugs.ruby-lang.org/issues/20641 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- I just discovered this while profiling Active Record's test suite, and I noticed 40% of the runtime was in `$LOAD_PATH.resolve_feature_path`, so much I thought it was a profiler bug. But it turns out it's real. Various APIs do call `require` late, for instance Psych calls `require 'date'` every single time it parses a date: https://github.com/ruby/psych/blob/be0ba74e5613c20f213403e15914d24944c2652d… I've put together a quick benchmark: ```ruby # frozen_string_literal: true require "bundler/inline" gemfile(true) do source "https://rubygems.org" gem "benchmark-ips" end Benchmark.ips do |x| x.report(RUBY_VERSION) { require "erb" } x.save! "/tmp/require.bench" x.compare! end ``` And the difference is massive: ``` Calculating ------------------------------------- 3.2.2 6.450M (± 1.2%) i/s - 32.822M in 5.089538s Comparison: 3.2.2: 6449899.4 i/s 3.3.3: 46996.8 i/s - 137.24x slower ``` And that's with a small `$LOAD_PATH`, the bigger the application, the worse it is, if I add: ```ruby 100.times do |i| $LOAD_PATH.unshift("/tmp/empty-#{i}") end ``` ``` Calculating ------------------------------------- 3.3.3 6.198k (± 6.1%) i/s - 30.968k in 5.018955s Comparison: 3.2.2: 3380939.6 i/s 3.3.3: 6198.4 i/s - 545.46x slower ``` I'm looking at a way to speed this up, but this is big enough that I believe we should backport the fix. cc @hsbt -- https://bugs.ruby-lang.org/

2 2