August 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:114323] [Ruby master Bug#19791] Debugger does not handle delete key correctly
by stuartb (Stuart Bury) 15 Aug '23

15 Aug '23

Issue #19791 has been reported by stuartb (Stuart Bury). ---------------------------------------- Bug #19791: Debugger does not handle delete key correctly https://bugs.ruby-lang.org/issues/19791 * Author: stuartb (Stuart Bury) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux-musl] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When entering the debugger using `binding.debugger` or the `rdbg` command, pressing the delete key on the keyboard to delete characters at the REPL merely prints "^[[3~" to the console, and does not actually delete anything. This is **very** inconvenient. Can this be fixed somehow? I really like the new debugger, but my swearing like a sailor every time I hit "delete" is starting to really annoy my wife... It is worth noting that if I run the `pry` command and then, within pry, call `binding.debugger`, the delete key operates correctly. I believe the issue is related in some way to readline support, or the lack thereof – but my Ruby installation was compiled with readline support. I've tried everything I can think of, and spent some time on Google trying to solve it, but the problem remains. It happens in Alpine 3.18 and also in Debian 12. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:114379] [Ruby master Bug#19836] Parser leaks memory for incomplete lambdas
by peterzhu2118 (Peter Zhu) 13 Aug '23

13 Aug '23

Issue #19836 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #19836: Parser leaks memory for incomplete lambdas https://bugs.ruby-lang.org/issues/19836 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- GitHub Pull Request: https://github.com/ruby/ruby/pull/8192 The parser does not free the chain of `struct vtable`, which causes memory leaks. The following script reproduces this issue: ```ruby 10.times do 100_000.times do Ripper.parse("-> {") end puts `ps -o rss= -p #{$$}` end ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:114377] [Ruby master Bug#19835] Parser leaks memory for incomplete tokens
by peterzhu2118 (Peter Zhu) 13 Aug '23

13 Aug '23

Issue #19835 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #19835: Parser leaks memory for incomplete tokens https://bugs.ruby-lang.org/issues/19835 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- GitHub Pull Request: https://github.com/ruby/ruby/pull/8192 The parser does not free the `tbl` of the `struct vtable` when there are leftover `lvtbl` in the parser. This causes a memory leak. The following script reproduces this issue: ```ruby 10.times do 100_000.times do Ripper.parse("class Foo") end puts `ps -o rss= -p #{$$}` end ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:114356] [Ruby master Bug#19833] Superclass of BasicObject is broken.
by ksss (Yuki Kurihara) 12 Aug '23

12 Aug '23

Issue #19833 has been reported by ksss (Yuki Kurihara). ---------------------------------------- Bug #19833: Superclass of BasicObject is broken. https://bugs.ruby-lang.org/issues/19833 * Author: ksss (Yuki Kurihara) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-08-08T00:21:45Z master 69292676a2) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I encountered a phenomenon where a non-class object appeared in the superclass of BasicObject. The minimum reproduction code is below. ```rb module Mod end BasicObject.include Mod # or BasicObject.prepend Mod p BasicObject.superclass #=> 2431129 or false ``` I think it is a practical problem because I found it by running code that monitors `singleton_method_added` as follows. https://github.com/ksss/orthoses/blob/341019c78ba625bc5d36c0f359c7d88621990… -- https://bugs.ruby-lang.org/

4 3

[ruby-core:114315] [Ruby master Bug#19789] YJIT + rustc 1.71.0 is broken with macOS
by hsbt (Hiroshi SHIBATA) 12 Aug '23

12 Aug '23

Issue #19789 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #19789: YJIT + rustc 1.71.0 is broken with macOS https://bugs.ruby-lang.org/issues/19789 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Priority: Normal * Assignee: yjit * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I got some segmentation fault on macOS. ``` 1) Failure: TestVMDump#test_darwin_invalid_call [/Users/hsbt/Documents/github.com/ruby/ruby/test/ruby/test_vm_dump.rb:11]: pid 35071 exit 1 | -e:1: [BUG] Bus Error at 0x0000000000000001 | ruby 3.3.0dev (2023-07-30T06:13:58Z master b5c74d5488) [arm64-darwin23] | | -- Crash Report log information -------------------------------------------- | See Crash Report log file in one of the following locations: | * ~/Library/Logs/DiagnosticReports | * /Library/Logs/DiagnosticReports | for more details. | Don't forget to include the above Crash Report log file in bug reports. | | -- Control frame information ----------------------------------------------- | c:0003 p:---- s:0010 e:000009 CFUNC :call | c:0002 p:0015 s:0006 e:000005 EVAL -e:1 [FINISH] | c:0001 p:0000 s:0003 E:000a30 DUMMY [FINISH] | | -- Ruby level backtrace information ---------------------------------------- | -e:1:in `<main>' | -e:1:in `call' | | -- Threading information --------------------------------------------------- | Total ractor count: 1 | Ruby thread count for this ractor: 1 | | -- Machine register context ------------------------------------------------ | x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x0000000000000000 | x3: 0x0000000000000000 x4: 0x0000000000000000 x5: 0x0000000000000000 | x6: 0x0000000000000000 x7: 0x0000000000000000 x18: 0x0000000000000000 | x19: 0x0000000000000000 x20: 0x000000016faadf40 x21: 0x000000016faadf40 | x22: 0x000000016faadec0 x23: 0x0000600001256eb0 x24: 0x000000016faadc70 | x25: 0x0000000000000000 x26: 0x0000000000000000 x27: 0x0000000000000000 | x28: 0x0000000140e04f20 lr: 0x000000019b211050 fp: 0x000000016faadd30 | sp: 0x000000016faadd30 | | -- C level backtrace information ------------------------------------------- | 1360: Abbrev Number 707 not found .. ``` I filed it and other failures to https://gist.github.com/hsbt/ea3e52d9fb52aed58d25caf839eae5ff @katei found this issue caused by YJIT and rustc 1.71.0. It's not happend with ``` ../ruby/configure -C --disable-install-doc --with-openssl-dir=/opt/homebrew/opt/openssl(a)1.1 --with-readline-dir=/opt/homebrew/opt/readline --with-libyaml-dir=/opt/homebrew/opt/libyaml RUSTC='rustc +1.70.0' ``` But `RUSTC='rustc +1.71.0'` is failed with same error on macOS Sonoma(beta) and Ventura. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:114328] [Ruby master Bug#19793] Segmentation fault with large arrays
by sczimmer (Scott Zimmermann) 12 Aug '23

12 Aug '23

Issue #19793 has been reported by sczimmer (Scott Zimmermann). ---------------------------------------- Bug #19793: Segmentation fault with large arrays https://bugs.ruby-lang.org/issues/19793 * Author: sczimmer (Scott Zimmermann) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [aarch64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I was doing ruby koans to learn ruby and I got a segmentation fault when it gets to the part where it uses `Symbol.all_symbols`. I realized it happens with any large Array, but I cannot reproduce in a small test script, just when it runs the whole ruby koans. So the minimal way to reproduce I have is: download rubykoans: https://github.com/edgecase/ruby_koans/blob/master/download/rubykoans.zip?r… ``` unzip rubykoans.zip cd koans # fix deprecated method call for ruby 3.2 ruby -i -pe 'sub "File.exists", "File.exist"' neo.rb ``` Edit about_asserts.rb, adding these two statements to make a big array to the first koan: ``` def test_assert_truth array = [] 99130.times { array << "a string"} assert false # This should be true end ``` run `ruby path_to_enlightenment.rb` and get a backtrace like the attached backtrace.txt I've tried this on two servers, ubuntu aarch64 and debian x86_64. On both it crashes with ruby 3.2.2 and works fine with ruby 3.1. On both I installed ruby built from source with RVM. On the server with more ram I had to increase the number more (above it's 99130) to get it to crash. ---Files-------------------------------- backtrace.txt (21.7 KB) -- https://bugs.ruby-lang.org/

4 5

[ruby-core:114381] [Ruby master Bug#19838] Ripper nested heredocs
by kddnewton (Kevin Newton) 12 Aug '23

12 Aug '23

Issue #19838 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #19838: Ripper nested heredocs https://bugs.ruby-lang.org/issues/19838 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I'm seeing some odd behavior on nested heredocs in the ripper lexer. ``` ruby <<~H1 1 #{<<~H2} 2 H2 3 H1 ``` $ cat test.rb | ruby -rripper -e 'pp Ripper.lex(ARGF.read)' ``` ruby [[[1, 0], :on_heredoc_beg, "<<~H1", BEG], [[1, 5], :on_nl, "\n", BEG], [[2, 0], :on_ignored_sp, " ", BEG], [[2, 2], :on_tstring_content, "1\n", BEG], [[3, 0], :on_ignored_sp, " ", BEG], [[3, 2], :on_embexpr_beg, "\#{", BEG], [[3, 4], :on_heredoc_beg, "<<~H2", BEG], [[3, 9], :on_embexpr_end, "}", END], [[3, 10], :on_tstring_content, "\n", BEG], [[4, 0], :on_ignored_sp, " ", BEG], [[4, 4], :on_tstring_content, "2\n", BEG], [[5, 0], :on_heredoc_end, " H2\n", BEG], [[6, 0], :on_ignored_sp, " ", BEG], [[6, 2], :on_tstring_content, "3\n", BEG], [[7, 0], :on_heredoc_end, "H1\n", BEG]] ``` This seems totally correct. But if you change it to a non-indenting heredoc: ``` ruby <<-H1 1 #{<<~H2} 2 H2 3 H1 ``` $ cat test.rb | ruby -rripper -e 'pp Ripper.lex(ARGF.read)' ``` ruby [[[1, 0], :on_heredoc_beg, "<<-H1", BEG], [[1, 5], :on_nl, "\n", BEG], [[2, 0], :on_tstring_content, " 1\n" + " ", BEG], [[3, 2], :on_embexpr_beg, "\#{", BEG], [[3, 4], :on_heredoc_beg, "<<~H2", BEG], [[3, 9], :on_embexpr_end, "}", END], [[3, 10], :on_tstring_content, "\n" + " 3\n", BEG], [[4, 0], :on_ignored_sp, " ", BEG], [[4, 4], :on_tstring_content, "2\n", BEG], [[5, 0], :on_heredoc_end, " H2\n", BEG], [[7, 0], :on_heredoc_end, "H1\n", BEG]] ``` Now the newline on line 3 gets concatenated with the content from line 6, and that token is dropped from the list entirely. This seems unintentional, but I'm not sure. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114365] [Ruby master Bug#19834] Segmentation fault while running in docker
by ramachandran＠mallow-tech.com (Ramachandran A) 09 Aug '23

09 Aug '23

Issue #19834 has been reported by ramachandran(a)mallow-tech.com (Ramachandran A). ---------------------------------------- Bug #19834: Segmentation fault while running in docker https://bugs.ruby-lang.org/issues/19834 * Author: ramachandran(a)mallow-tech.com (Ramachandran A) * Status: Open * Priority: Normal * ruby -v: 2.6.3 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` 2023-08-09 12:44:32 /usr/local/lib/ruby/2.6.0/openssl/buffering.rb:383: [BUG] Illegal instruction at 0x0000ffff90d911a0 2023-08-09 12:44:32 ruby 2.6.3p62 (2019-04-16 revision 67580) [aarch64-linux] 2023-08-09 12:44:32 2023-08-09 12:44:32 -- Control frame information ----------------------------------------------- 2023-08-09 12:44:32 c:0046 p:---- s:0274 e:000273 CFUNC :syswrite_nonblock 2023-08-09 12:44:32 c:0045 p:0013 s:0268 e:000267 METHOD /usr/local/lib/ruby/2.6.0/openssl/buffering.rb:383 2023-08-09 12:44:32 c:0044 p:0021 s:0261 e:000260 BLOCK /usr/local/lib/ruby/2.6.0/net/protocol.rb:277 [FINISH] 2023-08-09 12:44:32 c:0043 p:---- s:0253 e:000252 IFUNC 2023-08-09 12:44:32 c:0042 p:---- s:0250 e:000249 CFUNC :each 2023-08-09 12:44:32 c:0041 p:---- s:0247 e:000246 CFUNC :each_with_index ``` I am using Ruby 2.6.3 in my project. It works fine until this week, I don't know why this is occurring. I have tried the solution mentioned in https://bugs.ruby-lang.org/issues/18555#note-6 the above issue, but it doesn't solve my problem. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:114221] [Ruby master Bug#19771] Backport 79a4484, abfac22
by krk (Kerem Kat) 08 Aug '23

08 Aug '23

Issue #19771 has been reported by krk (Kerem Kat). ---------------------------------------- Bug #19771: Backport 79a4484, abfac22 https://bugs.ruby-lang.org/issues/19771 * Author: krk (Kerem Kat) * Status: Open * Priority: Normal * ruby -v: 3.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- * https://github.com/ruby/ruby/commit/79a4484a072e9769b603e7b4fbdb15b1d7eccb15 * https://github.com/ruby/ruby/commit/abfac2222bd51a03ec11b64f4770179cb6d06515 Related backport PR: https://github.com/ruby/ruby/pull/8023 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:114342] [Ruby master Feature#19830] Allow `Array#transpose` to take an optional size argument
by tomstuart (Tom Stuart) 04 Aug '23

04 Aug '23

Issue #19830 has been reported by tomstuart (Tom Stuart). ---------------------------------------- Feature #19830: Allow `Array#transpose` to take an optional size argument https://bugs.ruby-lang.org/issues/19830 * Author: tomstuart (Tom Stuart) * Status: Open * Priority: Normal ---------------------------------------- One benefit of supplying an initial value to `Enumerable#inject` is that it avoids an annoying edge case when the collection is empty: ``` >> [1, 2, 3].inject(:+) => 6 # good >> [].inject(:+) => nil # bad >> [].inject(0, :+) => 0 # good ``` A similar edge case exists for `Array#transpose`: ``` >> [[1, :a], [2, :b], [3, :c]].transpose => [[1, 2, 3], [:a, :b, :c]] # good >> [].transpose => [] # bad ``` Although no explicit `nil` is produced here, the subtle problem is that the caller may assume that the result array contains arrays, and that assumption leads to `nil`s in the empty case: ``` >> [[1, :a], [2, :b], [3, :c]].transpose.then { _2.join } => "abc" >> [].transpose.then { _2.join } undefined method `join' for nil:NilClass (NoMethodError) ``` If we allow `Array#transpose` to take an optional argument specifying the size of the result array, we can use this to always return an array of the correct size: ``` >> [[1, :a], [2, :b], [3, :c]].transpose(2) => [[1, 2, 3], [:a, :b, :c]] # good >> [].transpose(2) => [[], []] # good ``` By avoiding an unexpectedly empty result array, we also avoid unexpected downstream `nil`s: ``` >> [[1, :a], [2, :b], [3, :c]].transpose(2).then { _2.join } => "abc" >> [].transpose(2).then { _2.join } => "" ``` Here is a patch which adds an optional argument to `Array#transpose` to support the above usage: https://github.com/ruby/ruby/pull/8167 Something similar was requested eleven years ago in #6852. I believe this feature addresses the problem expressed in that issue without compromising backward compatibility with existing callers of #transpose. -- https://bugs.ruby-lang.org/

2 3