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

[ruby-core:114113] [Ruby master Bug#19761] AddressSanitizer fails with Thread and Process

by nobu (Nobuyoshi Nakada)

Issue #19761 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19761: AddressSanitizer fails with Thread and Process https://bugs.ruby-lang.org/issues/19761 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- With AddressSanitizer on macOS, this code crashes. ```ruby system('') Thread.new {} 300_000.times do String.new(capacity: 1000) end ``` ``` ==62870==ERROR: AddressSanitizer failed to deallocate 0x8000 (32768) bytes at address 0x62d00000a400 AddressSanitizer: CHECK failed: sanitizer_posix.cpp:61 "(("unable to unmap" && 0)) != (0)" (0x0, 0x0) (tid=857549) <empty stack> Assertion Failed: ../debug/vm_core.h:1853:rb_current_execution_context:!expect_ec || ec != NULL ruby 3.3.0dev (2023-07-08T02:54:37Z tmp 0083edc3a0) [x86_64-darwin22] -- 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. -- C level backtrace information ------------------------------------------- ``` -- https://bugs.ruby-lang.org/

9 months

2
1
0 0

[ruby-core:114218] [Ruby master Bug#19770] TLS / Certificate Hostname Verification against IP fails with "address family must be specified"

by Schachi65 (Joachim Schachermayer)

Issue #19770 has been reported by Schachi65 (Joachim Schachermayer). ---------------------------------------- Bug #19770: TLS / Certificate Hostname Verification against IP fails with "address family must be specified" https://bugs.ruby-lang.org/issues/19770 * Author: Schachi65 (Joachim Schachermayer) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.4 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I dont't use Ruby directly but indirectly via Fluentd-1.16.1 (https://www.fluentd.org/). Fluentd uses Ruby 3.1.4. The problem is, that a TLS connection from a Fluentd Client to a Fluentd Server fails, if the connection is established using the IP address of the server and tls_verify_hostname is switched to on. In the servers certificate, in the SubjectAlternativeNames extention, there is the servers IP address set with the correct value. I get the error message " **address family must be specified** ". **Probable cause** : ext/openssl/lib/openssl/ **ssl.rb** line 288: Here the Methode IPAddr.new(hostname) is called with just one argument: return true if san.value == IPAddr.new( **hostname** ).hton lib/ **ipaddr.rb** line 594: Here the exception is raised with the observed error message: when Socket::AF_UNSPEC **raise** AddressFamilyError, " **address family must be specified** " The exception is raised, because the variable "family" has the value " **Socket::AF_UNSPEC** " because thats the default value of "family" if there is no additional parameter in the call to "initialize()". The documumentation of "initialize()" says in line 575/576/577: "Although the address family is determined automatically from a specified string, you can specify one explicitly by the optional second argument." But that automatic address determination is done too late. If no second parameter is given, it is not done at all because that exception is raised (assumption: the addr i always a string). **Probable solution** : If the address family is set to Socket::AF_UNSPEC with the call of "initialize()", dont't raise an exception now but do the in the comment announced automatic adress family detection here. -- https://bugs.ruby-lang.org/

9 months

3
3
0 0

[ruby-core:114323] [Ruby master Bug#19791] Debugger does not handle delete key correctly

by stuartb (Stuart Bury)

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/

9 months, 1 week

2
4
0 0

[ruby-core:114379] [Ruby master Bug#19836] Parser leaks memory for incomplete lambdas

by peterzhu2118 (Peter Zhu)

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/

9 months, 1 week

2
1
0 0

[ruby-core:114377] [Ruby master Bug#19835] Parser leaks memory for incomplete tokens

by peterzhu2118 (Peter Zhu)

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/

9 months, 1 week

2
1
0 0

[ruby-core:114356] [Ruby master Bug#19833] Superclass of BasicObject is broken.

by ksss (Yuki Kurihara)

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/

9 months, 1 week

4
3
0 0

[ruby-core:114315] [Ruby master Bug#19789] YJIT + rustc 1.71.0 is broken with macOS

by hsbt (Hiroshi SHIBATA)

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/

9 months, 1 week

3
3
0 0

[ruby-core:114328] [Ruby master Bug#19793] Segmentation fault with large arrays

by sczimmer (Scott Zimmermann)

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/

9 months, 1 week

4
5
0 0

[ruby-core:114381] [Ruby master Bug#19838] Ripper nested heredocs

by kddnewton (Kevin Newton)

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/

9 months, 1 week

1
0
0 0

[ruby-core:114365] [Ruby master Bug#19834] Segmentation fault while running in docker

by ramachandran＠mallow-tech.com (Ramachandran A)

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/

9 months, 2 weeks

3
6
0 0

2024

2023

2022

ruby-core August 2023