- ruby-core - ml.ruby-lang.org

[ruby-core:120378] [Ruby master Bug#20979] +comment does not affect parsetree without `--parser=parse.y`
by znz (Kazuhiro NISHIYAMA) 24 Dec '24

24 Dec '24

Issue #20979 has been reported by znz (Kazuhiro NISHIYAMA). ---------------------------------------- Bug #20979: +comment does not affect parsetree without `--parser=parse.y` https://bugs.ruby-lang.org/issues/20979 * Author: znz (Kazuhiro NISHIYAMA) * Status: Open * Target version: 3.4 * ruby -v: ruby 3.4.0dev (2024-12-23T02:52:14Z master b19fcd02fa) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- `ruby --help` says `+comment Add comments to AST (affects parsetree).`, but it does not affect without `--parser=parse.y`. If it is intentional, I think more help messages or more explanation somewhere. ``` Dump List: insns Instruction sequences. yydebug yydebug of yacc parser generator. parsetree Abstract syntax tree (AST). -optimize Disable optimization (affects insns). +error-tolerant Error-tolerant parsing (affects yydebug, parsetree). +comment Add comments to AST (affects parsetree). ``` ``` % git diff --no-index --stat =(ruby --dump=parsetree -e 0) =(ruby --dump=parsetree+comment -e 0) % git diff --no-index --stat =(ruby --parser=parse.y --dump=parsetree -e 0) =(ruby --parser=parse.y --dump=parsetree+comment -e 0) /tmp/{zshEGciGv => zshWgqfVT} | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120089] [Ruby master Bug#20929] TestTime have an assertion different from current implementation.
by YO4 (Yoshinao Muramatsu) 24 Dec '24

24 Dec '24

Issue #20929 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #20929: TestTime have an assertion different from current implementation. https://bugs.ruby-lang.org/issues/20929 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- test/ruby/test_time.rb have following assersion function. ``` def assert_zone_encoding(time) zone = time.zone assert_predicate(zone, :valid_encoding?) if zone.ascii_only? assert_equal(Encoding::US_ASCII, zone.encoding) else enc = Encoding.default_internal || Encoding.find('locale') assert_equal(enc, zone.encoding) end end ``` In current implementation, Time#zone are returned in US_ASCII or locale encoding, which does not seem to take into account the default_internal. ``` C:\>ruby -e "puts Time.now.zone" 東京 (標準時) C:\>ruby -e "puts Time.now.zone.encoding" Windows-31J C:\>ruby -EWindows-31J:UTF-8 -e "puts Time.now.zone" 東京 (標準時) C:\>ruby -EWindows-31J:UTF-8 -e "puts Time.now.zone.encoding" Windows-31J ``` -- https://bugs.ruby-lang.org/

3 5

[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: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