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

[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