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

[ruby-core:116129] [Ruby master Bug#20172] Socket.addrinfo failing randomly
by mwaldvogel (Michael Waldvogel) 04 Feb '24

04 Feb '24

Issue #20172 has been reported by mwaldvogel (Michael Waldvogel). ---------------------------------------- Bug #20172: Socket.addrinfo failing randomly https://bugs.ruby-lang.org/issues/20172 * Author: mwaldvogel (Michael Waldvogel) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I've recently updated one of my linux systems (Gentoo) to glibc 2.38 (that was the only change). After the update most of the time the below error happens. Among other things this breaks rubygems for me. I've reinstalled ruby 3.2.2 with rvm and didn't encounter the issue. The issue however remained even after reinstalling ruby 3.3.0 and even with ruby master. Since this goes back to getaddrinfo (which is working without any issues outside of ruby) and there seems to be only one bigger change to stdlib socket, I'm assuming the problem was introduced with https://bugs.ruby-lang.org/issues/19965 ``` 3.3.0 :001 > require 'socket' => true 3.3.0 :002 > Socket.getaddrinfo('rubygems.org', 443) (irb):2:in `getaddrinfo': getaddrinfo: Temporary failure in name resolution (Socket::ResolutionError) from (irb):2:in `<main>' from <internal:kernel>:187:in `loop' from /usr/local/rvm/rubies/ruby-3.3.0/lib/ruby/gems/3.3.0/gems/irb-1.11.0/exe/irb:9:in `<top (required)>' from /usr/local/rvm/rubies/ruby-3.3.0/bin/irb:25:in `load' from /usr/local/rvm/rubies/ruby-3.3.0/bin/irb:25:in `<main>' 3.3.0 :003 > Socket.getaddrinfo('rubygems.org', 443) (irb):3:in `getaddrinfo': getaddrinfo: Temporary failure in name resolution (Socket::ResolutionError) from (irb):3:in `<main>' from <internal:kernel>:187:in `loop' from /usr/local/rvm/rubies/ruby-3.3.0/lib/ruby/gems/3.3.0/gems/irb-1.11.0/exe/irb:9:in `<top (required)>' from /usr/local/rvm/rubies/ruby-3.3.0/bin/irb:25:in `load' from /usr/local/rvm/rubies/ruby-3.3.0/bin/irb:25:in `<main>' 3.3.0 :004 > Socket.getaddrinfo('rubygems.org', 443) => [["AF_INET", 443, "151.101.193.227", "151.101.193.227", 2, 1, 6], ["AF_INET", 443, "151.101.193.227", "151.101.193.227", 2, 2, 17], ["AF_INET", 443, "151.101.193.227", "151.101.193.227", 2, 3, 0], ... ["AF_INET6", 443, "2a04:4e42::483", "2a04:4e42::483", 10, 1, 6], ["AF_INET6", 443, "2a04:4e42::483", "2a04:4e42::483", 10, 2, 17], ["AF_INET6", 443, "2a04:4e42::483", "2a04:4e42::483", 10, 3, 0]] 3.3.0 :005 > ``` -- https://bugs.ruby-lang.org/

4 8

[ruby-core:116223] [Ruby master Bug#20188] `Module#const_source_location` returns wrong information when real constant was defined but autoload is still ongoing
by byroot (Jean Boussier) 01 Feb '24

01 Feb '24

Issue #20188 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #20188: `Module#const_source_location` returns wrong information when real constant was defined but autoload is still ongoing https://bugs.ruby-lang.org/issues/20188 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Ref: https://github.com/fxn/zeitwerk/issues/281 `const_source_location` keeps returning the location of the `autoload` call, even after the real constant was defined. It only starts returning the real constant location once the autoload was fully completed. ```ruby # /tmp/autoload.rb File.write("/tmp/const.rb", <<~RUBY) module Const LOCATION = Object.const_source_location(:Const) end RUBY autoload :Const, "/tmp/const" p Const::LOCATION ``` Expected Output: ```ruby ["/tmp/const.rb", 1] ``` Actual Output: ```ruby ["/tmp/autoload.rb", 8] ``` Potential patch: https://github.com/ruby/ruby/pull/9549 -- https://bugs.ruby-lang.org/

3 31

[ruby-core:116103] [Ruby master Bug#20166] Backport 149373c to Ruby 3.3
by hsbt (Hiroshi SHIBATA) 01 Feb '24

01 Feb '24

Issue #20166 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #20166: Backport 149373c to Ruby 3.3 https://bugs.ruby-lang.org/issues/20166 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Priority: Normal * Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- https://github.com/ruby/ruby/pull/9457 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:116045] [Ruby master Bug#20157] Regression in GC.measure_total_time
by rianmcguire (Rian McGuire) 01 Feb '24

01 Feb '24

Issue #20157 has been reported by rianmcguire (Rian McGuire). ---------------------------------------- Bug #20157: Regression in GC.measure_total_time https://bugs.ruby-lang.org/issues/20157 * Author: rianmcguire (Rian McGuire) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Setting `GC.measure_total_time = false` is no longer disabling GC time measurement in Ruby 3.3.0. Reproduction script: ``` ruby puts RUBY_DESCRIPTION GC.measure_total_time = false puts "measure_total_time is now false" puts "GC.stat(:time) = #{GC.stat(:time)}" puts "There should be no further clock_gettime syscalls" # Generate some garbage Random.new.bytes(100 * 1024 * 1024) GC.start puts "GC.stat(:time) = #{GC.stat(:time)}. This should be unchanged from above" ``` Ruby 3.2.2 (expected behaviour): ``` $ strace --trace=clock_gettime --signal=none ruby --disable-gems bug.rb clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=45735959}) = 0 ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] measure_total_time is now false GC.stat(:time) = 0 There should be no further clock_gettime syscalls GC.stat(:time) = 0. This should be unchanged from above +++ exited with 0 +++ ``` Ruby 3.3.0: ``` $ strace --trace=clock_gettime --signal=none ruby --disable-gems bug.rb clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=31784505}) = 0 ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] measure_total_time is now false GC.stat(:time) = 0 There should be no further clock_gettime syscalls clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=47132055}) = 0 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=47576566}) = 0 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=47586656}) = 0 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=47852906}) = 0 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=180726043}) = 0 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=181242023}) = 0 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=181248873}) = 0 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=191276005}) = 0 GC.stat(:time) = 11. This should be unchanged from above +++ exited with 0 +++ ``` It appears that this was caused by commit https://github.com/ruby/ruby/commit/93ac7405b80cc61930d73da04441fa09af1851e1 -- the test for `MEASURE_GC` inside in `gc_enter_event_measure_p` was lost in the refactoring. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:116015] [Ruby master Bug#20149] Fix memory leak in IPSocket rb_getaddrinfo
by HParker (Adam Hess) 01 Feb '24

01 Feb '24

Issue #20149 has been reported by HParker (Adam Hess). ---------------------------------------- Bug #20149: Fix memory leak in IPSocket rb_getaddrinfo https://bugs.ruby-lang.org/issues/20149 * Author: HParker (Adam Hess) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- PR: https://github.com/ruby/ruby/pull/9413 Fixes a memory leak pthread_attr is created, but never cleaned up ``` require 'socket' 10.times do 10_000.times do IPSocket.getaddress("localhost") end puts `ps -o rss= -p #{$$}` end ``` before: ``` 26744 33400 39928 46328 53240 59640 66168 72696 79352 85880 ``` after: ``` 20864 20864 20864 20864 20864 20992 20992 20992 20992 21120 ``` This likely needs a backport to Ruby 3.3 series. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:116493] [Ruby master Bug#20226] Inconsistent Sort results on 3.3.0 compared to previous versions
by omerby (Omer Ben Yosef) 01 Feb '24

01 Feb '24

Issue #20226 has been reported by omerby (Omer Ben Yosef). ---------------------------------------- Bug #20226: Inconsistent Sort results on 3.3.0 compared to previous versions https://bugs.ruby-lang.org/issues/20226 * Author: omerby (Omer Ben Yosef) * Status: Open * Priority: Normal * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Try this code block: ``` [-0.9, -0.88, -0.85, -0.83, -0.81, -0.79, -0.77, -0.75, -0.73, -0.71, -0.69, -0.67, -0.65, -0.63, -0.6, -0.58, -0.56, -0.54, -0.52, -0.5, -0.48, -0.46, -0.44, -0.42, -0.4, -0.38, -0.35, -0.33, -0.31, -0.29, -0.27, -0.25, -0.23, -0.21, -0.19, -0.17, -0.15, -0.13, -0.1, -0.08, -0.06, -0.04, -0.02, 0.0, 0.02, 0.0, 0.02].sort_by(&:abs) ``` The end result should be the numbers absolute sorted, look at the last 5 numbers of this, the end result of them should be `[0.0, 0.0, -0.02, 0.02, 0.02...]` maintaining the original order, and this behavior is what we see on ruby 3.2.0, however on ruby 3.3.0 the end result will be `[0.0, 0.0, 0.02, 0.02, -0.02...]` This is also inconsistent, as `[-0.02, 0.0, 0.02, 0.0, 0.02].sort_by(&:abs)` will actually provide the expected result. Again, the main issue for us is the difference between 3.3.0 and previous versions of ruby. -- https://bugs.ruby-lang.org/

7 13

[ruby-core:115978] [Ruby master Bug#20104] Regexp#match returns nil but allocates T_MATCH objects
by jeremyevans0 (Jeremy Evans) 01 Feb '24

01 Feb '24

Issue #20104 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #20104: Regexp#match returns nil but allocates T_MATCH objects https://bugs.ruby-lang.org/issues/20104 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * ruby -v: ruby 3.4.0dev (2023-12-30T03:14:38Z master 8e32c01742) [x86_64-openbsd7.4] * Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- Between Ruby 3.2 and 3.3, behavior changed so that Regexp#match will allocate a T_MATCH object even when there is no match. Example code: ```ruby h = {} GC.start GC.disable ObjectSpace.count_objects(h) matches = h[:T_MATCH] || 0 md = /\A[A-Z]+\Z/.match('1') ObjectSpace.count_objects(h) new_matches = h[:T_MATCH] || 0 puts "/\\A[A-Z]+\\Z/.match('1') => #{md.inspect} generates #{new_matches - matches} T_MATCH objects" ``` Result with Ruby 1.9-3.2: ``` /\A[A-Z]+\Z/.match('1') => nil generates 0 T_MATCH objects ``` Results with Ruby 3.3.0 and current master branch: ``` /\A[A-Z]+\Z/.match('1') => nil generates 1 T_MATCH objects ``` This results in a measurable performance decrease for both Sinatra and Roda web applications, as reported at: https://old.reddit.com/r/ruby/comments/18sxtv9/ruby_330_performance_ups_and… Thanks to GitHub users kiskoza and tagliala for producing a minimal example showing this issue: https://github.com/caxlsx/caxlsx/issues/336 -- https://bugs.ruby-lang.org/

3 4