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

[ruby-core:112947] [Ruby master Bug#19542] Operations on zero-sized IO::Buffer are raising
by hanazuki (Kasumi Hanazuki) 05 Feb '24

05 Feb '24

Issue #19542 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #19542: Operations on zero-sized IO::Buffer are raising https://bugs.ruby-lang.org/issues/19542 * Author: hanazuki (Kasumi Hanazuki) * 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 ---------------------------------------- I found that IO::Buffer of zero length is not cloneable. ``` % ruby -v ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] % ruby -e 'p IO::Buffer.for("").dup' -e:1:in `initialize_copy': The buffer is not allocated! (IO::Buffer::AllocationError) from -e:1:in `initialize_dup' from -e:1:in `dup' from -e:1:in `<main>' % ruby -e 'p IO::Buffer.new(0).dup' -e:1: warning: IO::Buffer is experimental and both the Ruby and C interface may change in the future! -e:1:in `initialize_copy': The buffer is not allocated! (IO::Buffer::AllocationError) from -e:1:in `initialize_dup' from -e:1:in `dup' from -e:1:in `<main>' ``` It seems `IO::Buffer.new(0)` allocates no memory for buffer on object creation and thus prohibits reading from or writing to it. So `#dup` method copying zero bytes into the new IO::Buffer raises the exception. Empty buffers, however, often appear in corner cases of usual operations (encrypting an empty string, encoding an empty list of items into binary, etc.) and it would be easy if such cases could be handled consistently. Other operations on NULL IO::Buffers are also useful but currently raising. ``` IO::Buffer.new(0) <=> IO::Buffer.new(1) IO::Buffer.new(0).each(:U8).to_a IO::Buffer.new(0).get_values([], 0) IO::Buffer.new(0).set_values([], 0, []) ``` I'm not sure this is a bug or by design, but at least I don't want cloning and comparison to raise. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:116178] [Ruby master Bug#20178] Out of bounds stack read on Array#first when built with -O0
by jhawthorn (John Hawthorn) 04 Feb '24

04 Feb '24

Issue #20178 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #20178: Out of bounds stack read on Array#first when built with -O0 https://bugs.ruby-lang.org/issues/20178 * Author: jhawthorn (John Hawthorn) * Status: Open * Priority: Normal * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: REQUIRED ---------------------------------------- https://github.com/ruby/ruby/pull/9499 Previously on builds with optimizations disabled, we could end up with an out of bounds read trying to access a non-existent local variable in the compiled `Primitive.cexpr!`. This occurred only when we had all of: * built with `-O0` * Leaf builtin * `Primitive.mandatory_only` * "no args builtin", called by [vm_call_single_noarg_inline_builtin](https://github.com/ruby/ruby/pull/7486) * The stack is escaped to the heap via binding or a proc This is because `mk_builtin_loader` generated reads for all locals regardless of whether they were used and in the case we generated a mandatory_only iseq that would include more variables than were actually available. On optimized builds, the invalid accesses would be optimized away, and this also was often unnoticed as the invalid access would just hit another part of the stack unless it had been escaped to the heap. However we should fix (and backport) this both because and so that we can use ASAN and debug builds. --- ``` ruby def foo binding [].first end foo foo ``` ``` ================================================================= ==1542964==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000045fc8 at pc 0x55cb2958b7d0 bp 0x7ffcdc9f1f00 sp 0x7ffcdc9f1ef0 READ of size 8 at 0x603000045fc8 thread T0 #0 0x55cb2958b7cf in rb_vm_lvar /home/jhawthorn/src/ruby/builtin.h:103 #1 0x55cb295ab586 in builtin_inline_class_104 /home/jhawthorn/src/ruby/array.rbinc:14 #2 0x55cb29b2243e in builtin_invoker0 /home/jhawthorn/src/ruby/vm_insnhelper.c:6724 #3 0x55cb29b09556 in vm_call_single_noarg_inline_builtin /home/jhawthorn/src/ruby/vm_insnhelper.c:2931 #4 0x55cb29b1d112 in vm_sendish /home/jhawthorn/src/ruby/vm_insnhelper.c:5581 #5 0x55cb29b34533 in vm_exec_core /home/jhawthorn/src/ruby/insns.def:834 #6 0x55cb29b6c9a3 in rb_vm_exec /home/jhawthorn/src/ruby/vm.c:2487 #7 0x55cb29b6f338 in rb_iseq_eval_main /home/jhawthorn/src/ruby/vm.c:2753 #8 0x55cb296f7188 in rb_ec_exec_node /home/jhawthorn/src/ruby/eval.c:287 #9 0x55cb296f74e4 in ruby_run_node /home/jhawthorn/src/ruby/eval.c:328 #10 0x55cb29587d51 in rb_main main.c:39 #11 0x55cb29587eb1 in main main.c:58 #12 0x7f3295558ccf (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658) #13 0x7f3295558d89 in __libc_start_main (/usr/lib/libc.so.6+0x27d89) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658) #14 0x55cb29587bb4 in _start (/home/jhawthorn/src/ruby/miniruby+0x1a7bb4) (BuildId: acaf2fc9526d3e1423a2fcbd072ee6aeb3e5c4c6) 0x603000045fc8 is located 8 bytes before 32-byte region [0x603000045fd0,0x603000045ff0) allocated by thread T0 here: #0 0x7f32958e1359 in __interceptor_malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x55cb2975348a in objspace_xmalloc0 /home/jhawthorn/src/ruby/gc.c:12625 #2 0x55cb29753940 in ruby_xmalloc2_body /home/jhawthorn/src/ruby/gc.c:12872 #3 0x55cb29759643 in ruby_xmalloc2 /home/jhawthorn/src/ruby/gc.c:14473 #4 0x55cb29b62b80 in vm_make_env_each /home/jhawthorn/src/ruby/vm.c:977 #5 0x55cb29b62dc0 in vm_make_env_object /home/jhawthorn/src/ruby/vm.c:1010 #6 0x55cb29b65271 in rb_vm_make_binding /home/jhawthorn/src/ruby/vm.c:1433 #7 0x55cb298cbdb5 in rb_binding_new /home/jhawthorn/src/ruby/proc.c:347 #8 0x55cb298cbdc8 in rb_f_binding /home/jhawthorn/src/ruby/proc.c:397 #9 0x55cb29b0ca60 in ractor_safe_call_cfunc_0 /home/jhawthorn/src/ruby/vm_insnhelper.c:3306 #10 0x55cb29b0eb89 in vm_call_cfunc_with_frame_ /home/jhawthorn/src/ruby/vm_insnhelper.c:3490 #11 0x55cb29b0f149 in vm_call_cfunc_with_frame /home/jhawthorn/src/ruby/vm_insnhelper.c:3518 #12 0x55cb29b1d112 in vm_sendish /home/jhawthorn/src/ruby/vm_insnhelper.c:5581 #13 0x55cb29b34533 in vm_exec_core /home/jhawthorn/src/ruby/insns.def:834 #14 0x55cb29b6c9a3 in rb_vm_exec /home/jhawthorn/src/ruby/vm.c:2487 #15 0x55cb29b6f338 in rb_iseq_eval_main /home/jhawthorn/src/ruby/vm.c:2753 #16 0x55cb296f7188 in rb_ec_exec_node /home/jhawthorn/src/ruby/eval.c:287 #17 0x55cb296f74e4 in ruby_run_node /home/jhawthorn/src/ruby/eval.c:328 #18 0x55cb29587d51 in rb_main main.c:39 #19 0x55cb29587eb1 in main main.c:58 #20 0x7f3295558ccf (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658) SUMMARY: AddressSanitizer: heap-buffer-overflow /home/jhawthorn/src/ruby/builtin.h:103 in rb_vm_lvar Shadow bytes around the buggy address: 0x603000045d00: fd fd fd fa fa fa fd fd fd fa fa fa 00 00 00 00 0x603000045d80: fa fa 00 00 04 fa fa fa fd fd fd fd fa fa 00 00 0x603000045e00: 00 00 fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 0x603000045e80: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 00 0x603000045f00: fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 =>0x603000045f80: 00 00 fa fa 00 00 00 00 fa[fa]00 00 00 00 fa fa 0x603000046000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x603000046080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x603000046100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x603000046180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x603000046200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==1542964==ABORTING ``` -- https://bugs.ruby-lang.org/

3 3

[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

[ruby-core:115338] [Ruby master Bug#19999] Backport: .travis.yml and fixed commits
by jaruga (Jun Aruga) 31 Jan '24

31 Jan '24

Issue #19999 has been reported by jaruga (Jun Aruga). ---------------------------------------- Bug #19999: Backport: .travis.yml and fixed commits https://bugs.ruby-lang.org/issues/19999 * Author: jaruga (Jun Aruga) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: REQUIRED ---------------------------------------- This is a backport suggestion to make Travis CI stable on the Ruby stable branches ruby_3_2 and etc. Travis CI for Ruby master branch became stable recently with arm64, ppc64le, s390x and arm32 cases. All the CI cases are running without `allow_failures` option. And more importantly, I simplified the `.travis.yml` to maintain it easily without sacrificing performance. So, I think it may be a good time to backport the Travis CI configuration file `.travis.yml` without some commits to fix some issues. https://app.travis-ci.com/github/ruby/ruby/builds/267166336 I can see ruby_3_2 and ruby_3_1 branches on the Travis CI page below. There are no ruby_3_0 and ruby_27 branches there. I am not sure how the branches are used. https://app.travis-ci.com/github/ruby/ruby/branches But it's beneficial to fix at least Travis CI for ruby_3_2 branch to save the Travis infra resource. Seeing the ruby_3_2 log, the ppc64le is already timeout after running maximum 50 minutes. https://app.travis-ci.com/github/ruby/ruby/builds/267156055 https://app.travis-ci.com/github/ruby/ruby/jobs/613043898#L2325 ``` [1/2] TestFiberQueue#test_pop_with_timeout_and_value = 0.00 s [2/2] TestFiberQueue#test_pop_with_timeout====[ 540 seconds still running ]==== ====[ 1080 seconds still running ]==== ====[ 1620 seconds still running ]==== ====[ 2160 seconds still running ]==== ``` First you can make the tests fail rather than stucking by the commit below. https://github.com/ruby/ruby/commit/3eaae72855b23158e2148566bb8a7667bfb395cb As this stucking issue happened with the combination of the `optflags=-O1` on ppc64le, I think you avoid the issue by porting the `.travis.yml` from the `master` branch where the `optflags=-O1` is not used in ppc64le. -- https://bugs.ruby-lang.org/

2 6