September 2024 - ruby-dev - ml.ruby-lang.org

[ruby-dev:52086] [Ruby master Bug#20489] Ractor behavior strange in ruby master
by nekoyama32767 (Jinsong Yu) 09 Jan '25

09 Jan '25

Issue #20489 has been reported by nekoyama32767 (Jinsong Yu). ---------------------------------------- Bug #20489: Ractor behavior strange in ruby master https://bugs.ruby-lang.org/issues/20489 * Author: nekoyama32767 (Jinsong Yu) * Status: Open * ruby -v: ruby 3.4.0dev (2024-05-14T01:58:31Z master 9d01f657b3) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- This is a tarai program Run`./ruby tarai_ractor.rb 2 8` is to use 2 thread to run 8 times tarai function total, that means 4 times tarai for each ractor(thread). ``` GC.disable def split_len(len, split) ret = [] mod = len % split head = 0 tail = 0 split.times do |i| if head >= len break end k = 0 if i < mod then k = 1 end tail = tail + (len/split) + k ret.append(head...tail) head = tail end return ret end def ary_split(ary, split) return split_len(ary.length,split) end def item_check(item) if item[0] != nil 1 + item_check(item[0]) + item_check(item[1]) else 1 end end def tarai(x, y, z) = x <= y ? y : tarai(tarai(x-1, y, z), tarai(y-1, z, x), tarai(z-1, x, y)) times = ARGV[0].to_i split = ARGV[1].to_i p split_len(times, split) split_len(times, split).each.map do |sp| Ractor.new (sp) { s = _1 s.each do tarai(13, 7, 0) end } end.each(&:take) ``` The problem is in ruby 3.1.2 and ruby 3.3 `./ruby tarai_ractor.rb 1 1` has simiular execute time with `./ruby tarai_ractor.rb 8 8` because each thread only run 1 time of tarai function, like follow: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux]: ``` time ruby exp_ractor_tarai.rb 1 1 [0...1] <internal:ractor>:267: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. real 0m1.442s user 0m1.429s sys 0m0.014s time ruby exp_ractor_tarai.rb 8 8 [0...1, 1...2, 2...3, 3...4, 4...5, 5...6, 6...7, 7...8] <internal:ractor>:267: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. real 0m1.857s user 0m13.817s sys 0m0.041s ``` But in ruby master(ruby 3.4.0dev) ruby 3.4.0dev (2024-05-14T01:58:31Z master 9d01f657b3) [x86_64-linux] 1 ractor 1 tarai: ``` time ../ruby exp_ractor_tarai.rb 1 1 `RubyGems' were not loaded. `error_highlight' was not loaded. `did_you_mean' was not loaded. `syntax_suggest' was not loaded. [0...1] exp_ractor_tarai.rb:47: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. real 0m1.671s user 0m1.666s sys 0m0.005s ``` 8 ractor 8 tarai: ``` time ../ruby exp_ractor_tarai.rb 8 8 `RubyGems' were not loaded. `error_highlight' was not loaded. `did_you_mean' was not loaded. `syntax_suggest' was not loaded. [0...1, 1...2, 2...3, 3...4, 4...5, 5...6, 6...7, 7...8] exp_ractor_tarai.rb:47: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. real 0m18.408s user 1m58.659s sys 0m0.021s ``` And in ruby 3.4.0dev when run `time ../ruby exp_ractor_tarai.rb 16 16` 16 thread should be used in system monitoring while only 8 threads are used. Ruby 3.3 and Ruby 3.1.2 do not have this problem. ---Files-------------------------------- thead16_16.png (168 KB) thread16_8.png (165 KB) -- https://bugs.ruby-lang.org/

5 13

[ruby-dev:52116] [Ruby master Bug#20767] VM_ASSERT fails on clear_method_entry_by_id_in_class() under a specific situation
by tagomoris (Satoshi Tagomori) 05 Nov '24

05 Nov '24

Issue #20767 has been reported by tagomoris (Satoshi Tagomori). ---------------------------------------- Bug #20767: VM_ASSERT fails on clear_method_entry_by_id_in_class() under a specific situation https://bugs.ruby-lang.org/issues/20767 * Author: tagomoris (Satoshi Tagomori) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- VM_ASSERT in `clear_method_entry_by_id_in_class()` (vm_method.c) fails when: * Kernel#require is refined * Kernel#require is replaced by `alias_method` and `define_method` * User code calls `require` * The aliased method entry is undefined Under this situation, `VM_ASSERT(cme->owner == T_CLASS)` fails in `clear_method_entry_by_id_in_class`. This CI failure shows it: https://github.com/ruby/ruby/actions/runs/11081754435/job/30793895707?pr=11… In this case, the cme had: * def->type: CFUNC * defined_class: Kernel * owner: Kernel I couldn't find the root cause of why Kernel is set on cme->owner, and why the owner is checked here. How should we fix this problem? * Just delete the VM_ASSERT() (because the cme is just to be invalidated) * Fix the root cause of the invalid&unexpected cme->owner -- https://bugs.ruby-lang.org/

4 4

[ruby-dev:52112] [Ruby master Bug#20730] LoadError if Rakefile has shebang
by watson1978 (Shizuo Fujita) 14 Sep '24

14 Sep '24

Issue #20730 has been reported by watson1978 (Shizuo Fujita). ---------------------------------------- Bug #20730: LoadError if Rakefile has shebang https://bugs.ruby-lang.org/issues/20730 * Author: watson1978 (Shizuo Fujita) * Status: Open * Target version: 3.4 * ruby -v: ruby 3.4.0dev (2024-09-12T20:03:28Z master 0fc8422a05) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- `LoadError` exception will be raised when invoke the rake task with latest ruby 3.4-dev. ### Reproduce code Here is example code. ```ruby #!/usr/bin/env rake p "Hello" ``` ### Result ``` $ ruby -v ruby 3.4.0dev (2024-09-12T20:03:28Z master 0fc8422a05) +PRISM [x86_64-linux] $ rake -f test.rake rake aborted! LoadError: no Ruby script found in input (LoadError) (See full trace by running task with --trace) ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-dev:52100] [Ruby master Bug#20675] Parse error with required kwargs and omitted parens
by matz (Yukihiro Matsumoto) 05 Sep '24

05 Sep '24

Issue #20675 has been reported by matz (Yukihiro Matsumoto). ---------------------------------------- Bug #20675: Parse error with required kwargs and omitted parens https://bugs.ruby-lang.org/issues/20675 * Author: matz (Yukihiro Matsumoto) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- As pointed out in https://github.com/mruby/mruby/issues/6268, keyword arguments without surrounding parens are a bit confusing, e.g. ```ruby def foo arg: 123 end ``` is parsed as ```ruby def foo(arg:) 123 end ``` where ```ruby k=25 f k: 10 ``` is parserd as ```ruby k=25 f(k: 10) ``` In summary, should we ignore newlines after keyword labels? Should we make them behave consistent? Matz. -- https://bugs.ruby-lang.org/

5 8

[ruby-dev:52096] [Ruby master Bug#20633] compile error at vm_insnhelper.c when HAVE_DECL_ATOMIC_SIGNAL_FENCE is 0
by kimuraw (Wataru Kimura) 02 Sep '24

02 Sep '24

Issue #20633 has been reported by kimuraw (Wataru Kimura). ---------------------------------------- Bug #20633: compile error at vm_insnhelper.c when HAVE_DECL_ATOMIC_SIGNAL_FENCE is 0 https://bugs.ruby-lang.org/issues/20633 * Author: kimuraw (Wataru Kimura) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- 木村といいます。最近導入された、vm_insnhelper.c 中での atomic_signal_fence()の呼び出し[1]が config.hで ”#define HAVE_DECL_ATOMIC_SIGNAL_FENCE 0” のときコンパイルエラーになります。おそらくコードの意図と異なると思うのでパッチ送ります。 ``` compiling array.c compiling vm.c In file included from vm.c:514: ./vm_insnhelper.c:400:5: warning: implicit declaration of function 'atomic_signal_fence' is invalid in C99 [-Wimplicit-function-declaration] atomic_signal_fence(memory_order_seq_cst); ^ ./vm_insnhelper.c:400:25: error: use of undeclared identifier 'memory_order_seq_cst' atomic_signal_fence(memory_order_seq_cst); ^ 1 warning and 1 error generated. ``` [1] Add explicit compiler fence when pushing frames to ensure safe profiling https://github.com/ruby/ruby/commit/64fef3b870a8ed8147654531aef4c065d8a730c6 ---Files-------------------------------- patch-vm_insnhelper.c.diff (535 Bytes) -- https://bugs.ruby-lang.org/

4 5