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

[ruby-core:117572] [Ruby master Misc#20435] DevMeeting-2024-06-13
by mame (Yusuke Endoh) 04 Jun '24

04 Jun '24

Issue #20435 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #20435: DevMeeting-2024-06-13 https://bugs.ruby-lang.org/issues/20435 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2024/06/13 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2024/06/10. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

10 11

[ruby-core:117288] [Ruby master Misc#20387] Meta-ticket for ASAN support
by kjtsanaktsidis (KJ Tsanaktsidis) 02 Jun '24

02 Jun '24

Issue #20387 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Misc #20387: Meta-ticket for ASAN support https://bugs.ruby-lang.org/issues/20387 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Assignee: kjtsanaktsidis (KJ Tsanaktsidis) ---------------------------------------- I was asked to provide a bit of information about the current status of ASAN in CRuby, so I thought I'd open this meta-ticket to track all of the work I've been performing on fixing up address sanitizer support. So far, I have fixed the following issues related to ASAN support: * https://bugs.ruby-lang.org/issues/20001 + https://github.com/ruby/ruby/pull/9505, which dealt with two main themes: - Pushing the logic for capturing the start of the machine stack much closer to the top of the call stack, so that VALUEs stored close to the top of the machine stack get marked properly - Marking VALUEs stored on ASAN fake stacks during machine stack marking * https://bugs.ruby-lang.org/issues/20220 + https://github.com/ruby/ruby/pull/9734, which made M:N threading notify ASAN about stack switches in the same way that fibers do - Note: ASAN still doesn't work with M:N threading, but that actually has nothing to do with ASAN; it's because the most recent versions of Clang which are needed for ASAN just don't work with M:N threading either. See https://bugs.ruby-lang.org/issues/20243 for more info about that. * https://bugs.ruby-lang.org/issues/20273 + https://github.com/ruby/ruby/pull/10012, which disables `callcc` (and the associated tests) when ASAN is enabled - callcc is very rarely used in real code and the way it works is just fundamentally incompatible with ASAN (it performs longjmp's which I think are technically undefined behaviour) * https://bugs.ruby-lang.org/issues/20221 + https://github.com/ruby/ruby/pull/9865, which ignore some global symbols that ASAN defines from the global symbol leak checker * https://bugs.ruby-lang.org/issues/20274 + https://github.com/ruby/ruby/pull/10087, which ignores some false positive tests about memory leaks when ASAN is enabl * I updated the ASAN docs in https://github.com/ruby/ruby/pull/9922 to more closely reflect current reality The current state of things is that, by following the instructions in https://github.com/ruby/ruby/blob/master/doc/contributing/building_ruby.md, you can successfully build Ruby with ASAN enabled, however, the test suite has several failures. I'm currently working on addressing these: The next step is to merge https://github.com/ruby/ruby/pull/10122 (https://bugs.ruby-lang.org/issues/20310) which I plan to do next week (I'm currently away on a work trip). That makes sure that VALUEs stored in ASAN fake stacks from threads other than the currently running thread get marked during GC. After that, I need to push up patches for the remaining few issues. I mostly have these patches ready to go already; in fact, last week I got the full `make check` suite passing all tests with ASAN enabled! Once that's working, I'd like to investigate how ASAN can fit into CRuby's CI matrix somewhere so that it _stays_ working, although I have not thought too deeply about this yet. I will provide further updates on this ticket so anybody interested can stay in the loop. -- https://bugs.ruby-lang.org/

2 9

[ruby-core:117727] [Ruby master Bug#20459] Ractor.select() deadlock?
by esad (Esad Hajdarevic) 01 Jun '24

01 Jun '24

Issue #20459 has been reported by esad (Esad Hajdarevic). ---------------------------------------- Bug #20459: Ractor.select() deadlock? https://bugs.ruby-lang.org/issues/20459 * Author: esad (Esad Hajdarevic) * Status: Open * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin20] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When I run this script ``` echo = Ractor.new { Ractor.receive } Thread.new { puts Ractor.select(echo).inspect } sleep 0.1 echo.send "test" ``` the script never terminates. If I change thread body to ``` Thread.new { puts echo.take.inspect } ``` or introduce a small delay before #select like: ``` Thread.new { sleep 1; puts Ractor.select(echo).inspect } ``` then it works/terminates. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:117674] [Ruby master Bug#20450] Ruby 3.1.1 broken with bootsnap
by philippe.bs.noel＠tutanota.com (Philippe Noel) 31 May '24

31 May '24

Issue #20450 has been reported by philippe.bs.noel(a)tutanota.com (Philippe Noel). ---------------------------------------- Bug #20450: Ruby 3.1.1 broken with bootsnap https://bugs.ruby-lang.org/issues/20450 * Author: philippe.bs.noel(a)tutanota.com (Philippe Noel) * Status: Open * ruby -v: ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The issue looks like https://bugs.ruby-lang.org/issues/20060 With the new release of ruby 3.1.1, bootsnap does not work anymore. ``` bin/rails aborted! ArgumentError: comparison of String with nil failed (ArgumentError) msg = " #{RUBY_VERSION < SINCE[gem] ? "will no longer be" : "is not"} part of the default gems since Ruby #{SINCE[gem]}." ^^^^^^^^^^ /usr/local/bundle/gems/bootsnap-1.18.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require' ``` It's working with DISABLE_BOOTSNAP=1 with the following message : `warning: parser/current is loading parser/ruby33, which recognizes 3.3.0-compliant syntax, but you are running 3.3.1.` -- https://bugs.ruby-lang.org/

7 10

[ruby-core:117660] [Ruby master Bug#20449] Ripper issue in field production on Ruby 3.1.5
by kddnewton (Kevin Newton) 30 May '24

30 May '24

Issue #20449 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20449: Ripper issue in field production on Ruby 3.1.5 https://bugs.ruby-lang.org/issues/20449 * Author: kddnewton (Kevin Newton) * Status: Open * ruby -v: 3.1.5 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby Ripper.sexp("foo::bar = baz") # => [:program, [[:assign, [:field, [:vcall, [:@ident, "foo", [1, 0]]], 73, [:@ident, "bar", [1, 5]]], [:vcall, [:@ident, "baz", [1, 11]]]]]] ``` Note that 73 there. That's either `:"::"` or `[:@op, "::", [lineno, column]]` in every other version of Ruby that I could find. I assume this is a backport issue. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:115923] [Ruby master Bug#20094] Inline while loop behavior changed unexpectedly in 3.3.0
by sisyphus_cg (Sisyphus CG) 30 May '24

30 May '24

Issue #20094 has been reported by sisyphus_cg (Sisyphus CG). ---------------------------------------- Bug #20094: Inline while loop behavior changed unexpectedly in 3.3.0 https://bugs.ruby-lang.org/issues/20094 * Author: sisyphus_cg (Sisyphus CG) * Status: Open * Priority: Normal * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The behavior of the inline while loop has changed in 3.3.0. This unexpectedly broke my code and I couldn't find anything in the changelog about it so reporting it as a bug. In ruby <= 3.2: ``` ruby (p 1) while false # nothing (p 1; p 2) while false # nothing ``` In ruby 3.3: ``` ruby (p 1) while false # 1 (p 1; p 2) while false # 1 2 ``` Essentially, if the left hand side looks like a statement, now it is treated as a do-while loop. In ruby 3.2 and less this only happened with explicit use of `begin` and `end`. -- https://bugs.ruby-lang.org/

9 11

[ruby-core:117652] [Ruby master Bug#20445] Backport 2571d5376a38c333b8fe85f1f9b2f9c2422c0ad9 to ruby_3_3
by mame (Yusuke Endoh) 29 May '24

29 May '24

Issue #20445 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #20445: Backport 2571d5376a38c333b8fe85f1f9b2f9c2422c0ad9 to ruby_3_3 https://bugs.ruby-lang.org/issues/20445 * Author: mame (Yusuke Endoh) * Status: Closed * ruby -v: ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: REQUIRED ---------------------------------------- Building Ruby 3.3.1 prints the following warning: ``` regexec.c: In function 'match_at': regexec.c:2598:59: warning: 'stkp' may be used uninitialized [-Wmaybe-uninitialized] 2598 | if (*pbegin == OP_REPEAT_INC) stkp->u.repeat.count--;\ | ~~~~~~~~~~~~~~~~~~~~^~ regexec.c:3852:11: note: in expansion of macro 'CHECK_MATCH_CACHE' 3852 | CHECK_MATCH_CACHE; | ^~~~~~~~~~~~~~~~~ regexec.c:2297:18: note: 'stkp' was declared here 2297 | OnigStackType *stkp; /* used as any purpose. */ | ^~~~ ``` 2571d5376a38c333b8fe85f1f9b2f9c2422c0ad9 will remove it. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:117510] [Ruby master Bug#20427] Heap buffer overflow in `Array#sort!` when block modifies target array
by zack.ref＠gmail.com (Zack Deveau) 29 May '24

29 May '24

Issue #20427 has been reported by zack.ref(a)gmail.com (Zack Deveau). ---------------------------------------- Bug #20427: Heap buffer overflow in `Array#sort!` when block modifies target array https://bugs.ruby-lang.org/issues/20427 * Author: zack.ref(a)gmail.com (Zack Deveau) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- **(note: It was decided we should handle this in the public issue tracker in security ticket #2327648)** The attached patch [has been applied to `master`](https://github.com/ruby/ruby/pull/10522) and should apply to latest `3.3.0` for backport. Could not reproduce on the following builds: - ruby 3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-linux] - ruby 3.1.4p249 (2024-01-11 revision 2b608349bb) [x86_64-linux] --- In cases where `rb_ary_sort_bang` is called with a block and `tmp` is an embedded array, we need to account for the block potentially impacting the capacity of `ary`. Reproduction script for x86 targets: ```ruby var_0 = (1..70).to_a var_0.sort! do |var_0_block_129, var_1_block_129| var_0.pop var_1_block_129 <=> var_0_block_129 end.shift(3) ``` Reproduction script for ARM targets: ```ruby 10.times do var_0 = (1..70).to_a var_0.sort! do |var_0_block_129, var_1_block_129| var_0.pop var_1_block_129 <=> var_0_block_129 end.shift(3) end ``` The above example can put the array into a corrupted state (`ary` after block has `len=0` and `capa=14`) : ``` ================== ary =================== ary: BD99908 is_embedded?: 0 is_shared?: 0 heap.len: 0 heap.capa: 14 heap.shared_root: 14 ================== tmp =================== ary: BD1EB18 is_embedded?: 1 is_shared?: 0 embed_len: 70 embed_capa: 78 heap.len: 141 heap.capa: 139 heap.shared_root: 139 ``` This results in a heap buffer overflow and possible segfault: ``` ==19964==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60b0000034f0 at pc 0x00010c35ee6c bp 0x0003070fb290 sp 0x0003070faa50 WRITE of size 560 at 0x60b0000034f0 thread T0 #0 0x10c35ee6b in wrap_memcpy+0x2ab (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x18e6b) #1 0x100e0b085 in ruby_nonempty_memcpy memory.h:671 #2 0x100e0e43e in ary_memcpy0 array.c:335 #3 0x100e0cb00 in ary_memcpy array.c:352 #4 0x100e1426c in rb_ary_sort_bang array.c:3519 [ ... ] ``` Was able to reproduce on the following builds: - ruby 3.4.0dev (2024-01-17T14:48:46Z ef4a08eb65) [x86_64-linux] - ruby 3.3.0 (2024-01-05 revision 634d4e29ef) [x86_64-darwin23] - ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] This patch adds a conditional to determine when the capacity of `ary` has been modified by the provided block. If this is the case, ensure that the capacity of `ary` is adjusted to handle at minimum the len of `tmp`. `test-all` passes locally: ``` Finished tests in 70.194526s, 369.6727 tests/s, 89373.2939 assertions/s. 25949 tests, 6273516 assertions, 0 failures, 0 errors, 292 skips ``` ---Files-------------------------------- rb_ary_sort_bang_heap_overflow.patch (2.06 KB) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:116901] [Ruby master Bug#20289] Bug in Zlib::GzipReader#eof? breaks reading certain sizes of gzipped files.
by martinemde (Martin Emde) 29 May '24

29 May '24

Issue #20289 has been reported by martinemde (Martin Emde). ---------------------------------------- Bug #20289: Bug in Zlib::GzipReader#eof? breaks reading certain sizes of gzipped files. https://bugs.ruby-lang.org/issues/20289 * Author: martinemde (Martin Emde) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hello, A bug in the implementation of Zlib::GzipReader#eof? makes it very difficult to read certain rubygems using readpartial without receiving an EOFError. The bug is caused when the chunk size read from the gzip leaves only empty gzip "overhead" bytes at the end of the unread portion. The result is that a simple `readpartial until eof?` fails on some real world gems. ### Bug Explanation Imagine a gzip file, it has compressed data and some bytes that indicate the start and end of a chunk and then end of a file. ``` gzip file = "[... 2048 chunk of gzip data ...][ \0 bytes, chucksum info, with no new readable bytes ]" ``` When reading this file, zlib.c will pull a chunk of data according to READ_SIZE and return that data uncompressed. With exactly the right size of data (within exactly the range of READ-SIZE*n - 24 to READ_SIZE*n - 15 for any multiple of READ_SIZE) all of the file data is read and returned on the first read. The bug happens when there are bytes remaining on the gzip file that haven't been read, but contain no new data that can be returned to the buffer. Before reading the final empty chunk, #eof? returns false. After reading the final chunk, EOFError is raised because no bytes were returned into the buffer. What should happen is similar to how a Socket eof? is checked. On a socket, #eof? is not "passive" but actively reads ahead, filling the buffer. If that read-ahead fails to find new data, then the EOF is reached and eof? returns true. In zlib, #eof? does not read ahead to check if the end has been reached, causing this bug. ### Solution Samuel Giddins and I have both submitted alternate, but very similar solutions for this bug. [Samuel's PR](https://github.com/ruby/zlib/pull/73) and [My PR](https://github.com/ruby/zlib/pull/72). We'd leave it to ruby core to decide which is the best solution. Unfortunately, these bug fix PRs have been waiting for more than 2 months now with no movement on fixing this bug. The [original issue](https://github.com/ruby/zlib/issues/56) that I opened to point out this bug was submitted Aug 16, 2023. We've been working to find a solution for this bug for more than half a year. This bug was discovered because rubygems wanted to improve the efficiency of reading a gem by using readpartial to conserve memory. Sam submitted an additional PR that vastly improves the performance of the zlib gem by managing buffers better. We've already proven that this dramatically decreases memory usage when parsing gems. The [performance PR by Samuel](https://github.com/ruby/zlib/pull/61) has been open since September 13th, 2023. ### Plea We've been trying for months to get this solved. Opening a ruby-lang bug is my next attempt after communicating through our contacts at Ruby core has gone nowhere. Please merge and release these fixes, or tell us what is wrong with them so we can fix them so they can be merged. It will improve rubygems for everyone. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:117047] [Ruby master Bug#20324] `(1..).overlap?('foo'..)` returns true
by kyanagi (Kouhei Yanagita) 29 May '24

29 May '24

Issue #20324 has been reported by kyanagi (Kouhei Yanagita). ---------------------------------------- Bug #20324: `(1..).overlap?('foo'..)` returns true https://bugs.ruby-lang.org/issues/20324 * Author: kyanagi (Kouhei Yanagita) * Status: Open * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- While thinking about finding the intersection of two ranges, I found that `(1..).overlap?('foo'..)` returns true. In the current implementation, it seems that `(a..).overlap?(b..)` or `(..a).overlap?(..b)` returns true regardless of what `a` or `b` are. However, I think it should return true if and only if `a` and `b` are comparable. (What is the intersection of `1..` and `'foo'..`?) -- https://bugs.ruby-lang.org/

2 1