April 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:112721] [Ruby master Bug#19482] Fix crash when allocating classes with newobj hook
by peterzhu2118 (Peter Zhu) 16 Jul '23

16 Jul '23

Issue #19482 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #19482: Fix crash when allocating classes with newobj hook https://bugs.ruby-lang.org/issues/19482 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/7464 We need to zero out the whole slot when running the newobj hook for a newly allocated class because the slot could be filled with garbage, which would cause a crash if a GC runs inside of the newobj hook. For example, the following script crashes: ```ruby require "objspace" GC.stress = true ObjectSpace.trace_object_allocations { 100.times do Class.new end } ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:112723] [Ruby master Bug#19483] rubyzip not behaving well with YJIT
by k0kubun (Takashi Kokubun) 16 Jul '23

16 Jul '23

Issue #19483 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Bug #19483: rubyzip not behaving well with YJIT https://bugs.ruby-lang.org/issues/19483 * Author: k0kubun (Takashi Kokubun) * Status: Open * Priority: Normal * Assignee: yjit * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- Copied from https://github.com/Shopify/yjit/issues/310 for backports. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:112578] [Ruby master Bug#19463] YJIT `[BUG] Stack consistency error` under certain invalidation scenarios
by alanwu (Alan Wu) 16 Jul '23

16 Jul '23

Issue #19463 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #19463: YJIT `[BUG] Stack consistency error` under certain invalidation scenarios https://bugs.ruby-lang.org/issues/19463 * Author: alanwu (Alan Wu) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) +YJIT [arm64-darwin22] * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- > test.rb:19: [BUG] Stack consistency error (sp: 15, bp: 16) With the following: ```ruby klass = Class.new do def self.lookup(hash, key) = hash[key] def self.foo(a, b) = [] def self.test(hash, key) [lookup(hash, key), key, "".freeze] # 05 opt_send_without_block :lookup # 07 getlocal_WC_0 :hash # 09 opt_str_freeze "" # 12 newarray 3 # 14 leave # # YJIT will put instructions (07..14) into a block. # When String#freeze is redefined from within lookup(), # the return address to the block is still on-stack. We rely # on invalidation patching the code at the return address # to service this situation correctly. end end # get YJIT to compile test() hash = { 1 => [] } 31.times { klass.test(hash, 1) } # inject invalidation into lookup() evil_hash = Hash.new do |_, key| class String undef :freeze def freeze = :ugokanai end key end p klass.test(evil_hash, 1) ``` The fix is fairly simple and I'll apply it shortly. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:113251] [Ruby master Feature#19600] Method `clamp?`
by sawa (Tsuyoshi Sawada) 13 Jul '23

13 Jul '23

Issue #19600 has been reported by sawa (Tsuyoshi Sawada). ---------------------------------------- Feature #19600: Method `clamp?` https://bugs.ruby-lang.org/issues/19600 * Author: sawa (Tsuyoshi Sawada) * Status: Open * Priority: Normal ---------------------------------------- Currently, we have pairs of non-predicate and predicate methods like `String#match` and `String#match?`. They are brain-friendly, and make programmers happier. Along this line, I propose the following: 1. Since by #19588, `Comparable#clamp`'s behavior is made the same as `Range#cover?` for range arguments, alias `Range#cover?` as `Range#clamp?`. 2. Synchronize the specification of `Comparable#between?` with `Comparable#clamp`, i.e., a. Allow `Comparable#between?` to take range arguments, and b. Allow `Comparable#between?` to take `nil` as either or both of its arguments, or as either or both ends of its range argument. 3. Alias `Comparable#between?` as `Comparable#clamp?` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:112988] [Ruby master Bug#19544] Custom quotes inconsistency
by hurricup (Alexandr Evstigneev) 11 Jul '23

11 Jul '23

Issue #19544 has been reported by hurricup (Alexandr Evstigneev). ---------------------------------------- Bug #19544: Custom quotes inconsistency https://bugs.ruby-lang.org/issues/19544 * Author: hurricup (Alexandr Evstigneev) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- According to `parse_percent` in `parse.y`: For `%` we should be able use ascii non alphanumeric delimiters. But, `p % jim beam ;` does not work. Presumably because of some look-ahead distincting `%` from percent-string starter. Seems it is the same for any `\s` after `%` For the explicit `%` construction, with type specifier `%[QqWwIisrx]` we should be able to use non-alphanumeric ascii characters, which includes `\s`. But: This works: ``` p %s jim beam ``` And this does not: ``` p %w jim\ beam ``` with unterminated list error. First seems unavoidable, but second looks like obvious error of finding terminating `\n` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:112773] [Ruby master Feature#19521] Support for `Module#name=` and `Class#name=`.
by ioquatix (Samuel Williams) 02 Jul '23

02 Jul '23

Issue #19521 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #19521: Support for `Module#name=` and `Class#name=`. https://bugs.ruby-lang.org/issues/19521 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- See https://bugs.ruby-lang.org/issues/19450 for previous discussion and motivation. This proposal introduces `Class#name=` to set the temporary class name. This is an alternative or addition to <https://bugs.ruby-lang.org/issues/19520>. ```ruby c = Class.new do self.name = "fake name" end c = Class.new c.name = "fake name" ``` Alternatively, we could use `set_name`: ```ruby Class.new do set_name "fake_name" end ``` ## Example usage The current Ruby test suite has code which shows the usefulness of this new method: ```ruby def labeled_module(name, &block) Module.new do singleton_class.class_eval { define_method(:to_s) {name} alias inspect to_s alias name to_s } class_eval(&block) if block end end module_function :labeled_module def labeled_class(name, superclass = Object, &block) Class.new(superclass) do singleton_class.class_eval { define_method(:to_s) {name} alias inspect to_s alias name to_s } class_eval(&block) if block end end module_function :labeled_class ``` The updated code would look like this: ```ruby def labeled_module(name, &block) Module.new do self.name = name class_eval(&block) if block end end def labeled_class(name, superclass = Object, &block) Class.new(superclass) do self.name = name class_eval(&block) if block end end module_function :labeled_class ``` Because the name cannot be set as part of `.new`, we have to have a separate block to set the name, before calling `class_eval`. I think the ergonomics and performance of this are slightly worse than the [counter proposal](https://bugs.ruby-lang.org/issues/19520). -- https://bugs.ruby-lang.org/

10 30

[ruby-core:112871] [Ruby master Bug#19529] [BUG] ObjectSpace::WeakMap can segfault after compaction
by byroot (Jean Boussier) 25 Jun '23

25 Jun '23

Issue #19529 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #19529: [BUG] ObjectSpace::WeakMap can segfault after compaction https://bugs.ruby-lang.org/issues/19529 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * ruby -v: 3.2.1, 2.7.5p203 * Backport: 2.7: WONTFIX, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- Reproduction script: ```ruby wm = ObjectSpace::WeakMap.new obj = Object.new 100.times do |i| GC.compact wm[i] = obj # [BUG] Segmentation fault at 0x0000000000000001 end ``` Crash report: ``` /tmp/weakmap.rb:5: [BUG] Segmentation fault at 0x0000000000000003 ruby 3.2.1 (2023-02-08 revision 31819e82c8) [arm64-darwin22] -- Crash Report log information -------------------------------------------- See Crash Report log file in one of the following locations: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. -- Control frame information ----------------------------------------------- c:0005 p:---- s:0023 e:000022 CFUNC :[]= c:0004 p:0016 s:0017 e:000015 BLOCK /tmp/weakmap.rb:5 [FINISH] c:0003 p:---- s:0012 e:000011 CFUNC :times c:0002 p:0017 s:0008 E:0025b0 EVAL /tmp/weakmap.rb:3 [FINISH] c:0001 p:0000 s:0003 E:0010b0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- /tmp/weakmap.rb:3:in `<main>' /tmp/weakmap.rb:3:in `times' /tmp/weakmap.rb:5:in `block in <main>' /tmp/weakmap.rb:5:in `[]=' -- Machine register context ------------------------------------------------ x0: 0x000000016da8a6b0 x1: 0x000000016da8a6a8 x2: 0x000000000000003d x3: 0x0000000000000001 x4: 0x0000000000000000 x5: 0x0000000000000b00 x6: 0x0000600002db4b00 x7: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x000000016da8a6a8 x20: 0x000000000000003d x21: 0x0000000000000003 x22: 0x0000000000000001 x23: 0x00000001023df7b8 x24: 0x0000000000000001 x25: 0x0000000000000000 x26: 0x00006000027bdf80 x27: 0xffffffffffffffff x28: 0xffffffffffffffff lr: 0x0000000102ca28f0 fp: 0x000000016da8a680 sp: 0x000000016da8a640 -- C level backtrace information ------------------------------------------- /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_vm_bugreport+0x9a0) [0x102d3ba98] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_bug_for_fatal_signal+0x160) [0x102b5fe14] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(sig_do_nothing+0x0) [0x102c9a354] /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x19b63c2a4] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_st_update+0x328) [0x102ca28f0] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_st_update+0x328) [0x102ca28f0] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(wmap_aset+0x90) [0x102b88e9c] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_call_cfunc_with_frame+0xe8) [0x102d2fc7c] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_sendish+0x4cc) [0x102d31fdc] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_exec_core+0x239c) [0x102d136c8] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_vm_exec+0xad4) [0x102d26bf0] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(invoke_block_from_c_bh+0x398) [0x102d36438] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_yield_1+0x7c) [0x102d1f208] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(int_dotimes+0x148) [0x102bff3ec] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_call_cfunc_with_frame+0xe8) [0x102d2fc7c] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_sendish+0x4cc) [0x102d31fdc] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_exec_core+0x2350) [0x102d1367c] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_vm_exec+0xad4) [0x102d26bf0] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_ec_exec_node+0x12c) [0x102b6b4ac] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(ruby_run_node+0x60) [0x102b6b318] /opt/rubies/3.2.1/bin/ruby(main+0x68) [0x102377f34] ``` Seems to happens since 2.7. -- https://bugs.ruby-lang.org/

6 11

[ruby-core:111735] [Ruby master Bug#19323] Integer overflow in `Integer#<<`
by nobu (Nobuyoshi Nakada) 25 Jun '23

25 Jun '23

Issue #19323 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19323: Integer overflow in `Integer#<<` https://bugs.ruby-lang.org/issues/19323 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 2.7: REQUIRED, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- ```ruby require 'rbconfig/sizeof' char_bit = RbConfig::LIMITS["UCHAR_MAX"].bit_length size_max = RbConfig::LIMITS["SIZE_MAX"] size_bit_max = size_max * char_bit 1 << size_bit_max ``` The above code raises an "integer overflow" error. ``` -:5:in `<<': integer overflow: 4611686018427387905 * 4 > 18446744073709551615 (ArgumentError) from -:5:in `<main>' ``` It doesn't seem like a proper or intentional exception. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:112697] [Ruby master Bug#19479] Support IPv4-mapped IPv6 addresses in IPAddr#private?
by tgxworld (Guo Xiang Tan) 22 Jun '23

22 Jun '23

Issue #19479 has been reported by tgxworld (Guo Xiang Tan). ---------------------------------------- Bug #19479: Support IPv4-mapped IPv6 addresses in IPAddr#private? https://bugs.ruby-lang.org/issues/19479 * Author: tgxworld (Guo Xiang Tan) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` irb(main):010:0> IPAddr.new("172.16.0.0").private? => true irb(main):011:0> IPAddr.new("::ffff:172.16.0.0").private? => false ``` If IPAddr#private? is used in a critical code path, not supporting IPv4-mapped IPv6 addresses could lead to security issues. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:113083] [Ruby master Bug#19569] #map on Enumerator::Lazy block arguments differ from regular #map
by TomNaessens (Tom Naessens) 21 Jun '23

21 Jun '23

Issue #19569 has been reported by TomNaessens (Tom Naessens). ---------------------------------------- Bug #19569: #map on Enumerator::Lazy block arguments differ from regular #map https://bugs.ruby-lang.org/issues/19569 * Author: TomNaessens (Tom Naessens) * Status: Open * Priority: Normal * ruby -v: 3.0.5...3.2.0 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- A Ruby 2 to 3 upgrade surfaced the following issue: Ruby 2: ``` irb(main):252:0> [1, 2, 3].to_enum.lazy.zip([:a, :b, :c]).map(&:last).to_a => [:a, :b, :c] ``` Ruby 3: ``` irb(main):020:0> [1, 2, 3].to_enum.lazy.zip([:a, :b, :c]).map(&:last).to_a (irb):20:in `each': undefined method `last' for 1:Integer (NoMethodError) ``` Debugging the issue, I noticed the following: Map with a block returns only the first argument (and seems to ignore the zipped list): ``` irb(main):024:0> [1, 2, 3].to_enum.lazy.zip([:a, :b, :c]).map { |x| x }.to_a => [1, 2, 3] ``` It's not actually ignored though, it's just passed as a second argument: ``` irb(main):025:0> [1, 2, 3].to_enum.lazy.zip([:a, :b, :c]).map { |*x| x }.to_a => [[1, :a], [2, :b], [3, :c]] ``` Thus, this looks like a workaround: ``` irb(main):026:0> [1, 2, 3].to_enum.lazy.zip([:a, :b, :c]).map { |*x| x.last }.to_a => [:a, :b, :c] ``` But it behaves differently when leaving the `lazy` out: ``` irb(main):027:0> [1, 2, 3].to_enum.zip([:a, :b, :c]).map { |*x| x.last }.to_a => [[1, :a], [2, :b], [3, :c]] ``` Not sure if I'm correct in my conclusion, but to me it looks like the argument handling of `map` and `lazy_map` differs in an unexpected manner. Is this a bug/oversight, or I am simply using the different map implementations wrong? -- https://bugs.ruby-lang.org/

2 1