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

[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:116369] [Ruby master Feature#20202] Memoized endless method definitions
by matheusrich (Matheus Richard) 27 Feb '25

27 Feb '25

Issue #20202 has been reported by matheusrich (Matheus Richard). ---------------------------------------- Feature #20202: Memoized endless method definitions https://bugs.ruby-lang.org/issues/20202 * Author: matheusrich (Matheus Richard) * Status: Open * Priority: Normal ---------------------------------------- I propose introducing a shorthand for memoized endless method definitions: ```rb class Foo def bar ||= :memoized_value # It should behave like def bar = (@bar ||= :memoized_value) end ``` Not only is this shorter and (IMO) a natural follow-up for endless method definitions, but it's also a common pattern on Ruby codebases. It's very useful to decompose responsibilities into several objects: ```rb class User def notifications_enabled? = settings.notifications? def enable_notifications = (settings.notifications = true) def disable_notifications = (settings.notifications = false) private def settings = @settings ||= Settings.new(self) end class User::Settings attr_writer :notifications def initialize(user) @user = user @notifications = false end def notifications? = @notifications end u = User.new u.notifications_enabled? # => false u.enable_notifications u.notifications_enabled? # => true ``` In the example, the `settings` method could be rewritten as ```rb def settings ||= Settings.new(self) ``` -- https://bugs.ruby-lang.org/

4 5

[ruby-core:118682] [Ruby master Misc#20652] Memory allocation for gsub has increased from Ruby 2.7 to 3.3
by orisano (Nao Yonashiro) 24 Feb '25

24 Feb '25

Issue #20652 has been reported by orisano (Nao Yonashiro). ---------------------------------------- Misc #20652: Memory allocation for gsub has increased from Ruby 2.7 to 3.3 https://bugs.ruby-lang.org/issues/20652 * Author: orisano (Nao Yonashiro) * Status: Open ---------------------------------------- I recently upgraded from ruby 2.7.7 to 3.3.1 and noticed that the GC load increased. When I used the allocation profiler to investigate, I found that memory allocation from gsub had increased. The problem was code like this: ```ruby s = "foo " s.gsub(/ (\s+)/) { " #{' ' * Regexp.last_match(1).length}" } ``` When I compared the results of heap-profiler between 2.7.7 and 3.3.1, I found that MatchData was increasing. https://gist.github.com/orisano/98792dee260106e9b6fcb45bbabeb1e6 https://github.com/ruby/ruby/commit/abc0304cb28cb9dcc3476993bc487884c139fd11 I discovered that the cause is this commit, which stopped reusing backref to avoid race conditions. Is there a way to reuse backref while still avoiding race conditions? -- https://bugs.ruby-lang.org/

9 27

[ruby-core:119142] [Ruby master Bug#20727] YJIT segmentation fault inside of invalidate_block_version
by jhawthorn (John Hawthorn) 18 Feb '25

18 Feb '25

Issue #20727 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #20727: YJIT segmentation fault inside of invalidate_block_version https://bugs.ruby-lang.org/issues/20727 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- For a while we've been seeing an occasional segfault in production inside of YJIT's invalidation code. It seems to happen most often when a invalidation on a widely used CME. ``` [BUG] Segmentation fault at 0x0000000000000014" "ruby 3.3.5 (2024-09-04 revision 4f143c3038) +YJIT [x86_64-linux]" null "-- Control frame information -----------------------------------------------" "c:0174 p:---- s:1247 e:001246 CFUNC :extend_object" "c:0173 p:---- s:1244 e:001243 CFUNC :extend" "c:0172 p:0049 s:1239 e:001238 METHOD /build/vendor/gems/3.3.5/ruby/3.3.0/gems/activerecord-8.0.0.alpha.6395186/lib/active_record/relation/query_methods.rb:1467" "c:0171 p:0024 s:1233 e:001232 METHOD /build/vendor/gems/3.3.5/ruby/3.3.0/gems/activerecord-8.0.0.alpha.6395186/lib/active_record/relation/query_methods.rb:1456" "c:0170 p:0055 s:1227 e:001226 METHOD /build/vendor/gems/3.3.5/ruby/3.3.0/gems/will_paginate-4.0.1/lib/will_paginate/active_record.rb:170" "c:0169 p:0076 s:1219 e:001218 METHOD /build/vendor/gems/3.3.5/ruby/3.3.0/gems/will_paginate-4.0.1/lib/will_paginate/active_record.rb:154" -----8<----- null "-- Threading information ---------------------------------------------------" "Total ractor count: 1" "Ruby thread count for this ractor: 19" null "-- Machine register context ------------------------------------------------" " RIP: 0x0000563c0aaccef7 RBP: 0x00007f481524f5f0 RSP: 0x00007fffe8631d70" " RAX: 0x0000000000000014 RBX: 0x0000000000000010 RCX: 0x000000000000000e" " RDX: 0x0000000002ff9bab RDI: 0x00007f4839357520 RSI: 0x0000000000000008" " R8: 0x00007f480cc0f5e0 R9: 0x0000000000000800 R10: 0x00007f48af4008c0" " R11: 0x0000000000000060 R12: 0x0000563c0ad93108 R13: 0x00007f4816abe260" " R14: 0x000000000000000e R15: 0x0000000002f9d50f EFL: 0x0000000000010206" null "-- C level backtrace information -------------------------------------------" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(rb_print_backtrace+0x11) [0x563c0a9ff8df] vm_dump.c:820" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(rb_vm_bugreport) vm_dump.c:1151" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(rb_bug_for_fatal_signal+0xfc) [0x563c0abc2a1c] error.c:1065" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(sigsegv+0x4d) [0x563c0a94e02d] signal.c:926" "/lib/x86_64-linux-gnu/libpthread.so.0(__restore_rt+0x0) [0x7f48afba1420]" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(0x563c0aaccef7) [0x563c0aaccef7]" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby({closure#0}) yjit/src/core.rs:718" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(invalidate_block_version) yjit/src/core.rs:3237" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby({closure#0}+0xe6) [0x563c0aaf1586] yjit/src/invariants.rs:246" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(do_call<yjit::invariants::rb_yjit_cme_invalidate::{closure_env#0}, ()>) /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(try<(), yjit::invariants::rb_yjit_cme_invalidate::{closure_env#0}>) /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(catch_unwind<yjit::invariants::rb_yjit_cme_invalidate::{closure_env#0}, ()>+0x8) [0x563c0aae2d68] /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/s> "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(with_vm_lock<yjit::invariants::rb_yjit_cme_invalidate::{closure_env#0}, ()>) yjit/src/cruby.rs:646" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(rb_yjit_cme_invalidate+0x5c) [0x563c0aae6e0c] yjit/src/invariants.rs:243" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(vm_cme_invalidate+0x12) [0x563c0a9d78bd] vm_method.c:126" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(clear_method_cache_by_id_in_class) vm_method.c:240" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(clear_module_cache_i+0x13) [0x563c0ab2d263] class.c:1234" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(rb_id_table_foreach+0x84) [0x563c0a9891c4] id_table.c:278" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(do_include_modules_at+0x16a) [0x563c0ab31a0a] class.c:1314" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(include_modules_at+0x1a) [0x563c0ab31f61] class.c:1370" -----8<----- ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120335] [Ruby master Feature#20971] Deprecate `rb_path_check`
by Earlopain (Earlopain _) 14 Feb '25

14 Feb '25

Issue #20971 has been reported by Earlopain (Earlopain _). ---------------------------------------- Feature #20971: Deprecate `rb_path_check` https://bugs.ruby-lang.org/issues/20971 * Author: Earlopain (Earlopain _) * Status: Open ---------------------------------------- With #16131, various code around $SAFE, taint, etc. has been deprecated and removed. GH PR https://github.com/ruby/ruby/pull/2476. Now, [`rb_path_check`] still exists as part of the public API, with Ruby itself never using or testing it. I believe it should have been deprecated and was simply missed. Should it be deprecated today or is that not worth the effort? Docs for it are pretty vague: https://github.com/ruby/ruby/blob/33f95d632dce42fac35da29eaed33f0a5a4f0dcb/… > This function is mysterious. What it does is not immediately obvious. Also what it does seems platform dependent. [`rb_path_check`]: https://github.com/ruby/ruby/blob/33f95d632dce42fac35da29eaed33f0a5a4f0dcb/… -- https://bugs.ruby-lang.org/

5 12

[ruby-core:120409] [Ruby master Feature#20982] Inconsistency between Hash#inspect and ENV.inspect in Ruby 3.4
by herwin (Herwin W) 14 Feb '25

14 Feb '25

Issue #20982 has been reported by herwin (Herwin W). ---------------------------------------- Feature #20982: Inconsistency between Hash#inspect and ENV.inspect in Ruby 3.4 https://bugs.ruby-lang.org/issues/20982 * Author: herwin (Herwin W) * Status: Open ---------------------------------------- Ruby 3.4 changed the stringified output of Hash to add whitespace to the hashrockets ``` ruby -e 'p({"a"=>"b"})' {"a" => "b"} ``` The output of `ENV.inspect` is very similar to `Hash#inspect`, but does not include the whitespace ``` ruby -e 'p ENV' {"SHELL"=>"/bin/bash", [...] } ``` Adding the extra whitespace around the hashrockets would improve the readability, and make things more consistent. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:120458] [Ruby master Misc#20995] exception escapes block given to IO.popen("-") in child process
by martin.dorey＠hds.com (Martin Dorey) 14 Feb '25

14 Feb '25

Issue #20995 has been reported by martin.dorey(a)hds.com (Martin Dorey). ---------------------------------------- Misc #20995: exception escapes block given to IO.popen("-") in child process https://bugs.ruby-lang.org/issues/20995 * Author: martin.dorey(a)hds.com (Martin Dorey) * Status: Open ---------------------------------------- I was surprised by the "ensure" being reached in the child process here: ``` ruby martind@stormy:~/tmp/D161730$ cat repro.rb #!/usr/bin/ruby -w parent = Process.pid() [false, true].each() { |nauseous| $stderr.puts("#{nauseous ? "" : "not "}raising exception from child:") begin IO.popen("-") { |io| unless io if nauseous raise("childish fit") end end } ensure $stderr.puts("in finalization block from #{Process.pid() == parent ? "parent" : "child"}") $stderr.puts() end } martind@stormy:~/tmp/D161730$ ~/download/ruby-3.3.4/ruby --version ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux] martind@stormy:~/tmp/D161730$ ~/download/ruby-3.3.4/ruby -w repro.rb not raising exception from child: in finalization block from parent raising exception from child: in finalization block from child repro.rb:11:in `block (2 levels) in <main>': childish fit (RuntimeError) from repro.rb:7:in `popen' from repro.rb:7:in `block in <main>' from repro.rb:3:in `each' from repro.rb:3:in `<main>' in finalization block from parent martind@stormy:~/tmp/D161730$ ``` In the first iteration of the loop, we don't see the surprise - the child process exits when the block is completed. Only when an exception is thrown, in the second iteration, does the control flow escape from the block. It does so even for the SystemExit exception raised by exit(0) but not, as we see above, from just leaving the block (in which case perhaps we _exit(0) at https://github.com/ruby/ruby/blob/master/io.c#L8044) My expectation was that the block would be executed in the child process much like the "main" part of a program, with the usual unhandled exception reporting, which we see demonstrated above, being invoked as soon as the exception propagated out the block, rather than first unwinding the callers. I think the behavior is unchanged since the oldest version I was conveniently able to test, which was: ruby 1.8.7 (2012-02-08 patchlevel 358) [x86_64-linux] ... so I didn't file this report as a Bug in case users have (accidentally?) come to depend on the behavior. I didn't find any mention of this at eg https://ruby-doc.org/3.4.1/IO.html#method-c-popen but I didn't file this report as a Feature request for the documentation in case the documentation deliberately leaves open such possibilities. I didn't even find anyone else puzzling over this behavior on eg StackOverflow, but I felt that I should report it for the benefit of the next poor sap to run into it, especially in case that's Future Me. Could it be a case where a warning would be worth more than the trouble it causes? -- https://bugs.ruby-lang.org/

4 6

[ruby-core:120443] [Ruby master Bug#20992] `eval(ascii_encoded_code)` raises EncodingError when multibyte local variable exists
by tompng (tomoya ishida) 14 Feb '25

14 Feb '25

Issue #20992 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20992: `eval(ascii_encoded_code)` raises EncodingError when multibyte local variable exists https://bugs.ruby-lang.org/issues/20992 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.5.0dev (2024-12-28T09:40:37Z master e4ec2128ae) +YJIT +MN +PRISM [arm64-darwin22] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ~~~ruby #coding: utf-8 α=1 eval '1+2'.encode('ascii') ~~~ ~~~ $ ruby file.rb file.rb:3:in 'Kernel#eval': invalid symbol in encoding US-ASCII :"\xCE\xB1" (EncodingError) from file.rb:3:in '<main>' ~~~ Running the file below with `LANG=C ruby file.rb` will make IRB unresponsive ~~~ruby #coding: utf-8 α=1 binding.irb ~~~ ~~~ $ LANG=C ruby file.rb From: file.rb @ line 3 : 1: #coding: utf-8 2: α=1 => 3: binding.irb irb(main):001> 1 <internal:kernel>:168:in 'Kernel#loop': invalid symbol in encoding US-ASCII :"\xCE\xB1" (EncodingError) from <internal:prelude>:5:in 'Binding#irb' from file.rb:3:in '<main>' irb(main):002> ~~~ -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120432] [Ruby master Bug#20989] Segmentation fault in Ripper when lexing `/#{"\xcd"}/`
by Earlopain (Earlopain _) 14 Feb '25

14 Feb '25

Issue #20989 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #20989: Segmentation fault in Ripper when lexing `/#{"\xcd"}/` https://bugs.ruby-lang.org/issues/20989 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When I paste this code snippet into irb, I get a segfault: `/#{"\xcd"}/`. Current master (https://github.com/ruby/ruby/commit/adbbc9109ee71848204b5168a7c1bf604849e5fa) also fails. Here is a simple reproduction, I attached the full bug as an attachment: ```rb require "ripper" lexer = Ripper::Lexer.new('/#{"\xcd"}/', '-', 0) lexer.scan.each # => /home/earlopain/.rbenv/versions/3.4.1/lib/ruby/3.4.0/ripper/lexer.rb:177: [BUG] Segmentation fault at 0x0000000000000008 # => ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] ``` ---Files-------------------------------- bug.txt (27.2 KB) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120404] [Ruby master Bug#20981] rb_undefine_finalizer is missing
by KitaitiMakoto 14 Feb '25

14 Feb '25

Issue #20981 has been reported by KitaitiMakoto (真北市). ---------------------------------------- Bug #20981: rb_undefine_finalizer is missing https://bugs.ruby-lang.org/issues/20981 * Author: KitaitiMakoto (真北市) * Status: Open * ruby -v: 3.4.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Merry Christmas! I encountered an error like "dyld[89037]: missing symbol called" in an extension which uses`rb_undefine_finalizer` in Ruby 3.4.1. It works fine in Ruby 3.3.6. The function defined in [ruby/include/ruby/internal/gc.h](https://github.com/ruby/ruby/blob/v3_4_1/i… but seems removed from [ruby/gc.c](https://github.com/ruby/ruby/blob/v3_4_1/gc.c). Could you consider restore the implementation or remove the function from `gc.h`? Reproducible code: ### extconf.rb ### ```ruby require "mkmf" create_makefile "undefine_finalizer_bug" ``` ### undefine_finalizer_bug.c ### ```c #include<ruby.h> static VALUE s_undefine_finalizer(VALUE self) { rb_undefine_finalizer(self); return Qnil; } void Init_undefine_finalizer_bug(void) { VALUE klass = rb_define_class("UndefineFinalizerBug", rb_cObject); rb_define_singleton_method(klass, "undefine_finalizer", s_undefine_finalizer, 0); } ``` ### undefine-finalizer-bug.rb ### ```ruby require "undefine_finalizer_bug.so" finalizer = proc { puts "Finalizer called" } ObjectSpace.define_finalizer(UndefineFinalizerBug, finalizer) UndefineFinalizerBug.new UndefineFinalizerBug.undefine_finalizer GC.start ``` ### Running ### #### Ruby 3.4.1 ## ``` % ruby ./extconf.rb && make && ruby -v -I. ./undefine-finalizer-bug.rb creating Makefile linking shared-object undefine_finalizer_bug.bundle ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] dyld[2436]: missing symbol called [1] 2436 abort ruby -v -I. ./undefine-finalizer-bug.rb ``` #### Ruby 3.3.6 #### ``` % chruby-exec 3.3.6 -- ruby ./extconf.rb && make && chruby-exec 3.3.6 -- ruby -v -I. ./undefine-finalizer-bug.rb creating Makefile linking shared-object undefine_finalizer_bug.bundle ruby 3.3.6 (2024-11-05 revision 75015d4c1f) [arm64-darwin24] ``` Thank you. -- https://bugs.ruby-lang.org/

3 4