January 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:119751] [Ruby master Bug#20871] Including methods in Enumerable doesn't make them available in Array
by sanderd17 (Sander Deryckere) 15 Jan '25

15 Jan '25

Issue #20871 has been reported by sanderd17 (Sander Deryckere). ---------------------------------------- Bug #20871: Including methods in Enumerable doesn't make them available in Array https://bugs.ruby-lang.org/issues/20871 * Author: sanderd17 (Sander Deryckere) * Status: Open * ruby -v: 3.3.6 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Today, our CI pipeline started failing after the automatic update from v3.3.5 to v3.3.6. After researching, it turned out that our core extensions to the `Array` class weren't loaded anymore. The core-extensions code looks like this: ```ruby module CoreExt module Enumerable def average sum(&:to_f) / count if any? end # def ... end end Enumerable.include CoreExt::Enumerable ``` After some debugging, it turned out that the `average` method was included in the `instance_methods` of `Enumerable`, but not in the `instance_methods` of `Array`. Explicitly adding `Array.include CoreExt::Enumerable` fixes CI for our case. The very strange thing is that it only happens on a release branch we are still maintaining. It doesn't happen on our main development branch (which also updated to v3.3.6 today). I have been unable to find the difference between both branches so far (they diverged a couple of months ago, but the base system is still regularly updated on both, and pretty similar). After some digging around, I assume this commit is related to our issue: https://github.com/ruby/ruby/commit/edeb0319f7a95dfe3f9b895bcf32371dd8514726 -- https://bugs.ruby-lang.org/

6 12

[ruby-core:119998] [Ruby master Bug#20907] Fiber scheduler does not correctly re-lock mutex if `Mutex#sleep` is interrupted.
by ioquatix (Samuel Williams) 15 Jan '25

15 Jan '25

Issue #20907 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #20907: Fiber scheduler does not correctly re-lock mutex if `Mutex#sleep` is interrupted. https://bugs.ruby-lang.org/issues/20907 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- The following test fails with a `ThreadError` instead of a `RuntimeError`: ```ruby def test_condition_variable condition_variable = ::Thread::ConditionVariable.new mutex = ::Thread::Mutex.new error = nil thread = Thread.new do Thread.current.report_on_exception = false scheduler = Scheduler.new Fiber.set_scheduler scheduler fiber = Fiber.schedule do begin mutex.synchronize do condition_variable.wait(mutex) end rescue => error end end fiber.raise(RuntimeError) end thread.join assert_kind_of RuntimeError, error end ``` Fix: https://github.com/ruby/ruby/pull/12158 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:119903] [Ruby master Bug#20892] `ObjectSpace.dump` can produce broken JSON for classes with temporary names
by byroot (Jean Boussier) 15 Jan '25

15 Jan '25

Issue #20892 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #20892: `ObjectSpace.dump` can produce broken JSON for classes with temporary names https://bugs.ruby-lang.org/issues/20892 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- ```ruby puts ObjectSpace.dump(Class.new.tap { |c| c.set_temporary_name('" little boby table') }) ``` Produces the following JSON: ```json { "address":"0x120bea980", "type":"CLASS", "shape_id":2, "slot_size":160, "class":"0x120bea840", "variation_count":0, "superclass":"0x1041ffd38", "name":"" little boby table", "references":["0x1041ffd38", "0x123e71a98"], "memsize":192, "flags":{"wb_protected":true} } ``` Notice how the `name` property is broken. This only impacts 3.3.x, as that's when `set_temporary_name` was introduced, before that, it was impossible to assign a name that would cause such bug. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:119884] [Ruby master Bug#20886] Crash due to double free on regex timeout after stack allocations
by jhawthorn (John Hawthorn) 15 Jan '25

15 Jan '25

Issue #20886 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #20886: Crash due to double free on regex timeout after stack allocations https://bugs.ruby-lang.org/issues/20886 * Author: jhawthorn (John Hawthorn) * Status: Open * ruby -v: ruby 3.3.6 (2024-11-05 revision 75015d4c1f) [x86_64-linux] * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- As of the change from #20650 ([1057485](https://github.com/ruby/ruby/commit/10574857ce167869524b97ee862b61…) it's possible to crash on a double free due to `stk_alloc` AKA `msa->stack_p` being freed twice, once at the end of match_at and a second time in `FREE_MATCH_ARG` in the parent caller. It's fairly, but not quite 100% reliable to reproduce, adjusting the timeout or number of spaces can help. I reduced this test case from a larger real-world regex, I believe the first part is important just to disable the match cache. ``` $ ruby -e 'Regexp.new("d()*+|a*a*bc", timeout: 0.2) === "b" + "a"*800' double free or corruption (!prev) ``` https://github.com/ruby/ruby/pull/12030 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:119764] [Ruby master Bug#20873] `printf("%f")` returns wrong result for `Rational` with `FIXNUM_MIN`
by nobu (Nobuyoshi Nakada) 15 Jan '25

15 Jan '25

Issue #20873 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20873: `printf("%f")` returns wrong result for `Rational` with `FIXNUM_MIN` https://bugs.ruby-lang.org/issues/20873 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Since the beginning, ruby 2.3. ```ruby require 'rbconfig/sizeof' fmin, fmax = RbConfig::LIMITS.values_at("FIXNUM_MIN", "FIXNUM_MAX") sprintf("%f", Rational(fmin, fmax)) #=> --1.000000 ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:119855] [Ruby master Bug#20883] sprintf with binary strings has incorrect coderange
by jhawthorn (John Hawthorn) 15 Jan '25

15 Jan '25

Issue #20883 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #20883: sprintf with binary strings has incorrect coderange https://bugs.ruby-lang.org/issues/20883 * Author: jhawthorn (John Hawthorn) * Status: Open * ruby -v: ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux] * Backport: 3.1: DONTNEED, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- In [9dc6065](https://github.com/ruby/ruby/commit/9dc60653db186b1ae9400ed75b413a… we stopped updating the coderange when the encoding became ENCINDEX_ASCII_8BIT. Though ASCII-8BIT (binary) can't ever have a broken coderange, it does need to distinguish between 7bit and valid. ``` ruby puts ("%s" % "\xe2".b).ascii_only? # => false from Ruby 2.1 to 3.1 # => true (incorrect) on Ruby 3.2 and 3.3 # => false again on HEAD ``` This was fixed in master as part of #20189, which clears the coderange in more cases of `rb_str_resize` which happens to fix this, but we shouldn't rely on it. https://github.com/ruby/ruby/pull/12029 -- https://bugs.ruby-lang.org/

3 4

[ruby-core:119738] [Ruby master Bug#20868] Method#hash changes after compaction
by peterzhu2118 (Peter Zhu) 15 Jan '25

15 Jan '25

Issue #20868 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #20868: Method#hash changes after compaction https://bugs.ruby-lang.org/issues/20868 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- Fix: https://github.com/ruby/ruby/pull/12004 The hash value of a Method may change after a compaction but must remain constant because otherwise it may not work as the key in a hash table. For example: ```ruby def a; end # Need this method here because otherwise the iseq may be on the C stack # which would get pinned and not move during compaction def get_hash method(:a).hash end puts get_hash # => 2993401401091578131 GC.verify_compaction_references(expand_heap: true, toward: :empty) puts get_hash # => -2162775864511574135 ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:119470] [Ruby master Bug#20787] IO#readline does not check its arguments like IO#gets and will read more data than limit
by javanthropus (Jeremy Bopp) 15 Jan '25

15 Jan '25

Issue #20787 has been reported by javanthropus (Jeremy Bopp). ---------------------------------------- Bug #20787: IO#readline does not check its arguments like IO#gets and will read more data than limit https://bugs.ruby-lang.org/issues/20787 * Author: javanthropus (Jeremy Bopp) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- In revision d3574c117a637a4456aa3ee78e24d8df510b9355, the implementation of IO#readline was modified and consequently broke argument handling in a subtle way. It no longer checks that the encoding of the separator string is compatible with the internal encoding of the stream. Prior to version 3.3.0, the following script raises an ArgumentError when calling #readline: ```ruby require "tempfile" Tempfile.open(encoding: "utf-8:utf-32le") { |f| f.write("0123456789"); f.rewind; f.readline("\0", 1); } ``` After 3.3.0, the script will read all the data in the file, in this case 40 bytes, even though the limit argument is 1. Replacing #readline with #gets raises the ArgumentError in all versions. I'm fairly sure that the failure to check the separator string encoding leads to the incorrect handling of the limit argument. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120252] [Ruby master Bug#20955] Subtle differences with Proc#parameters for anonymous parameters
by zverok (Victor Shepelev) 14 Jan '25

14 Jan '25

Issue #20955 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #20955: Subtle differences with Proc#parameters for anonymous parameters https://bugs.ruby-lang.org/issues/20955 * Author: zverok (Victor Shepelev) * Status: Open * ruby -v: ruby 3.4.0dev (2024-12-15T13:36:38Z master 366fd9642f) +PRISM [x86_64-linux] * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: DONTNEED ---------------------------------------- ```ruby p proc { |x| }.parameters #=> [[:opt, :x]] p lambda { |x| }.parameters #=> [[:req, :x]] p proc { _1 }.parameters #=> [[:opt, :_1]] p lambda { _1 }.parameters #=> [[:req, :_1]] p proc { it }.parameters #=> [[:opt, nil]] p lambda { it }.parameters #=> [[:req]] ``` Note the last pair; here are two small confusing problems: 1. For proc, unlike numbered parameters, the parameter name is `nil` (not `it`). This, though, can be justified to distinguish from `proc { |it| }` case 2. But also, `proc` has this `nil` for a parameter name, while `lambda` has not. I am not sure what the “most logical” thing to do here, but I believe that at least `proc { it }` and `lambda { it }` should be made consistent with each other. -- https://bugs.ruby-lang.org/

4 8

[ruby-core:120664] RubyKaigi 2025 CFP is closing soon!
by Akira Matsuda 14 Jan '25

14 Jan '25

Hello, ruby-core ML readers! Let me remind you that CFP for RubyKaigi 2025 is closing this week. As you may know, RubyKaigi wants to focus on Ruby language core development, and thus we're eagerly looking forward to hearing hack stories from Ruby hackers like you who are reading this mailing list. The CFP form is closing in 5 days. Don't miss a chance to reveal your hack to the real world! https://cfp.rubykaigi.org/events/2025 -- Akira Matsuda<ronnie(a)dio.jp>

1 0