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

[ruby-core:121140] [Ruby master Bug#21152] Enumerator's #size returned by Range#reverse_each raises an exception for endless Range
by andrykonchin (Andrew Konchin) 13 Mar '25

13 Mar '25

Issue #21152 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #21152: Enumerator's #size returned by Range#reverse_each raises an exception for endless Range https://bugs.ruby-lang.org/issues/21152 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.4.2 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I've noticed a change between 3.3 and 3.4 in a way how `Range#reverse_each` behaves: Ruby 3.3: ```ruby Range.new("a", nil).size # => nil Range.new(1, nil).size # => Infinity Range.new("a", nil).reverse_each.size # => nil Range.new(1, nil).reverse_each.size # => Infinity ``` Ruby 3.4 ```ruby Range.new("a", nil).size # => nil Range.new(1, nil).size # => Infinity Range.new("a", nil).reverse_each.size # can't iterate from NilClass (TypeError) Range.new(1, nil).reverse_each.size # can't iterate from NilClass (TypeError) ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:121136] [Ruby master Bug#21151] IO and StringIO raise FrozenError even for read-only methods
by headius (Charles Nutter) 13 Mar '25

13 Mar '25

Issue #21151 has been reported by headius (Charles Nutter). ---------------------------------------- Bug #21151: IO and StringIO raise FrozenError even for read-only methods https://bugs.ruby-lang.org/issues/21151 * Author: headius (Charles Nutter) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Problem -------- While fixing a small [regression](https://github.com/ruby/stringio/issues/119) from my recent StringIO [fixes](https://github.com/ruby/stringio/issues/116) I discovered that a large number of read-only methods will fail if the StringIO is frozen. A few examples: ``` $ ruby -rstringio -e 's = StringIO.new; p s.lineno; s.freeze; p s.lineno' 0 -e:1:in 'StringIO#lineno': can't modify frozen StringIO: #<StringIO:0x0000000103711ea8> (FrozenError) from -e:1:in '<main>' $ ruby -rstringio -e 's = StringIO.new; p s.closed?; s.freeze; p s.closed?' false -e:1:in 'StringIO#closed?': can't modify frozen StringIO: #<StringIO:0x00000001008c1e68> (FrozenError) from -e:1:in '<main>' $ ruby -rstringio -e 's = StringIO.new; p s.eof?; s.freeze; p s.eof?' true -e:1:in 'StringIO#eof?': can't modify frozen StringIO: #<StringIO:0x000000011c171e80> (FrozenError) from -e:1:in '<main>' $ ruby -rstringio -e 's = StringIO.new; p s.pos; s.freeze; p s.pos' 0 -e:1:in 'StringIO#pos': can't modify frozen StringIO: #<StringIO:0x0000000105551df0> (FrozenError) from -e:1:in '<main>' ``` @kou pointed out that IO also raises for at least `lineno` and suggested I re-open the issue here. I still believe these read-only operations should be allowed on frozen IO or StringIO. Cause in StringIO ----------------- This is because the `StringIO` macro calls `get_strio` which calls `rb_io_taint_check` which calls `rb_check_frozen`. The `StringIO` macro is used in almost every method to access the rb_stringio_t data structure. A list of methods I believe should be operable when the StringIO is frozen (in stringio.c definition order): * string (returns underlying String but does not mutate anything) * lineno * pos * closed?/closed_read?/closed_write? * eof/eof? * sync * pid (a dummy method but it writes nothing) * fileno (dummy) * pread (by definition does not modify state) * isatty/tty? * size/length * external_encoding * internal_encoding In addition, `initialize_copy` probably should not require the original StringIO to be writable: ``` $ ruby -rstringio -e 's = StringIO.new("foo"); s.freeze; p s.dup' -e:1:in 'StringIO#initialize_copy': can't modify frozen StringIO: #<StringIO:0x0000000102eb1df8> (FrozenError) from -e:1:in 'Kernel#initialize_dup' from -e:1:in 'Kernel#dup' from -e:1:in '<main>' ``` The data from the original StringIO is unmodified by `initialize_copy`, other than the reference-counting `ptr->count` (which should not be subject to frozen checks). Cause in IO ----------- The `GetOpenFile` macro calls `RB_IO_POINTER` macro which calls `rb_io_taint_check` which calls `rb_check_frozen`. Methods in IO that should work on a frozen IO include any of the above StringIO that currently raise. For example `lineno` uses `GetOpenFile`, but `fileno` does not and does not raise. There's clearly some inconsistency here we can clean up. Origin ------ I believe most of the StringIO cases are caused by this change from 2011 that added frozen checks to StringIO (the class and the macro): https://github.com/ruby/ruby/commit/d8d9bac5c8b071135e50ad3f21c8a9b6a9c06e54 In IO, this behavior dates way back to 2000 by @matz himself: https://github.com/ruby/ruby/commit/087c83d7ceed6893afff93066937fb570ae4a115 Notes ----- I have started to fix the StringIO cases for JRuby in https://github.com/ruby/stringio/pull/122. I could probably fix the C version of StringIO as well, but I'm a little more unsure about how to fix IO. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:118944] [Ruby master Bug#20698] Please backport fix for CVE-2024-43398
by vo.x (Vit Ondruch) 13 Mar '25

13 Mar '25

Issue #20698 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20698: Please backport fix for CVE-2024-43398 https://bugs.ruby-lang.org/issues/20698 * Author: vo.x (Vit Ondruch) * 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 ---------------------------------------- This is similar request to #20667, but since that was already partially done, I have decided to open new ticket -- https://bugs.ruby-lang.org/

4 4

[ruby-core:113153] [Ruby master Bug#19584] Crash in rb_gc_register_address
by peterzhu2118 (Peter Zhu) 13 Mar '25

13 Mar '25

Issue #19584 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #19584: Crash in rb_gc_register_address https://bugs.ruby-lang.org/issues/19584 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/7670 Some C extensions pass a pointer to a global variable to rb_gc_register_address. However, if a GC is triggered inside of rb_gc_register_address, then the object could get swept since it does not exist on the stack. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:115512] [Ruby master Bug#20025] Parsing identifiers/constants is case-folding dependent
by kddnewton (Kevin Newton) 13 Mar '25

13 Mar '25

Issue #20025 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20025: Parsing identifiers/constants is case-folding dependent https://bugs.ruby-lang.org/issues/20025 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When CRuby parses identifiers, it is encoding-dependent. Once the identifier is found, it determines if it starts with a uppercase or lowercase codepoint. This determines if the identifier is a constant or not. The function is charge of this is `rb_sym_constant_char_p`. For non-unicode encodings where the leading byte has the top-bit set, this relies on onigmo's `mbc_case_fold` to determine if it is a constant or not (as opposed to `is_code_ctype`). This works for almost every single codepoint in every encoding, but has one very weird edge case. In the Windows-1253 encoding for the 0xB5 byte, it's the micro sign. The micro sign, when case folded, becomes the uppercase mu character, and then the lowercase mu character, or 0xEC. This means that even though 0xB5 reports itself as being a lowercase codepoint, it gets parsed as a constant. This example might make this more clear: ``` ruby class Context < BasicObject def method_missing(name, *) = :identifier def self.const_missing(name) = :constant end encoding = Encoding::Windows_1253 character = 0xB5.chr(encoding) source = "# encoding: #{encoding.name}\n#{character}\n" result = Context.new.instance_eval(source) puts "#{encoding.name} encoding of 0x#{character.ord.to_s(16).upcase}" puts " [[:alpha:]] => #{character.match?(/[[:alpha:]]/)}" puts " [[:alnum:]] => #{character.match?(/[[:alnum:]]/)}" puts " [[:upper:]] => #{character.match?(/[[:upper:]]/)}" puts " [[:lower:]] => #{character.match?(/[[:lower:]]/)}" puts " parsed as #{result}" ``` this results in the output of: ``` Windows-1253 encoding of 0xB5 [[:alpha:]] => true [[:alnum:]] => true [[:upper:]] => false [[:lower:]] => true parsed as constant ``` To be clear, I don't think the case-folding is incorrect here (and @duerst confirms that it is correct). I believe instead that it is incorrect to use case-folding here to determine if a codepoint is uppercase or not. Note that this only impacts this one codepoint in this one encoding, so I don't believe this is actually a large-scale problem. But I found it surprising, and think we should change it. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:112301] [Ruby master Bug#19426] Endless `Range#step` of object with `#succ` method does not work
by nobu (Nobuyoshi Nakada) 13 Mar '25

13 Mar '25

Issue #19426 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19426: Endless `Range#step` of object with `#succ` method does not work https://bugs.ruby-lang.org/issues/19426 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Consider this `c` object which hash `#succ` method. ```ruby c = Struct.new(:i) do def succ; self.class.new(i+1); end def <=>(other) i <=> other.i;end end.new(0) ``` This `Range#step` works. ```ruby (c..c.succ).step(1) do |d| p d.i # 0, 1 end ``` But it fails on an endless range. ```ruby (c..).step(1) do |d| p d.i break if d.i > 3 end ``` ``` -:3:in `<=>': undefined method `i' for nil:NilClass (NoMethodError) from -:10:in `step' from -:10:in `<main>' ``` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:120637] [Ruby master Bug#21032] `Module#autoload?` is slow when `$LOAD_PATH` contains a relative path
by byroot (Jean Boussier) 13 Mar '25

13 Mar '25

Issue #21032 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21032: `Module#autoload?` is slow when `$LOAD_PATH` contains a relative path https://bugs.ruby-lang.org/issues/21032 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.1: WONTFIX, 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- Reproduction script: ```ruby require 'benchmark' $LOAD_PATH << 'relative-path' autoload :FOO, '/tmp/foo.rb' puts Benchmark.realtime { 500_000.times do Object.autoload?(:FOO) end } ``` The above takes 2.5 to 3 seconds on my machine, but just removing `$LOAD_PATH << 'relative-path'` make it complete in 50ms. It's such a stark difference that I think it is a bug, and it cause Zeitwerk, a very popular gem, to be way slower than it should when the load path contains relative paths. I have a patch for it, that passes all tests, but I'd appreciate some eyes on it: https://github.com/ruby/ruby/pull/12562 cc @fxn -- https://bugs.ruby-lang.org/

5 8

[ruby-core:120949] [Ruby master Bug#21129] Backporting strscan fix in Ruby 3.2
by andrykonchin (Andrew Konchin) 12 Mar '25

12 Mar '25

Issue #21129 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #21129: Backporting strscan fix in Ruby 3.2 https://bugs.ruby-lang.org/issues/21129 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.2.7 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- An `strscan` version shipped with Ruby 3.2 (`strscan` v3.0.5) has a bug. It was fixed long time ago in `strscan` v3.0.7 (in https://github.com/ruby/strscan/pull/61) but reported recently again in https://github.com/ruby/strscan/issues/132. Ruby 3.2 AFAIK is still normally supported. So does it make sense to have a new Ruby 3.2.x patch level release with `strscan` v3.0.7? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120232] [Ruby master Misc#20951] Confusing handling of timezone object's `#utc_to_local` results
by andrykonchin (Andrew Konchin) 12 Mar '25

12 Mar '25

Issue #20951 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Misc #20951: Confusing handling of timezone object's `#utc_to_local` results https://bugs.ruby-lang.org/issues/20951 * Author: andrykonchin (Andrew Konchin) * Status: Open ---------------------------------------- I am looking into the timezone object feature (that is supported by various Time class methods) now and I am confused by the current implementation. Specifically, how a time-like object **that is not inherited from the Time class** is handled. A time-like object is returned for instance from the timezone object's `#utc_to_local` method. The documentation states that: > A Time-like object is a container object capable of interfacing with timezone libraries for timezone conversion. Also > The zone value may be an object responding to certain timezone methods, an instance of Timezone and TZInfo for example. And indeed the `TZInfo::Timezone` class works as expected. But when I try to use for time-like objects a brand new class not inherited from Time - it works incorrectly. Let's consider an example with `TZInfo::Timezone`: ```ruby require 'tzinfo' zone = TZInfo::Timezone.get("Europe/Kiev") # UTC+2 time = Time.now.utc puts time.to_i # 1734107333 puts Time.now(in: zone) # 2024-12-13 18:28:53 +0200 puts zone.utc_to_local(time) # 2024-12-13 18:28:53 +0200 puts zone.utc_to_local(time).to_i # 1734107333 ``` And now an example with a brand new class. I make an assumption, that as far as `zone.utc_to_local(time).to_i` doesn't change Unix timestamp (it equals `time.to_i`, that's 1734107333), so in a new class also `#utc_to_local` should return not modified value too. ```ruby TimeObj = Struct.new(:year, :mon, :mday, :hour, :min, :sec, :isdst, :to_i) zone_obj = Object.new def zone_obj.utc_to_local(t) TimeObj.new(t.year, t.mon, t.mday, t.hour + 2, t.min, t.sec, t.isdst, t.to_i) # <=== adjust hours (`hours + 2`) to match "Europe/Kiev" timezone (that's UTC+2) end ``` Unfortunately it produces incorrect result: ```ruby puts Time.now(in: zone_obj) # 2024-12-13 18:28:53 +0000 <====== wrong UTC offset puts zone_obj.utc_to_local(time) # #<struct TimeObj year=2024, mon=12, mday=13, hour=18, min=28, sec=53, isdst=false, to_i=1734107333> puts zone_obj.utc_to_local(time).to_i # 1734107333 <===== the same Unix timestamp ``` So now result time object has wrong utc offset - `+0000` instead of `+0200`. Okey, so probably Unix timestamp should be adjusted as well. Let's check: ```ruby def zone_obj.utc_to_local(t) TimeObj.new(t.year, t.mon, t.mday, t.hour + 2, t.min, t.sec, t.isdst, t.to_i + 2 * 60 * 60) # <===== adjust #to_i as well so it returns timestamp + 2 hours end puts Time.now(in: zone_obj) # 2024-12-13 18:28:53 +0200 <======= correct UTC offset puts zone_obj.utc_to_local(time) # #<struct TimeObj year=2024, mon=12, mday=13, hour=18, min=28, sec=53, isdst=false, to_i=1734114533> puts zone_obj.utc_to_local(time).to_i # 1734114533 <====== different Unix timestamp ``` Now we have correct UTC offset `+0200` despite `zone_obj.utc_to_local(time).to_i` returns not original offset but an adjusted one. I assume the difference is caused by a special treatment of time-like object inherited from the Time class. So its `utc_offset` property is used only. But for all the other classes the `#to_i` is used instead. ```ruby zone.utc_to_local(time).class.ancestors # => [TZInfo::TimeWithOffset, TZInfo::WithOffset, Time, Comparable, Object, PP::ObjectMixin, Kernel, BasicObject] ``` This difference is confusing so I think it makes sense either to document it (I mean to document that `#to_i` should return adjusted value for non-related to Time classes) in case it's intentional or to change behaviour for non-related to Time classes and rely not on `#to_i` to calculate UTC offset but on difference in `sec`/`min`/`hours` values otherwise. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:121093] [Ruby master Bug#21146] VM_ASSERT(expr) gives bad bug report results when another ractor fails an assertion during printing of report
by luke-gru (Luke Gruber) 11 Mar '25

11 Mar '25

Issue #21146 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21146: VM_ASSERT(expr) gives bad bug report results when another ractor fails an assertion during printing of report https://bugs.ruby-lang.org/issues/21146 * Author: luke-gru (Luke Gruber) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- test.rb: ```ruby rs = 100.times.map do Ractor.new do cnt = rand 3 cnt += 1 if cnt.zero? sleep cnt 100.times do |i| if i != 0 && i % 50 == 0 Ractor.fail_assert end end end end ``` ractor.rb: ```ruby def self.fail_assert __builtin_cexpr! %q{ VM_ASSERT(0), Qfalse } end ``` > make run I would like to be able to see the bug report for the first failed assertion, without any output from the other ractors. -- https://bugs.ruby-lang.org/

2 3