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

[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

[ruby-core:114248] [Ruby master Feature#19777] Make `Kernel#lambda` raise when called without a literal block
by alanwu (Alan Wu) 24 Aug '23

24 Aug '23

Issue #19777 has been reported by alanwu (Alan Wu). ---------------------------------------- Feature #19777: Make `Kernel#lambda` raise when called without a literal block https://bugs.ruby-lang.org/issues/19777 * Author: alanwu (Alan Wu) * Status: Open * Priority: Normal ---------------------------------------- Since 3.0.0, released in 2020, calling `Kernel#lambda` without a literal block has been issuing a deprecation warning: ```ruby Warning[:deprecated] = true def foo(&b) lambda(&b) end foo {} # => test.rb:2: warning: lambda without a literal block is deprecated; use the proc without lambda instead ``` I think enough time has passed and we should make it raise in all situations where it currently issues a deprecation warning. The original decision to deprecate is here: https://bugs.ruby-lang.org/issues/15973#note-46 The new behavior allows one to predict whether `Kernel#lambda` will return by inspecting its direct caller, checking whether the call site has a literal block. It will remove some hard-to-predict cases where `Kernel#lambda` receives a non-literal block forwarded with `super` or `rb_funcall_passing_block`. The method will always return a lambda, if it returns. However, note that `send` will be a special exception in this new model: ```ruby Warning[:deprecated] = true singleton_class.send(:public, :lambda) p (send(:lambda) {}).lambda? # => true without warning p (public_send(:lambda) {}).lambda? # => true with warning, would raise instead ``` This newer model is friendlier to some optimization we're investigating for YJIT as it has fewer moving parts. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:114340] [Ruby master Bug#19829] Enumerator.product called with keyword arguments raises exception with not precise message
by andrykonchin (Andrew Konchin) 24 Aug '23

24 Aug '23

Issue #19829 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #19829: Enumerator.product called with keyword arguments raises exception with not precise message https://bugs.ruby-lang.org/issues/19829 * Author: andrykonchin (Andrew Konchin) * Status: Open * Priority: Normal * ruby -v: 3.2.1 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The `Enumerator.product` method, added in Ruby 3.2, when it's called with keyword arguments (but it expects only a list of enums) raises `unknown keyword: ... (ArgumentError)` exception: ```ruby Enumerator.product([], a: 1) # (irb):1:in `product': unknown keyword: :a (ArgumentError) ``` But AFAIK `unknown keyword` is used when a method expects keyword arguments and some not supported keyword arguments were passed. So I would expect raising exception with `no keywords accepted (ArgumentError)` message instead that states clearly that no keywords should be passed. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:113954] [Ruby master Misc#19740] Block taking methods can't differentiate between a non-local return and a throw
by byroot (Jean Boussier) 24 Aug '23

24 Aug '23

Issue #19740 has been reported by byroot (Jean Boussier). ---------------------------------------- Misc #19740: Block taking methods can't differentiate between a non-local return and a throw https://bugs.ruby-lang.org/issues/19740 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- Opening this as Misc, as at this stage I don't have a fully formed feature request. Ref: https://github.com/ruby/ruby/commit/1a3bcf103c582b20e9ea70dfed0ee68b24243f55 Ref: https://github.com/ruby/timeout/pull/30 Ref: https://github.com/rails/rails/pull/29333 ### Context Rails has this problem in the Active Record transaction API. The way it works is that it yields to a block, and if no error was raised the SQL transaction is committed, otherwise it's rolled back: ```ruby User.transaction do do_thing end # COMMIT ``` or ```ruby User.transaction do raise SomeError end # ROLLBACK ``` The problem is that there are more ways a method can be exited: ```ruby User.transaction do return # non-local exit end ``` ```ruby User.transaction do throw :something end ``` In the case of a non-local return, we'd want to commit the transaction, but in the case of a throw, particularly since it's internally used by `Timeout.timeout` since Ruby 2.1, we'd rather consider that an error and rollback. But as far as I'm aware, there is not way to distinguish the two cases. ```ruby def transaction returned = false yield returned = true ensure if $! # error was raised elsif returned # no uniwnd else # non-local return or throw, don't know end end ``` I think it could be useful to have a way to access the currently thrown object, similar to `$!` for such cases, or some other way to tell what is going on. There is some discussion going on in https://github.com/ruby/timeout/pull/30 about whether `Timeout` should throw or raise, and that may solve part of the problem, but regardless of where this leads, I think being able to check if something is being thrown would be valuable. cc @matthewd FYI @jeremyevans0 @Eregon -- https://bugs.ruby-lang.org/

3 2

[ruby-core:114479] [Ruby master Feature#19846] Extend warnings message of bundled gems for gem author
by hsbt (Hiroshi SHIBATA) 24 Aug '23

24 Aug '23

Issue #19846 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #19846: Extend warnings message of bundled gems for gem author https://bugs.ruby-lang.org/issues/19846 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- This is my task reminder. The current warnings feature of bundled gems only notice for Gemfile. Like this: ``` $ cat Gemfile # frozen_string_literal: true source "https://rubygems.org" gem "activesupport" ``` ``` $ bundle exec irb >> require "active_support/all" /Users/hsbt/.local/share/gem/gems/activesupport-7.0.7.2/lib/active_support/core_ext/big_decimal/conversions.rb:3: warning: bigdecimal will be not part of the default gems since Ruby 3.4.0. Add it to your Gemfile. /Users/hsbt/.local/share/gem/gems/activesupport-7.0.7.2/lib/active_support/notifications/fanout.rb:3: warning: mutex_m will be not part of the default gems since Ruby 3.4.0. Add it to your Gemfile. ``` But we should also notice above message for maintainer of `activesupport` like "Add "mutex_m" with `add_dependency` to `activesupport` gemspec." -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114476] [Ruby master Bug#14543] `make commit` show error of `common-srcs`
by hsbt (Hiroshi SHIBATA) 24 Aug '23

24 Aug '23

Issue #14543 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed svn.ruby-lang.org is already retired. ---------------------------------------- Bug #14543: `make commit` show error of `common-srcs` https://bugs.ruby-lang.org/issues/14543#change-104260 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- When I use `make commit`, it shows following error. ``` ~/D/g/r/ruby (trunk) > mk commit make: Entering directory '/Users/hsbt/Documents/github.com/ruby/ruby/.x86_64-darwin' Committing to svn+ssh://svn@ci.ruby-lang.org/ruby/trunk ... M gems/bundled_gems Committed r62546 M gems/bundled_gems r62546 = 2e1b00647ce1b4d3a6801484d7e76283fac6d202 (refs/remotes/svn/trunk) No changes between 99295842365c9b356a6e8dfec264249cd8e24aad and refs/remotes/svn/trunk Resetting to the latest refs/remotes/svn/trunk dcommitted on a detached HEAD because you gave a revision argument. The rewritten commit is: 2e1b00647ce1b4d3a6801484d7e76283fac6d202 Already on 'trunk' Your branch is ahead of 'origin/trunk' by 1 commit. (use "git push" to publish your local commits) First, rewinding head to replay your work on top of it... Applying: Update minitest-5.11.3 on bundled gems. From github.com:ruby/ruby 26741c97f4..2e1b00647c trunk -> origin/trunk First, rewinding head to replay your work on top of it... make[1]: Entering directory '/Users/hsbt/Documents/github.com/ruby/ruby/.x86_64-darwin' make[1]: *** No rule to make target '../lex.c', needed by 'common-srcs'. Stop. make[1]: *** Waiting for unfinished jobs.... generating ../parse.c M gems/bundled_gems r62546 = 2e1b00647ce1b4d3a6801484d7e76283fac6d202 (refs/remotes/svn/trunk) Current branch trunk is up to date. make[1]: Leaving directory '/Users/hsbt/Documents/github.com/ruby/ruby/.x86_64-darwin' make: *** [../defs/gmake.mk:142: commit] Error 2 make: Leaving directory '/Users/hsbt/Documents/github.com/ruby/ruby/.x86_64-darwin' ``` `mk` is an alias of `make -j`. @nobu Can you investigate it? -- https://bugs.ruby-lang.org/

1 0