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

[ruby-core:114510] [Ruby master Bug#17543] Ractor isolation broken by `self` in shareable proc
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #17543 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed This was fixed in commit:cce331272b07636d536c8227288ab3fbcf24e2aa ---------------------------------------- Bug #17543: Ractor isolation broken by `self` in shareable proc https://bugs.ruby-lang.org/issues/17543#change-104301 * Author: marcandre (Marc-Andre Lafortune) * Status: Closed * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: 3.0.0p0 * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- Discussing with @MaxLap we realized that the `self` in a shareable proc is not properly isolated: ``` class Foo attr_accessor :x def pr Ractor.make_shareable(Proc.new { self }) end end f = Foo.new f.x = [1, 2, 3] Ractor.new(f.pr) { |pr| pr.call.x << :oops } p f.x # => [1, 2, 3, :oops] ``` If the `self` refers to a shareable object then it's fine, but for non-shareable objects it has to be reset to `nil` or to a global shareable object that would have an instructive `inspect`. ```ruby Ractor::DETACHED_SELF = Object.new def << Ractor::DETACHED_SELF def inspect '<#detached self>' end alias to_s inspect end Ractor::DETACHED_SELF.freeze ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114509] [Ruby master Bug#17531] `did_you_mean` not Ractor friendly
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #17531 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed This was fixed, did_you_mean is now Ractor-friendly: https://github.com/ruby/did_you_mean/commit/8faba54b2d3ec9aa570691775f14380… ---------------------------------------- Bug #17531: `did_you_mean` not Ractor friendly https://bugs.ruby-lang.org/issues/17531#change-104300 * Author: marcandre (Marc-Andre Lafortune) * Status: Closed * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: 3.0.0p0 * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- The gem `did_you_mean` uses a class instance variable that does not work with Ractor. ``` $ RUBYOPT='--disable-did_you_mean' ruby -W0 -e 'Ractor.new{ begin ; nil + 42; rescue Exception => e; e.to_s end}.take' # => prints nothing (ok) $ ruby -W0 -e 'Ractor.new{ begin ; nil + 42; rescue Exception => e; e.to_s end}.take' # Prints /Users/mal/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean.rb:102:in `formatter' /Users/mal/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/core_ext/name_error.rb:9:in `to_s' -e:1:in `rescue in block in <main>' -e:1:in `block in <main>' # (not ok) ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114508] [Ruby master Bug#17478] Ruby3.0 is slower than Ruby2.7.2 when parsing a large CSV file
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #17478 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Assigned to Closed I did some testing with the CSV example given in the original post repeated 400k times. Note that Ruby 2.7 ships with CSV 3.1.2 and Ruby 3.2 ships with CSV 3.2.6. * 2.7: 49 seconds * 3.2: 77 seconds * 3.2 --yjit: 59 seconds * 3.2 with CSV 3.1.2: 48 seconds * 3.2 --yjit with CSV 3.1.2: 33 seconds Since the performance issue is in the `csv` library, and not in Ruby itself, I'm closing this. You may want to bisect changes to the `csv` library between 3.1.2 and 3.2.6, and if you identify an unnecessary performance regression, file an issue upstream: https://github.com/ruby/csv/issues . Alternatively, just use CSV 3.1.2 if performance is an issue and you don't need features added since. ---------------------------------------- Bug #17478: Ruby3.0 is slower than Ruby2.7.2 when parsing a large CSV file https://bugs.ruby-lang.org/issues/17478#change-104297 * Author: okkez (okkez _) * Status: Closed * Priority: Normal * Assignee: kou (Kouhei Sutou) * ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- Ruby3.0 is around 10%-20% slower than Ruby2.7.2 when parsing and aggregating a large CSV file. The script is here: ```ruby require "csv" name_to_cost = Hash.new(0) CSV.foreach(ARGV[0], headers: true) do |row| name_to_cost[row["name"]] += row["cost"].to_f end name_to_cost.sort_by {|k, _| k }.each do |name, cost| printf "%s\t%.3f\n", name, cost end ``` The sample data is like following(3 mega lines and the size is about 235MiB): ``` id,name,description,cost 2365599605,ysgHDPA,Voluptatem sit perferendis accusantium consequatur aut.,25.115 2365599606,xFLXOtJ,Sit accusantium aut perferendis voluptatem consequatur.,60.228 2365599607,RlkxNQB,Accusantium sit aut consequatur perferendis voluptatem.,79.663 2365599608,YVMbuva,Sit perferendis voluptatem accusantium aut consequatur.,49.863 2365599609,rtxVcDW,Accusantium voluptatem sit perferendis aut consequatur.,50.765 2365599610,rtxVcDW,Aut sit accusantium consequatur perferendis voluptatem.,94.310 2365599611,muDwuke,Consequatur sit accusantium aut perferendis voluptatem.,16.991 2365599612,tkqFWyM,Perferendis sit voluptatem consequatur aut accusantium.,98.753 ``` * Ruby2.7.2: 25.37 seconds * Ruby3.0.0: 27.53 seconds I use this program to generate the test CSV file: https://gist.github.com/okkez/05ffa0df08cf49014f460eb2e8543698 In case of using another private data: * Ruby2.7.2: 31.54 seconds * Ruby3.0.0: 37.15 seconds The private data is like followings: * There are 18 columns * There are 1144305 lines * It is 334MiB -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114505] [Ruby master Bug#17383] 3.0 recursion memory|speed issues
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #17383 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed I tested the example: * 2.7: 1178 seconds * 3.2: 1315 seconds * 3.2 --yjit: 1012 seconds 3.2 with --yjit is ~15% faster than 2.7, so whatever performance has been lost since 2.7 has been more than regained by --yjit. ---------------------------------------- Bug #17383: 3.0 recursion memory|speed issues https://bugs.ruby-lang.org/issues/17383#change-104294 * Author: jzakiya (Jabari Zakiya) * Status: Closed * Priority: Normal * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- Testing 3.0.0-preview2 against 2.7.2 I see it's still not as performant to 2.7.2 for the following code. Below is code from Rosettacode.org https://rosettacode.org/wiki/Palindromic_gapful_numbers#Orders_of_Magnitude… This is run on an I7, 3.5GHz, 16GB, Linux 5.9.10 laptop. Using rvm, 2.7.2 uses at max ~50% of memory worst case, but for 3.0.0pre2 it hits ~70%. It's also faster on 2.7.2 than 3.0.0-pre2 ``` class PalNo def initialize(digit) @digit, @l, @dd = digit, 3, 11*digit end def fN(n) return [0,1,2,3,4,5,6,7,8,9] if n==1 return [0,11,22,33,44,55,66,77,88,99] if n==2 a=[]; [0,1,2,3,4,5,6,7,8,9].product(fN(n-2)).each{ |g| a << g[0]*10**(n-1)+g[0]+10*g[1] }; return a end def show(count, keep) to_skip, palcnt, pals = count - keep, 0, [] while palcnt < count fN((a)l-2).each{ |g| pal=@digit*10**(@l-1)+@digit+10*g; pals << pal if pal%(@dd)==0 && (palcnt += 1) > to_skip; break if palcnt - to_skip == keep }; @l+=1 end print pals; puts end end start = Time.now (1..9).each { |digit| PalNo.new(digit).show(20, 20) }; puts "####" (1..9).each { |digit| PalNo.new(digit).show(100, 15) }; puts "####" (1..9).each { |digit| PalNo.new(digit).show(1000, 10) }; puts "####" (1..9).each { |digit| PalNo.new(digit).show(100_000, 1) }; puts "####" (1..9).each { |digit| PalNo.new(digit).show(1_000_000, 1) }; puts "####" (1..9).each { |digit| PalNo.new(digit).show(10_000_000, 1) }; puts "####" puts (Time.now - start) ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114495] [Ruby master Bug#19848] Ripper BOM behavior
by kddnewton (Kevin Newton) 24 Aug '23

24 Aug '23

Issue #19848 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #19848: Ripper BOM behavior https://bugs.ruby-lang.org/issues/19848 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When there is a byte-order mark in a file, the first token in the file usually begins at -3. For example: ```ruby Ripper.lex("\xEF\xBB\xBF[]") # => [[[1, -3], :on_lbracket, "[", BEG|LABEL], [[1, 1], :on_rbracket, "]", END]] ``` The rest of the tokens appear as if the byte-order-mark never existed. This is consistent except for the case where the file starts with a global variable, an instance variable, or a class variable. In those cases the first token begins at 0. For example: ```ruby Ripper.lex("\xEF\xBB\xBF@foo") # => [[[1, 0], :on_ivar, "@foo", END]] Ripper.lex("\xEF\xBB\xBF@@foo") # => [[[1, 0], :on_cvar, "@@foo", END]] Ripper.lex("\xEF\xBB\xBF$foo") # => [[[1, 0], :on_gvar, "$foo", END]] ``` Additionally, when there is a byte-order mark it usually does not appear as part of the first token, unless the token is a magic encoding comment. If it's a magic encoding comment, then it's part of the value: ```ruby Ripper.lex("\xEF\xBB\xBF# encoding: us-ascii") # => [[[1, -3], :on_comment, "\xEF\xBB\xBF# encoding: us-ascii", BEG]] ``` For solutions - when there is a byte-order mark I think the column information should either always start at 0, or always start at -3. Then for the encoding comment, it should probably not show up as part of the value, or it should show up for all comments. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:114502] [Ruby master Bug#17373] Ruby 3.0 is slower at Discourse bench than Ruby 2.7
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #17373 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed It looks like the slowdown for refined methods was fixed by @ko1 in commit:cfd7729ce7a31c8b6ec5dd0e99c67b2932de4732. Even without that, I'm guessing with yjit, Ruby 3.2 is now faster than Ruby 2.6/2.7. If that is not the case, please reopen with details. ---------------------------------------- Bug #17373: Ruby 3.0 is slower at Discourse bench than Ruby 2.7 https://bugs.ruby-lang.org/issues/17373#change-104290 * Author: sam.saffron (Sam Saffron) * Status: Closed * Priority: Normal * ruby -v: 3.0 * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- We have a continuous effort to keep https://rubybench.org/ up to date. Unfortunately we have lapsed a bit on updates so I decided to run Discourse bench by hand. On my local system I am noticing the timing are much slower on Discourse bench than they were on Ruby 2.7: ``` 98c9120cc00ba691b4abcc13a49a30fa54638535 --- categories: 50: 34 75: 35 90: 36 99: 40 home: 50: 47 75: 50 90: 56 99: 92 topic: 50: 53 75: 55 90: 58 99: 92 categories_admin: 50: 33 75: 34 90: 38 99: 68 home_admin: 50: 45 75: 47 90: 51 99: 95 topic_admin: 50: 51 75: 52 90: 54 99: 59 timings: load_rails: 1449 ruby-version: 3.0.0-p-1 rss_kb: 293808 pss_kb: 284244 2.7.2 --- categories: 50: 29 75: 30 90: 33 99: 43 home: 50: 42 75: 43 90: 47 99: 73 topic: 50: 47 75: 47 90: 52 99: 54 categories_admin: 50: 30 75: 31 90: 36 99: 56 home_admin: 50: 41 75: 43 90: 48 99: 71 topic_admin: 50: 47 75: 48 90: 52 99: 55 timings: load_rails: 1339 ruby-version: 2.7.2-p137 rss_kb: 296836 pss_kb: 287310 2.6.6 --- categories: 50: 30 75: 30 90: 31 99: 51 home: 50: 40 75: 42 90: 60 99: 79 topic: 50: 47 75: 48 90: 53 99: 71 categories_admin: 50: 30 75: 31 90: 35 99: 50 home_admin: 50: 41 75: 43 90: 62 99: 100 topic_admin: 50: 48 75: 49 90: 65 99: 93 timings: load_rails: 1464 ruby-version: 2.6.6-p146 rss_kb: 332268 pss_kb: 322865 ``` Concretely this means a typical "homepage" view is taking 47 milliseconds now, when in the past it was taking 42 or even 40 ms. There may be some issues with the bench, you can see it here: https://github.com/discourse/discourse/tree/ruby-3 The script to run the bench is `ruby script/bench.rb` I re-tested against a cleanly built Ruby 2.7 direct from the Git branch to ensure compilation was not at fault. This is pretty concerning, Discourse bench usually tracks Rails performance pretty accurately. ---Files-------------------------------- aaron — perf _home_aaron_git_railsbench — ssh whiteclaw.local — 175×54 2020-12-07 12-41-12.png (842 KB) aaron — perf _home_aaron_git_railsbench — ssh whiteclaw.local — 175×54 2020-12-07 12-41-58.png (874 KB) aaron — perf _home_aaron_git_railsbench — ssh whiteclaw.local — 299×65 2020-12-07 13-19-20.png (142 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114500] [Ruby master Bug#17289] Time#strftime occurs Segmentation Fault on ruby-2.7.2p137
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #17289 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Assigned to Feedback @joker1007 Can you reproduce this issue with Ruby 3.2 or the master branch? Can you reproduce this issue without the strptime gem? ---------------------------------------- Bug #17289: Time#strftime occurs Segmentation Fault on ruby-2.7.2p137 https://bugs.ruby-lang.org/issues/17289#change-104288 * Author: joker1007 (Tomohiro Hashidate) * Status: Feedback * Priority: Normal * Assignee: shyouhei (Shyouhei Urabe) * ruby -v: ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: REQUIRED ---------------------------------------- Segmentation Fault occurred when I run Time#strftime via Time#iso8601 on ruby-2.7.2. It occurs repeatedly about once a day in our system. Because it was not possible to make a reproduction case in a simple environment, I share the C Level backtrace and the control frame information at the time of occurrence. Also, I used strptime gem (https://github.com/nurse/strptime) to create the Time object. Ruby version: ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux] ``` /opt/ruby/lib/ruby/2.7.0/time.rb:732: [BUG] Segmentation fault at 0x0000000077359419 ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0065 p:---- s:0380 e:000379 CFUNC :* c:0064 p:---- s:0377 e:000376 CFUNC :strftime c:0063 p:0014 s:0372 e:000371 METHOD /opt/ruby/lib/ruby/2.7.0/time.rb:732 ``` ``` -- C level backtrace information ------------------------------------------- /opt/ruby/lib/libruby.so.2.7(rb_vm_bugreport+0x54c) [0x7fc11890cf5c] vm_dump.c:755 /opt/ruby/lib/libruby.so.2.7(rb_bug_for_fatal_signal+0xe7) [0x7fc11873c937] error.c:660 /opt/ruby/lib/libruby.so.2.7(sigsegv+0x4b) [0x7fc1188732ab] signal.c:946 /lib/x86_64-linux-gnu/libpthread.so.0(__restore_rt+0x0) [0x7fc1182500e0] /opt/ruby/lib/libruby.so.2.7(rb_rational_mul+0x40) [0x7fc1188370b0] rational.c:898 /opt/ruby/lib/libruby.so.2.7(vm_call0_cfunc_with_frame+0x10a) [0x7fc1188fe790] vm_eval.c:91 /opt/ruby/lib/libruby.so.2.7(vm_call0_cfunc) vm_eval.c:105 /opt/ruby/lib/libruby.so.2.7(vm_call0_body) vm_eval.c:140 /opt/ruby/lib/libruby.so.2.7(rb_funcallv_with_cc+0xdb) [0x7fc11890157b] vm_eval.c:1013 /opt/ruby/lib/libruby.so.2.7(mulv+0x50) [0x7fc1188bbf50] time.c:116 /opt/ruby/lib/libruby.so.2.7(timew_out_of_timet_range+0x1c) [0x7fc1188c2ef4] time.c:1664 /opt/ruby/lib/libruby.so.2.7(localtimew) time.c:1677 /opt/ruby/lib/libruby.so.2.7(time_localtime+0x61) [0x7fc1188c3411] time.c:3816 /opt/ruby/lib/libruby.so.2.7(time_strftime+0x7b) [0x7fc1188c53eb] time.c:5076 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc_with_frame+0xcf) [0x7fc1188e95a6] vm_insnhelper.c:2514 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc) vm_insnhelper.c:2539 /opt/ruby/lib/libruby.so.2.7(vm_sendish+0xa3) [0x7fc1188f55a7] vm_insnhelper.c:4023 /opt/ruby/lib/libruby.so.2.7(vm_exec_core) insns.def:801 /opt/ruby/lib/libruby.so.2.7(rb_vm_exec+0xab) [0x7fc1188fb6fb] vm.c:1920 /opt/ruby/lib/libruby.so.2.7(invoke_block+0x167) [0x7fc1189069d3] vm.c:1044 /opt/ruby/lib/libruby.so.2.7(invoke_iseq_block_from_c) vm.c:1116 /opt/ruby/lib/libruby.so.2.7(invoke_block_from_c_bh) vm.c:1134 /opt/ruby/lib/libruby.so.2.7(vm_yield) vm.c:1179 /opt/ruby/lib/libruby.so.2.7(rb_yield_0) vm_eval.c:1227 /opt/ruby/lib/libruby.so.2.7(rb_yield_1) vm_eval.c:1233 /opt/ruby/lib/libruby.so.2.7(int_dotimes+0x50) [0x7fc1187d8ac0] numeric.c:5201 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc_with_frame+0xcf) [0x7fc1188e95a6] vm_insnhelper.c:2514 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc) vm_insnhelper.c:2539 /opt/ruby/lib/libruby.so.2.7(vm_sendish+0x56) [0x7fc1188f6ab5] vm_insnhelper.c:4023 /opt/ruby/lib/libruby.so.2.7(vm_exec_core) insns.def:782 /opt/ruby/lib/libruby.so.2.7(rb_vm_exec+0x898) [0x7fc1188fbee8] vm.c:1929 /opt/ruby/lib/libruby.so.2.7(invoke_block+0x166) [0x7fc118906e19] vm.c:1044 /opt/ruby/lib/libruby.so.2.7(invoke_iseq_block_from_c) vm.c:1116 /opt/ruby/lib/libruby.so.2.7(invoke_block_from_c_bh) vm.c:1134 /opt/ruby/lib/libruby.so.2.7(vm_yield) vm.c:1179 /opt/ruby/lib/libruby.so.2.7(rb_yield_0) vm_eval.c:1227 /opt/ruby/lib/libruby.so.2.7(rb_yield_1) vm_eval.c:1233 /opt/ruby/lib/libruby.so.2.7(rb_yield) vm_eval.c:1243 /opt/ruby/lib/libruby.so.2.7(rb_array_len+0x0) [0x7fc1186ac63c] array.c:2135 /opt/ruby/lib/libruby.so.2.7(rb_ary_each) array.c:2134 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc_with_frame+0xcf) [0x7fc1188e95a6] vm_insnhelper.c:2514 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc) vm_insnhelper.c:2539 /opt/ruby/lib/libruby.so.2.7(vm_sendish+0x56) [0x7fc1188f6ab5] vm_insnhelper.c:4023 /opt/ruby/lib/libruby.so.2.7(vm_exec_core) insns.def:782 /opt/ruby/lib/libruby.so.2.7(rb_vm_exec+0xab) [0x7fc1188fb6fb] vm.c:1920 /opt/ruby/lib/libruby.so.2.7(invoke_block+0x167) [0x7fc118906593] vm.c:1044 /opt/ruby/lib/libruby.so.2.7(invoke_iseq_block_from_c) vm.c:1116 /opt/ruby/lib/libruby.so.2.7(invoke_block_from_c_bh) vm.c:1134 /opt/ruby/lib/libruby.so.2.7(vm_yield) vm.c:1179 /opt/ruby/lib/libruby.so.2.7(rb_yield_0) vm_eval.c:1227 /opt/ruby/lib/libruby.so.2.7(catch_i) vm_eval.c:2228 /opt/ruby/lib/libruby.so.2.7(vm_catch_protect+0xb1) [0x7fc1188eebe1] vm_eval.c:2310 /opt/ruby/lib/libruby.so.2.7(rb_catch_obj+0x2c) [0x7fc1188eecec] vm_eval.c:2336 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc_with_frame+0xcf) [0x7fc1188e95a6] vm_insnhelper.c:2514 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc) vm_insnhelper.c:2539 /opt/ruby/lib/libruby.so.2.7(vm_sendish+0x56) [0x7fc1188f6ab5] vm_insnhelper.c:4023 /opt/ruby/lib/libruby.so.2.7(vm_exec_core) insns.def:782 /opt/ruby/lib/libruby.so.2.7(rb_vm_exec+0xab) [0x7fc1188fb6fb] vm.c:1920 /opt/ruby/lib/libruby.so.2.7(invoke_block+0x166) [0x7fc118906e19] vm.c:1044 /opt/ruby/lib/libruby.so.2.7(invoke_iseq_block_from_c) vm.c:1116 /opt/ruby/lib/libruby.so.2.7(invoke_block_from_c_bh) vm.c:1134 /opt/ruby/lib/libruby.so.2.7(vm_yield) vm.c:1179 /opt/ruby/lib/libruby.so.2.7(rb_yield_0) vm_eval.c:1227 /opt/ruby/lib/libruby.so.2.7(rb_yield_1) vm_eval.c:1233 /opt/ruby/lib/libruby.so.2.7(rb_yield) vm_eval.c:1243 /opt/ruby/lib/libruby.so.2.7(rb_array_len+0x0) [0x7fc1186ac63c] array.c:2135 /opt/ruby/lib/libruby.so.2.7(rb_ary_each) array.c:2134 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc_with_frame+0xcf) [0x7fc1188e95a6] vm_insnhelper.c:2514 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc) vm_insnhelper.c:2539 /opt/ruby/lib/libruby.so.2.7(vm_sendish+0x56) [0x7fc1188f6ab5] vm_insnhelper.c:4023 /opt/ruby/lib/libruby.so.2.7(vm_exec_core) insns.def:782 /opt/ruby/lib/libruby.so.2.7(rb_vm_exec+0xab) [0x7fc1188fb6fb] vm.c:1920 /opt/ruby/lib/libruby.so.2.7(invoke_block+0x167) [0x7fc118906593] vm.c:1044 /opt/ruby/lib/libruby.so.2.7(invoke_iseq_block_from_c) vm.c:1116 /opt/ruby/lib/libruby.so.2.7(invoke_block_from_c_bh) vm.c:1134 /opt/ruby/lib/libruby.so.2.7(vm_yield) vm.c:1179 /opt/ruby/lib/libruby.so.2.7(rb_yield_0) vm_eval.c:1227 /opt/ruby/lib/libruby.so.2.7(catch_i) vm_eval.c:2228 /opt/ruby/lib/libruby.so.2.7(vm_catch_protect+0xb1) [0x7fc1188eebe1] vm_eval.c:2310 /opt/ruby/lib/libruby.so.2.7(rb_catch_obj+0x2c) [0x7fc1188eecec] vm_eval.c:2336 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc_with_frame+0xcf) [0x7fc1188e95a6] vm_insnhelper.c:2514 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc) vm_insnhelper.c:2539 /opt/ruby/lib/libruby.so.2.7(vm_sendish+0x56) [0x7fc1188f6ab5] vm_insnhelper.c:4023 /opt/ruby/lib/libruby.so.2.7(vm_exec_core) insns.def:782 /opt/ruby/lib/libruby.so.2.7(rb_vm_exec+0x898) [0x7fc1188fbee8] vm.c:1929 /opt/ruby/lib/libruby.so.2.7(invoke_block+0x16d) [0x7fc118905d82] vm.c:1044 /opt/ruby/lib/libruby.so.2.7(invoke_iseq_block_from_c) vm.c:1116 /opt/ruby/lib/libruby.so.2.7(invoke_block_from_c_bh) vm.c:1134 /opt/ruby/lib/libruby.so.2.7(vm_yield) vm.c:1179 /opt/ruby/lib/libruby.so.2.7(rb_yield_0) vm_eval.c:1227 /opt/ruby/lib/libruby.so.2.7(loop_i) vm_eval.c:1330 /opt/ruby/lib/libruby.so.2.7(rb_vrescue2+0xd4) [0x7fc118747064] eval.c:990 /opt/ruby/lib/libruby.so.2.7(rb_rescue2+0x8a) [0x7fc11874725a] eval.c:967 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc_with_frame+0xcf) [0x7fc1188e95a6] vm_insnhelper.c:2514 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc) vm_insnhelper.c:2539 /opt/ruby/lib/libruby.so.2.7(vm_sendish+0x56) [0x7fc1188f6ab5] vm_insnhelper.c:4023 /opt/ruby/lib/libruby.so.2.7(vm_exec_core) insns.def:782 /opt/ruby/lib/libruby.so.2.7(rb_vm_exec+0xab) [0x7fc1188fb6fb] vm.c:1920 /opt/ruby/lib/libruby.so.2.7(invoke_block+0x167) [0x7fc118906593] vm.c:1044 /opt/ruby/lib/libruby.so.2.7(invoke_iseq_block_from_c) vm.c:1116 /opt/ruby/lib/libruby.so.2.7(invoke_block_from_c_bh) vm.c:1134 /opt/ruby/lib/libruby.so.2.7(vm_yield) vm.c:1179 /opt/ruby/lib/libruby.so.2.7(rb_yield_0) vm_eval.c:1227 /opt/ruby/lib/libruby.so.2.7(catch_i) vm_eval.c:2228 /opt/ruby/lib/libruby.so.2.7(vm_catch_protect+0xb1) [0x7fc1188eebe1] vm_eval.c:2310 /opt/ruby/lib/libruby.so.2.7(rb_catch_obj+0x2c) [0x7fc1188eecec] vm_eval.c:2336 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc_with_frame+0xcf) [0x7fc1188e95a6] vm_insnhelper.c:2514 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc) vm_insnhelper.c:2539 /opt/ruby/lib/libruby.so.2.7(vm_sendish+0x56) [0x7fc1188f6ab5] vm_insnhelper.c:4023 /opt/ruby/lib/libruby.so.2.7(vm_exec_core) insns.def:782 /opt/ruby/lib/libruby.so.2.7(rb_vm_exec+0xab) [0x7fc1188fb6fb] vm.c:1920 /opt/ruby/lib/libruby.so.2.7(invoke_iseq_block_from_c+0x7c) [0x7fc118907076] vm.c:1116 /opt/ruby/lib/libruby.so.2.7(invoke_block_from_c_bh) vm.c:1134 /opt/ruby/lib/libruby.so.2.7(vm_yield) vm.c:1179 /opt/ruby/lib/libruby.so.2.7(rb_yield_0) vm_eval.c:1227 /opt/ruby/lib/libruby.so.2.7(rb_yield) vm_eval.c:1240 /opt/ruby/lib/libruby.so.2.7(rb_protect+0x158) [0x7fc1187473f8] eval.c:1087 /opt/ruby/lib/libruby.so.2.7(rb_f_fork+0x7f) [0x7fc11882697f] process.c:4129 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc_with_frame+0xcf) [0x7fc1188e95a6] vm_insnhelper.c:2514 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc) vm_insnhelper.c:2539 /opt/ruby/lib/libruby.so.2.7(vm_sendish+0x56) [0x7fc1188f6ab5] vm_insnhelper.c:4023 /opt/ruby/lib/libruby.so.2.7(vm_exec_core) insns.def:782 /opt/ruby/lib/libruby.so.2.7(rb_vm_exec+0xab) [0x7fc1188fb6fb] vm.c:1920 /opt/ruby/lib/libruby.so.2.7(invoke_block_from_c_bh+0x2bc) [0x7fc1188fc51c] vm.c:1116 /opt/ruby/lib/libruby.so.2.7(rb_yield_values2+0x56) [0x7fc1188fcd76] vm.c:1179 /opt/ruby/lib/libruby.so.2.7(each_with_index_i+0x6a) [0x7fc11872ce1a] enum.c:2365 /opt/ruby/lib/libruby.so.2.7(vm_yield_with_cfunc+0x115) [0x7fc1188f1b15] vm_insnhelper.c:3220 /opt/ruby/lib/libruby.so.2.7(invoke_block_from_c_bh+0x2c) [0x7fc118906eec] vm.c:1139 /opt/ruby/lib/libruby.so.2.7(vm_yield) vm.c:1179 /opt/ruby/lib/libruby.so.2.7(rb_yield_0) vm_eval.c:1227 /opt/ruby/lib/libruby.so.2.7(rb_yield_1) vm_eval.c:1233 /opt/ruby/lib/libruby.so.2.7(rb_yield) vm_eval.c:1243 /opt/ruby/lib/libruby.so.2.7(rb_array_len+0x0) [0x7fc1186ac63c] array.c:2135 /opt/ruby/lib/libruby.so.2.7(rb_ary_each) array.c:2134 /opt/ruby/lib/libruby.so.2.7(vm_call0_cfunc_with_frame+0x10a) [0x7fc1188fe790] vm_eval.c:91 /opt/ruby/lib/libruby.so.2.7(vm_call0_cfunc) vm_eval.c:105 /opt/ruby/lib/libruby.so.2.7(vm_call0_body) vm_eval.c:140 /opt/ruby/lib/libruby.so.2.7(rb_vm_call0+0xe6) [0x7fc1188fee36] vm_eval.c:52 /opt/ruby/lib/libruby.so.2.7(rb_vm_call_kw+0x6d) [0x7fc1188ff0ed] vm_eval.c:268 /opt/ruby/lib/libruby.so.2.7(iterate_method+0x39) [0x7fc1189001b9] vm_eval.c:718 /opt/ruby/lib/libruby.so.2.7(rb_iterate0+0xd5) [0x7fc1188ee7b5] vm_eval.c:1415 /opt/ruby/lib/libruby.so.2.7(rb_block_call+0x43) [0x7fc1188ee953] vm_eval.c:1480 /opt/ruby/lib/libruby.so.2.7(enum_each_with_index+0x44) [0x7fc1187261f4] enum.c:2395 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc_with_frame+0xcf) [0x7fc1188e95a6] vm_insnhelper.c:2514 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc) vm_insnhelper.c:2539 /opt/ruby/lib/libruby.so.2.7(vm_call_method+0x10a) [0x7fc11890442a] vm_insnhelper.c:3053 /opt/ruby/lib/libruby.so.2.7(vm_sendish+0x56) [0x7fc1188f6ab5] vm_insnhelper.c:4023 /opt/ruby/lib/libruby.so.2.7(vm_exec_core) insns.def:782 /opt/ruby/lib/libruby.so.2.7(rb_vm_exec+0x898) [0x7fc1188fbee8] vm.c:1929 /opt/ruby/lib/libruby.so.2.7(raise_load_if_failed+0x0) [0x7fc11879dc53] load.c:585 /opt/ruby/lib/libruby.so.2.7(rb_load_internal) load.c:645 /opt/ruby/lib/libruby.so.2.7(rb_f_load) load.c:701 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc_with_frame+0xcf) [0x7fc1188e95a6] vm_insnhelper.c:2514 /opt/ruby/lib/libruby.so.2.7(vm_call_cfunc) vm_insnhelper.c:2539 /opt/ruby/lib/libruby.so.2.7(vm_call_method+0x10a) [0x7fc11890442a] vm_insnhelper.c:3053 /opt/ruby/lib/libruby.so.2.7(vm_sendish+0xa3) [0x7fc1188f55a7] vm_insnhelper.c:4023 /opt/ruby/lib/libruby.so.2.7(vm_exec_core) insns.def:801 /opt/ruby/lib/libruby.so.2.7(rb_vm_exec+0xab) [0x7fc1188fb6fb] vm.c:1920 /opt/ruby/lib/libruby.so.2.7(rb_ec_exec_node+0xaa) [0x7fc118743bea] eval.c:278 /opt/ruby/lib/libruby.so.2.7(ruby_run_node+0x49) [0x7fc118749549] eval.c:336 /opt/ruby/bin/ruby(main+0x5b) [0x55cb7cb329db] ./main.c:50 ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114498] [Ruby master Bug#18622] const_get still looks in Object, while lexical constant lookup no longer does
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #18622 has been updated by jeremyevans0 (Jeremy Evans). @matz This was reviewed during the June 2023 developer meeting and is still waiting for your response: https://github.com/ruby/dev-meeting-log/blob/master/2023/DevMeeting-2023-06… ---------------------------------------- Bug #18622: const_get still looks in Object, while lexical constant lookup no longer does https://bugs.ruby-lang.org/issues/18622#change-104283 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * ruby -v: ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- There is some inconsistency here between literal constant lookup and the meta API (const_get). Lexical constant lookup no longer uses a special case for Object, and this is good as it avoids surprises: #11547 However, `const_get` still looks in Object, even though that's confusing, inconsistent and IMHO shouldn't really happen. ```ruby module ConstantSpecsTwo Foo = :cs_two_foo end module ConstantSpecs end p ConstantSpecs.const_get("ConstantSpecsTwo::Foo") # => :cs_two_foo p ConstantSpecs::ConstantSpecsTwo::Foo # => const_get.rb:9:in `<main>': uninitialized constant ConstantSpecs::ConstantSpecsTwo (NameError) ``` I think we should change it so both behave the same (i.e., NameError). It's like if `cd /foo/bar` would go to `/bar` if `/foo/bar` does not exist and `/bar` does. `const_get` is a meta API so it cannot know the surrounding `Module.nesting`, but so I think it should consider the receiver of `const_get` as the only nesting (so just `ConstantSpecs` in this case, not `Object`). Note this does not affect nested constants inside the `const_get` like `Foo` above (another way to look at the inconsistency that the first component is treated differently). From https://bugs.ruby-lang.org/issues/11547#note-19 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114497] [Ruby master Bug#16920] TestThread#test_signal_at_join fails on aarch64
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #16920 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed I reviewed every recent RubyCI arm/aarch64 failure, and this test did not fail in any of them. So failures must be rare. I'm going to close this. If this is still an issue and someone can come up with a reproducible test case, that would be appreciated. ---------------------------------------- Bug #16920: TestThread#test_signal_at_join fails on aarch64 https://bugs.ruby-lang.org/issues/16920#change-104282 * Author: jaruga (Jun Aruga) * Status: Closed * Priority: Normal * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- I observed the following error on Ruby 2.7.1 building in Fedora aarch64 CI. It was just one time error. It does not always happen. ``` 1) Error: TestThread#test_signal_at_join: Timeout::Error: execution of assert_separately expired timeout (120 sec) pid 2314088 killed by SIGABRT (signal 6) (core dumped) | /builddir/build/BUILD/ruby-2.7.1/test/ruby/test_thread.rb:1346:in `test_signal_at_join' Finished tests in 1379.712832s, 15.2372 tests/s, 1972.9127 assertions/s. ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114491] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by ioquatix (Samuel Williams) 24 Aug '23

24 Aug '23

Issue #19057 has been updated by ioquatix (Samuel Williams). - `cool.io` has since been fixed and released. - `unicorn` has merged a fix but it is not released: https://yhbt.net/unicorn.git/63c85c4282d15e22bd32a905883d2d0e149619d1/s/ - `kgio` has a patch submitted. ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-104276 * Author: ioquatix (Samuel Williams) * Status: Assigned * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Target version: 3.3 ---------------------------------------- In order to make improvements to the IO implementation like <https://bugs.ruby-lang.org/issues/18455>, we need to add new fields to `struct rb_io_t`. By the way, ending types in `_t` is not recommended by POSIX, so I'm also trying to rename the internal implementation to drop `_t` where possible during this conversion. Anyway, we should try to hide the implementation of `struct rb_io`. Ideally, we don't expose any of it, but the problem is backwards compatibility. So, in order to remain backwards compatibility, we should expose some fields of `struct rb_io`, the most commonly used one is `fd` and `mode`, but several others are commonly used. There are many fields which should not be exposed because they are implementation details. ## Current proposal The current proposed change <https://github.com/ruby/ruby/pull/6511> creates two structs: ```c // include/ruby/io.h #ifndef RB_IO_T struct rb_io { int fd; // ... public fields ... }; #else struct rb_io; #endif // internal/io.h #define RB_IO_T struct rb_io { int fd; // ... public fields ... // ... private fields ... }; ``` However, we are not 100% confident this is safe according to the C specification. My experience is not sufficiently wide to say this is safe in practice, but it does look okay to both myself, and @Eregon + @tenderlovemaking have both given some kind of approval. That being said, maybe it's not safe. There are two alternatives: ## Hide all details We can make public `struct rb_io` completely invisible. ```c // include/ruby/io.h #define RB_IO_HIDDEN struct rb_io; int rb_ioptr_descriptor(struct rb_io *ioptr); // accessor for previously visible state. // internal/io.h struct rb_io { // ... all fields ... }; ``` This would only be forwards compatible, and code would need to feature detect like this: ```c #ifdef RB_IO_HIDDEN #define RB_IOPTR_DESCRIPTOR rb_ioptr_descriptor #else #define RB_IOPTR_DESCRIPTOR(ioptr) rb_ioptr_descriptor(ioptr) #endif ``` ## Nested public interface Alternatively, we can nest the public fields into the private struct: ```c // include/ruby/io.h struct rb_io_public { int fd; // ... public fields ... }; // internal/io.h #define RB_IO_T struct rb_io { struct rb_io_public public; // ... private fields ... }; ``` ## Considerations I personally think the "Hide all details" implementation is the best, but it's also the lest compatible. This is also what we are ultimately aiming for, whether we decide to take an intermediate "compatibility step" is up to us. I think "Nested public interface" is messy and introduces more complexity, but it might be slightly better defined than the "Current proposal" which might create undefined behaviour. That being said, all the tests are passing. -- https://bugs.ruby-lang.org/

1 0