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

[ruby-core:114546] [Ruby master Bug#18080] Syntax error on one-line pattern matching
by jeremyevans0 (Jeremy Evans) 25 Aug '23

25 Aug '23

Issue #18080 has been updated by jeremyevans0 (Jeremy Evans). @kddnewton Is this possible to support in YARP? @yui-knk Is this possible to support in parse.y/lrama? ---------------------------------------- Bug #18080: Syntax error on one-line pattern matching https://bugs.ruby-lang.org/issues/18080#change-104348 * Author: ko1 (Koichi Sasada) * Status: Open * Priority: Normal * ruby -v: 3.1.0dev * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- One line pattern matching with a method return value with parameters which are not surrounded by parenthesis raises syntax error. I think it is not intentional, but nobu said it's hard to support because of parse.y limitation. ```ruby p do end => a p a #=> nil p(1) do end => a p a #=> 1 p 1 do end => a #=> # syntax error, unexpected =>, expecting end-of-input # end => a # ^~ p 1 do end in a #=> # syntax error, unexpected `in', expecting end-of-input # end in a # ^~ ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114545] [Ruby master Bug#18073] test/ruby/test_jit.rb: "error: invalid use of '__builtin_va_arg_pack ()'" on Ruby 2.7.4 on gcc 4.8.5
by jeremyevans0 (Jeremy Evans) 25 Aug '23

25 Aug '23

Issue #18073 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed These failures look related to MJIT, which has been removed. ---------------------------------------- Bug #18073: test/ruby/test_jit.rb: "error: invalid use of '__builtin_va_arg_pack ()'" on Ruby 2.7.4 on gcc 4.8.5 https://bugs.ruby-lang.org/issues/18073#change-104347 * Author: jaruga (Jun Aruga) * Status: Closed * Priority: Normal * Backport: 2.6: UNKNOWN, 2.7: REQUIRED, 3.0: DONTNEED ---------------------------------------- I hit the following JIT test failures causing the following error on v2_7_4 tag (Ruby 2.7.4) with gcc 4.8.5 on RHEL 7. The tests work on Ruby 2.7.3 and also works on Ruby 3.0.2. ``` /mnt/git/ruby/ruby/.ext/include/x86_64-linux/rb_mjit_min_header-2.7.4.h: In function 'sprintf': /mnt/git/ruby/ruby/.ext/include/x86_64-linux/rb_mjit_min_header-2.7.4.h:442:3: error: invalid use of '__builtin_va_arg_pack ()' return __builtin___sprintf_chk (__s, 2 - 1, ^ ``` ``` $ which gcc /usr/bin/gcc $ gcc --version gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ git branch * (detached from v2_7_4) ... $ autoconf $ ./configure --enable-shared 2>&1 | tee configure.log $ make 2>&1 | tee make.log ``` Here is one of the failures. I would attach the full long files on this ticket. ``` $ make test-all TESTS="-v test/ruby/test_jit.rb" 2>&1 | tee make_test-all_test_jit.log ... 30) Failure: TestJIT#test_compile_insn_local [/mnt/git/ruby/ruby/test/ruby/test_jit.rb:62]: Expected 1 times of JIT success, but succeeded 0 times. script: """ p proc { foo = 1 foo }.call """ stderr: """ /mnt/git/ruby/ruby/.ext/include/x86_64-linux/rb_mjit_min_header-2.7.4.h: In function 'sprintf': /mnt/git/ruby/ruby/.ext/include/x86_64-linux/rb_mjit_min_header-2.7.4.h:442:3: error: invalid use of '__builtin_va_arg_pack ()' return __builtin___sprintf_chk (__s, 2 - 1, ^ compilation terminated due to -Wfatal-errors. Successful MJIT finish """ .. <1> expected but was <0>. ... Finished tests in 29.837252s, 3.1504 tests/s, 15.7186 assertions/s. 94 tests, 469 assertions, 87 failures, 0 errors, 4 skips ... ``` ---Files-------------------------------- configure.log (27.6 KB) make.log (102 KB) make_test-all_test_jit.log (77 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114539] [Ruby master Bug#19852] bundled_gems.rb & bigdecimal
by MSP-Greg (Greg L) 25 Aug '23

25 Aug '23

Issue #19852 has been reported by MSP-Greg (Greg L). ---------------------------------------- Bug #19852: bundled_gems.rb & bigdecimal https://bugs.ruby-lang.org/issues/19852 * Author: MSP-Greg (Greg L) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-08-25T13:01:21Z master f5c8bdaa8a) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Running the following: ```ruby ruby -rbigdecimal -e "puts BigDecimal::VERSION" ``` A warning is shown when bigdecimal.rb is loaded, when bigdecimal.so is loaded, an error is thrown: ``` /usr/local/lib/ruby/3.3.0+0/bundled_gems.rb:84:in `<': comparison of String with nil failed (ArgumentError) end + " which #{RUBY_VERSION < SINCE[gem] ? "will be" : "is"} not part of the default gems since Ruby #{SINCE[gem]}" ^^^^^^^^^^ from /usr/local/lib/ruby/3.3.0+0/bundled_gems.rb:84:in `warning?' from /usr/local/lib/ruby/3.3.0+0/bundled_gems.rb:90:in `block in <module:BUNDLED_GEMS>' ``` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:114543] [Ruby master Bug#17678] Ractors do not restart after fork
by jeremyevans0 (Jeremy Evans) 25 Aug '23

25 Aug '23

Issue #17678 has been updated by jeremyevans0 (Jeremy Evans). I updated https://github.com/ruby/ruby/pull/8283 to mark non-main ractors as terminated after fork. ---------------------------------------- Bug #17678: Ractors do not restart after fork https://bugs.ruby-lang.org/issues/17678#change-104345 * Author: ivoanjo (Ivo Anjo) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hello there! I'm working at Datadog on the `ddtrace` gem -- <https://github.com/DataDog/dd-trace-rb> and we're experimenting with using Ractors in our library but run into a few issues. ### Background When running a Ractor as a background process, the Ractor stops & does not restart when the application forks. ### How to reproduce (Ruby version & script) `ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux]` ```ruby r2 = Ractor.new do loop { puts "[#{Process.pid}] Ractor"; sleep(1) } end sleep(1) puts "[#{Process.pid}] Forking..." fork do sleep(5) puts "[#{Process.pid}] End fork." end loop do sleep(1) end ``` ### Expectation and result The application prints “Ractor” each second in the main process, but not in the fork. Expected the Ractor (defined as `r2`) to run in the fork. ``` [29] Ractor [29] Ractor [29] Forking... [29] Ractor [29] Ractor [29] Ractor [29] Ractor [29] Ractor [32] End fork. [29] Ractor [29] Ractor [29] Ractor ``` ### Additional notes Threads do not restart across forks either, so it might not be unreasonable to expect consistent behavior. However, it’s possible to detect a dead Thread and recreate it after a fork (e.g. with `#alive?`, `#status`), but there’s no such mechanism for Ractors. ### Suggested solutions 1. Auto-restart Ractors after fork 2. Add additional methods to Ractors that allow users to check & manage the status of the Ractor, similar to Thread. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114535] [Ruby master Bug#19851] Ripper returns and extra block argument for :params with :args_forward
by thyresias (Thierry Lambert) 25 Aug '23

25 Aug '23

Issue #19851 has been reported by thyresias (Thierry Lambert). ---------------------------------------- Bug #19851: Ripper returns and extra block argument for :params with :args_forward https://bugs.ruby-lang.org/issues/19851 * Author: thyresias (Thierry Lambert) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x64-mingw-ucrt] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby require 'ripper' class BasicParser < Ripper EVENTS.each do |event| module_eval(<<~RUBY, __FILE__, __LINE__ + 1) def on_#{event}(*args) puts "#{event}(\#{args.inspect})" args.unshift :#{event} args end RUBY end end BasicParser.new('def m(...); end').parse # stdout: # kw(["def"]) # sp([" "]) # ident(["m"]) # lparen(["("]) # op(["..."]) # args_forward([]) # params([nil, nil, nil, nil, nil, [:args_forward], :&]) ``` I would have expected the last `:params` argument to be `nil`, not `:&`. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:114540] [Ruby master Bug#17678] Ractors do not restart after fork
by ivoanjo (Ivo Anjo) 25 Aug '23

25 Aug '23

Issue #17678 has been updated by ivoanjo (Ivo Anjo). Ack, that seems a reasonable way of looking at this, having a way to detect that the ractor is dead would be enough to write some auto-restart code after fork (Erlang supervisor trees here we go :D). ---------------------------------------- Bug #17678: Ractors do not restart after fork https://bugs.ruby-lang.org/issues/17678#change-104341 * Author: ivoanjo (Ivo Anjo) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hello there! I'm working at Datadog on the `ddtrace` gem -- <https://github.com/DataDog/dd-trace-rb> and we're experimenting with using Ractors in our library but run into a few issues. ### Background When running a Ractor as a background process, the Ractor stops & does not restart when the application forks. ### How to reproduce (Ruby version & script) `ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux]` ```ruby r2 = Ractor.new do loop { puts "[#{Process.pid}] Ractor"; sleep(1) } end sleep(1) puts "[#{Process.pid}] Forking..." fork do sleep(5) puts "[#{Process.pid}] End fork." end loop do sleep(1) end ``` ### Expectation and result The application prints “Ractor” each second in the main process, but not in the fork. Expected the Ractor (defined as `r2`) to run in the fork. ``` [29] Ractor [29] Ractor [29] Forking... [29] Ractor [29] Ractor [29] Ractor [29] Ractor [29] Ractor [32] End fork. [29] Ractor [29] Ractor [29] Ractor ``` ### Additional notes Threads do not restart across forks either, so it might not be unreasonable to expect consistent behavior. However, it’s possible to detect a dead Thread and recreate it after a fork (e.g. with `#alive?`, `#status`), but there’s no such mechanism for Ractors. ### Suggested solutions 1. Auto-restart Ractors after fork 2. Add additional methods to Ractors that allow users to check & manage the status of the Ractor, similar to Thread. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114538] [Ruby master Bug#17678] Ractors do not restart after fork
by jeremyevans0 (Jeremy Evans) 25 Aug '23

25 Aug '23

Issue #17678 has been updated by jeremyevans0 (Jeremy Evans). Tracker changed from Feature to Bug Backport set to 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN Thanks for that information. It looks like ractors contain information about their state (shown in `inspect`), but that state is not updated on fork, unlike threads. So I think there is a bug, and it's that non-main ractors do not have their state to `terminated` upon fork (forking from non-main ractors is going to be prohibited, see #17516). ---------------------------------------- Bug #17678: Ractors do not restart after fork https://bugs.ruby-lang.org/issues/17678#change-104340 * Author: ivoanjo (Ivo Anjo) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hello there! I'm working at Datadog on the `ddtrace` gem -- <https://github.com/DataDog/dd-trace-rb> and we're experimenting with using Ractors in our library but run into a few issues. ### Background When running a Ractor as a background process, the Ractor stops & does not restart when the application forks. ### How to reproduce (Ruby version & script) `ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux]` ```ruby r2 = Ractor.new do loop { puts "[#{Process.pid}] Ractor"; sleep(1) } end sleep(1) puts "[#{Process.pid}] Forking..." fork do sleep(5) puts "[#{Process.pid}] End fork." end loop do sleep(1) end ``` ### Expectation and result The application prints “Ractor” each second in the main process, but not in the fork. Expected the Ractor (defined as `r2`) to run in the fork. ``` [29] Ractor [29] Ractor [29] Forking... [29] Ractor [29] Ractor [29] Ractor [29] Ractor [29] Ractor [32] End fork. [29] Ractor [29] Ractor [29] Ractor ``` ### Additional notes Threads do not restart across forks either, so it might not be unreasonable to expect consistent behavior. However, it’s possible to detect a dead Thread and recreate it after a fork (e.g. with `#alive?`, `#status`), but there’s no such mechanism for Ractors. ### Suggested solutions 1. Auto-restart Ractors after fork 2. Add additional methods to Ractors that allow users to check & manage the status of the Ractor, similar to Thread. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114536] [Ruby master Bug#17516] forking in a ractor causes Ruby to crash
by jeremyevans0 (Jeremy Evans) 25 Aug '23

25 Aug '23

Issue #17516 has been updated by jeremyevans0 (Jeremy Evans). I submitted a pull request to disallow fork from inside a ractor: https://github.com/ruby/ruby/pull/8283 ---------------------------------------- Bug #17516: forking in a ractor causes Ruby to crash https://bugs.ruby-lang.org/issues/17516#change-104338 * Author: pkmuldoon (Phil Muldoon) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- I just want to point out, there's absolutely no reason to do this, but r = Ractor.new do Process.fork() end Will cause: <internal:ractor>:267: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. [BUG] rb_thread_terminate_all: called by child thread (0x0000700004ddca40, 0x00007f981b567ee0) ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20] -- Crash Report log information -------------------------------------------- See Crash Report log file under the one of following: * ~/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:0001 p:---- s:0003 e:000002 (none) [FINISH] -- C level backtrace information ------------------------------------------- => #<Ractor:#3 (pry):5 terminated> [4] pry(main)> /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_vm_bugreport+0x6cf) [0x103084d1f] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_bug_without_die+0x206) [0x102e9e2b6] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_bug+0x71) [0x103091e6b] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_thread_terminate_all+0x329) [0x10301e5b9] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_ractor_terminate_all+0xa3) [0x102f8acc3] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_ec_cleanup+0x229) [0x102ea9299] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(ruby_stop+0x9) [0x102ea9509] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(thread_start_func_2+0x8ce) [0x103027fce] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(thread_start_func_1+0x10d) [0x10302753d] /usr/lib/system/libsystem_pthread.dylib(_pthread_start+0xe0) [0x7fff20382950] ---Files-------------------------------- ruby_2021-01-06-104315_phillip-muldoon-FA588.crash (31.8 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114532] [Ruby master Bug#17926] spec/ruby/core/file/atime_spec.rb: a random failing test on Travis ppc64le
by jaruga (Jun Aruga) 25 Aug '23

25 Aug '23

Issue #17926 has been updated by jaruga (Jun Aruga). Status changed from Feedback to Closed jeremyevans0 (Jeremy Evans) wrote in #note-5: > @jaruga We haven't been seeing this error on the ppc64le RubyCI server recently. Is this OK to close? @jeremyevans0 Yeah, it's ok to close. ---------------------------------------- Bug #17926: spec/ruby/core/file/atime_spec.rb: a random failing test on Travis ppc64le https://bugs.ruby-lang.org/issues/17926#change-104334 * Author: jaruga (Jun Aruga) * Status: Closed * Priority: Normal * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- I just observed the following test failing randomly on Travis ppc64le at the commit:fd65ef2a5aa8629676d1edb6410e4d4cf60b8045. When running this commit on my forked repo, the test passed. https://travis-ci.com/github/ruby/ruby/jobs/509310540#L2255 ``` $ $SETARCH make -s test-spec MSPECOPT=-ff ... 1) File.atime returns the last access time for the named file with microseconds FAILED Expected 0 == 123456 to be truthy but was false /home/travis/build/ruby/ruby/spec/ruby/core/file/atime_spec.rb:25:in `block (3 levels) in <top (required)>' /home/travis/build/ruby/ruby/spec/ruby/core/file/atime_spec.rb:3:in `<top (required)>' ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114530] [Ruby master Bug#17676] Accessing ENV from Ractor raises IsolationError
by ivoanjo (Ivo Anjo) 25 Aug '23

25 Aug '23

Issue #17676 has been updated by ivoanjo (Ivo Anjo). Thank you Jeremy! :) ---------------------------------------- Bug #17676: Accessing ENV from Ractor raises IsolationError https://bugs.ruby-lang.org/issues/17676#change-104329 * Author: delner (David Elner) * Status: Closed * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ## Background Accessing ENV variables from a Ractor will raise Ractor::IsolationError, as the Hash is non-shareable. ## How to reproduce ``` ruby ractor = Ractor.new do ENV['PATH'] end ractor.take ``` ## Expectation and result Ractor raises Ractor::IsolationError for ENV Expect to be able to access ENV variables from Ractors without raising an error. ``` `block in <main>': can not access non-shareable objects in constant Object::ENV by non-main Ractor. (Ractor::IsolationError) ``` ## Additional Notes Attempting to create a shareable copy of ENV currently fails: ```ruby Ractor.make_shareable(ENV, copy: true) # TypeError: cannot freeze ENV # from <internal:ractor>:812:in `freeze' ``` ## Suggested solutions 1. If ENV is a mutable hash, make a Ractor-compatible copy of ENV isolated to that Ractor. -- https://bugs.ruby-lang.org/

1 0