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

[ruby-core:120359] [Ruby master Bug#20976] ethon 0.15.0 began to segfault
by mtasaka (Mamoru TASAKA) 24 Dec '24

24 Dec '24

Issue #20976 has been reported by mtasaka (Mamoru TASAKA). ---------------------------------------- Bug #20976: ethon 0.15.0 began to segfault https://bugs.ruby-lang.org/issues/20976 * Author: mtasaka (Mamoru TASAKA) * Status: Open * ruby -v: ruby 3.4.0dev (2024-12-21 master 6114094aa0) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Looks like ethon 0.15.0: https://github.com/typhoeus/ethon/tree/0b1c2278806502ecbc6814a245f6b11f5365… began to segfault frequently (not always) with recent ruby 3.4.0dev. Looks like: commit:fef8ecc708 does not cause segfault commit:018b775039 seems to cause segfault: Trying with commit:6114094aa0 , segfaulting log is attached. ---Files-------------------------------- backtrace.log.txt (86 KB) -- https://bugs.ruby-lang.org/

3 5

[ruby-core:120363] [Ruby master Bug#20977] backtick is used for syntax errors related to 'it'
by jnchito (Junichi Ito) 23 Dec '24

23 Dec '24

Issue #20977 has been reported by jnchito (Junichi Ito). ---------------------------------------- Bug #20977: backtick is used for syntax errors related to 'it' https://bugs.ruby-lang.org/issues/20977 * Author: jnchito (Junichi Ito) * Status: Open * ruby -v: ruby 3.4.0rc1 (2024-12-12 master 29caae9991) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The following error message uses single quote for "'it'": ``` irb(main):012> [10].each_with_index { p "#{it}:#{_2}" } #=> 10 irb(main):013> <internal:kernel>:168:in 'Kernel#loop': (irb):12: syntax error found (SyntaxError) > 12 | ... _2}" } #=> 10 | ^~ numbered parameters are not allowed when 'it' is already used 13 | 14 | from /Users/jnito/.rbenv/versions/3.4.0-rc1/lib/ruby/gems/3.4.0+1/gems/irb-1.14.1/exe/irb:9:in '<top (required)>' from /Users/jnito/.rbenv/versions/3.4.0-rc1/bin/irb:25:in 'Kernel#load' from /Users/jnito/.rbenv/versions/3.4.0-rc1/bin/irb:25:in '<main>' ``` However, the error below uses backtick: ``` irb(main):019* [1, 2, 3].map.with_index(10) do |n, i| irb(main):020* it * i irb(main):021> end <internal:kernel>:168:in 'Kernel#loop': (irb):20: syntax error found (SyntaxError) 19 | [1, 2, 3].map.with_index(10) do |n, i| > 20 | it * i | ^~ `it` is not allowed when an ordinary parameter is defined 21 | end 22 | from /Users/jnito/.rbenv/versions/3.4.0-rc1/lib/ruby/gems/3.4.0+1/gems/irb-1.14.1/exe/irb:9:in '<top (required)>' from /Users/jnito/.rbenv/versions/3.4.0-rc1/bin/irb:25:in 'Kernel#load' from /Users/jnito/.rbenv/versions/3.4.0-rc1/bin/irb:25:in '<main>' ``` So it should use single quote for consistency. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:119413] [Ruby master Bug#20779] Un-rescuable thread creation limit on Mac
by hms (Hal Spitz) 23 Dec '24

23 Dec '24

Issue #20779 has been reported by hms (Hal Spitz). ---------------------------------------- Bug #20779: Un-rescuable thread creation limit on Mac https://bugs.ruby-lang.org/issues/20779 * Author: hms (Hal Spitz) * Status: Open * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Thread.new will hang the ruby process once past the OSX limit. It does not appear that's possible to trap and rescue failed thread creation. It seems the Mac has a limit to the number of threads it supports and googling the issue suggests the limit has been known to change with hardware and OS releases. While I hit the thread creation limit due to a bug in my code and the number of threads that I was attempting to create (12,250+) is an unlikely use-case, I am hoping it would be possible to turn this into a rescuable error. While I'm reporting this on 3.3.5, I have tested the issue and the inability to rescue back to 3.3.1. (Thanks to @raels for being a great second set of eyes to make sure I wasn't doing anything goofy / wrong before making this report. Also, another callout and thanks to both @eregon and @bensheldon over at concurrent-ruby for the unbelievably quick and helpful response to my initial bug report over there). ---Files-------------------------------- hang.rb (713 Bytes) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115438] [Ruby master Misc#20013] Travis CI status
by jaruga (Jun Aruga) 23 Dec '24

23 Dec '24

Issue #20013 has been reported by jaruga (Jun Aruga). ---------------------------------------- Misc #20013: Travis CI status https://bugs.ruby-lang.org/issues/20013 * Author: jaruga (Jun Aruga) * Status: Open * Priority: Normal ---------------------------------------- I would like to use this ticket to manage our activities to report Travis CI status. Because there is Travis CI status page provided by Travis CI. However, even when the page shows ok, I actually see infra issues. https://www.traviscistatus.com/ I would share my activities and report the Travis CI status on the ticket. The ticket's status is not closed until we stop using Travis CI. The easiest option to fix the Travis infra issue is to email Travis CI support `support _AT_ travis-ci.com`. You can check [this ruby/ruby Travis CI wiki page](https://github.com/ruby/ruby/wiki/CI-Servers#travis-ci) for details. -- https://bugs.ruby-lang.org/

2 49

[ruby-core:120355] [Ruby master Bug#20975] TestEval#test_outer_local_variable_under_gc_compact_stress failure on s390x
by mtasaka (Mamoru TASAKA) 23 Dec '24

23 Dec '24

Issue #20975 has been reported by mtasaka (Mamoru TASAKA). ---------------------------------------- Bug #20975: TestEval#test_outer_local_variable_under_gc_compact_stress failure on s390x https://bugs.ruby-lang.org/issues/20975 * Author: mtasaka (Mamoru TASAKA) * Status: Open * ruby -v: ruby 3.4.0dev (2024-12-21 master 6114094aa0) * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Trying with commit:6114094aa049ffcf3202254933e5da1552837c32 : testsuite on s390x shows error: ``` 205) Error: TestEval#test_outer_local_variable_under_gc_compact_stress: RuntimeError: compaction doesn't work well on s390x. Omit the test in the caller. /builddir/build/BUILD/ruby-3.4.0_20241221.1252git6114094aa0-build/ruby-3.4.0-6114094aa0/tool/lib/envutil.rb:261:in 'EnvUtil.under_gc_compact_stress' /builddir/build/BUILD/ruby-3.4.0_20241221.1252git6114094aa0-build/ruby-3.4.0-6114094aa0/test/ruby/test_eval.rb:649:in '<main>' /builddir/build/BUILD/ruby-3.4.0_20241221.1252git6114094aa0-build/ruby-3.4.0-6114094aa0/test/ruby/test_eval.rb:643:in 'TestEval#test_outer_local_variable_under_gc_compact_stress' Finished tests in 672.150857s, 47.6857 tests/s, 9724.2724 assertions/s. 32052 tests, 6536178 assertions, 0 failures, 1 errors, 204 skips ruby -v: ruby 3.4.0dev (2024-12-21 master 6114094aa0) +PRISM [s390x-linux] make: *** [uncommon.mk:964: yes-test-all] Error 1 ``` Perhaps starting from commit:e23a60b929cff951252167935e8868b69ae3dc74 . Looks like there is some confusion about how tests should be skipped wrt GC compaction on s390x? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120141] [Ruby master Bug#20937] "can't set length of shared string" error when using OpenSSL::Cipher#update with buffer
by akiellor (Andrew Kiellor) 22 Dec '24

22 Dec '24

Issue #20937 has been reported by akiellor (Andrew Kiellor). ---------------------------------------- Bug #20937: "can't set length of shared string" error when using OpenSSL::Cipher#update with buffer https://bugs.ruby-lang.org/issues/20937 * Author: akiellor (Andrew Kiellor) * Status: Open * ruby -v: ruby 3.3.6 (2024-11-05 revision 75015d4c1f) +YJIT [arm64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- We've observed a recurring "can't set length of shared string" error in production emerging from the `aws-sdk-s3` library when using it's client encryption features. The sdk in this mode uses OpenSSL::Cipher in decrypt mode with a String buffer. It appears that under some circumstances the buffer becomes a "shared string" and is no longer compatible with the requirements of OpenSSL::Cipher#update. I've attached a reproduction scenario using only the ruby standard library. ``` shell $ ruby -v ruby 3.3.6 (2024-11-05 revision 75015d4c1f) +YJIT [arm64-darwin23] $ ruby scripty.rb scripty.rb:32:in `update': can't set length of shared string (RuntimeError) from scripty.rb:32:in `block (2 levels) in <main>' from scripty.rb:31:in `each' from scripty.rb:31:in `block in <main>' from /nix/store/fhmbmmzr4h5yax66nl2x44rrdf039b3s-ruby-3.3.6/lib/ruby/3.3.0/tempfile.rb:447:in `create' from scripty.rb:26:in `<main>' ``` The attached script has a few different read patterns, some fail and some do not. ---Files-------------------------------- scripty.rb (1.15 KB) -- https://bugs.ruby-lang.org/

5 8

[ruby-core:120336] [Ruby master Bug#20972] OpenSSL Memory Usage
by mrkgrandjean (Mark Grandjean) 21 Dec '24

21 Dec '24

Issue #20972 has been reported by mrkgrandjean (Mark Grandjean). ---------------------------------------- Bug #20972: OpenSSL Memory Usage https://bugs.ruby-lang.org/issues/20972 * Author: mrkgrandjean (Mark Grandjean) * Status: Open * ruby -v: 3.3.6 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- While testing large file uploads I noticed the OpenSSL Buffering is allocating a lot of memory for file uploads. Similar to the issue in this ticket from a few years ago https://bugs.ruby-lang.org/issues/14426 Using the same test code from that ticket ``` ruby require "http" require "memory_profiler" require "stringio" body = StringIO.new("a" * 5*1024*1024) MemoryProfiler.report do HTTP.post("https://example.com", body: body) end.pretty_print ``` in ruby 2.6.10 ``` allocated memory by gem ----------------------------------- 1913287 unicode_normalize 1053463 llhttp-ffi-0.5.0 187849 http-5.2.0 50168 openssl 36180 addressable-2.8.7 8904 ipaddr 272 other ``` While testing in Ruby 3.3.6 ``` allocated memory by gem ----------------------------------- 16104976 openssl 2393456 unicode_normalize 1053880 llhttp-ffi-0.5.0 151633 http-5.2.0 9813 addressable-2.8.7 7872 ipaddr 240 other 40 forwardable ``` It looks like the memory allocation issue has returned. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120347] [Ruby master Feature#18439] YJIT: Support Microsoft x86 calling convention
by maximecb (Maxime Chevalier-Boisvert) 20 Dec '24

20 Dec '24

Issue #18439 has been updated by maximecb (Maxime Chevalier-Boisvert). It would definitely be simpler if integers were handled the same way on windows as on Linux and macOS. ---------------------------------------- Feature #18439: YJIT: Support Microsoft x86 calling convention https://bugs.ruby-lang.org/issues/18439#change-111124 * Author: usa (Usaku NAKAMURA) * Status: Assigned * Assignee: yjit ---------------------------------------- I heard that supporting YJIT for VC++ needs mmap from k0kubun-san, so I implemented tiny mmap emulation on Windows and committed it to master. And, I found we need more changes to actually enabled YJIT for VC++, at least: - YJIT requires `OPT_DIRECT_THREADED_CODE` or `OPT_CALL_THREADED_CODE` in `rb_yjit_compile_iseq()`. Really? - Maybe ABI deffers between VC++ and YJIT's expectation. Can I get support to fix above? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120346] [Ruby master Feature#18439] YJIT: Support Microsoft x86 calling convention
by YO4 (Yoshinao Muramatsu) 20 Dec '24

20 Dec '24

Issue #18439 has been updated by YO4 (Yoshinao Muramatsu). The Windows version of ruby limits Integer to 30 bits even in x64 environments. I am afraid that to support this in yjit would add complexity, which would harm the evolution of yjit. Would 30bit Integer support actually have a negative impact? Nevertheless, regardless of yjit support, I would like to see the Windows version of Integer's limitation removed. ---------------------------------------- Feature #18439: YJIT: Support Microsoft x86 calling convention https://bugs.ruby-lang.org/issues/18439#change-111120 * Author: usa (Usaku NAKAMURA) * Status: Assigned * Assignee: yjit ---------------------------------------- I heard that supporting YJIT for VC++ needs mmap from k0kubun-san, so I implemented tiny mmap emulation on Windows and committed it to master. And, I found we need more changes to actually enabled YJIT for VC++, at least: - YJIT requires `OPT_DIRECT_THREADED_CODE` or `OPT_CALL_THREADED_CODE` in `rb_yjit_compile_iseq()`. Really? - Maybe ABI deffers between VC++ and YJIT's expectation. Can I get support to fix above? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117812] [Ruby master Bug#20478] Circular parameter syntax error rules
by kddnewton (Kevin Newton) 20 Dec '24

20 Dec '24

Issue #20478 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20478: Circular parameter syntax error rules https://bugs.ruby-lang.org/issues/20478 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I would like to revisit https://bugs.ruby-lang.org/issues/16343. These cases are syntax errors: ```ruby def foo(bar = -> { bar }) end # no lambda parameters def foo(bar = ->() { bar }) end # no lambda parameters def foo(bar = baz { bar }) end # no block parameters def foo(bar = baz { _1 + bar }) end # parameters, but no pipes def foo(bar = baz { it + bar }) end # parameters, but no pipes ``` These cases are not syntax errors: ```ruby def foo(bar = ->(baz) { bar }) end # lambda parameters def foo(bar = baz { || bar }) end # no block parameters but empty pipes def foo(bar = baz { |qux| bar }) end # block parameters ``` I don't think these rules are very intuitive, and they feel somewhat arbitrary. I would like to suggest we change them to be either: * Syntax error is raised if the parameter is ever read in its default value at any scope depth * Syntax error is raised if the parameter is ever read in its default value at depth 0 Either one is fine by me, but gating the syntax error based on the presence of pipes is really confusing. -- https://bugs.ruby-lang.org/

4 10