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

[ruby-core:114512] [Ruby master Bug#17676] Accessing ENV from Ractor raises IsolationError
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #17676 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Assigned to Closed This was fixed in commit:3aab870761ff0138ffd29e0a08b6cdf151e2acb4 ---------------------------------------- Bug #17676: Accessing ENV from Ractor raises IsolationError https://bugs.ruby-lang.org/issues/17676#change-104303 * 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

[ruby-core:114511] [Ruby master Bug#17667] Module#name needs synchronization
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #17667 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed This appears to have been fixed between Ruby 3.1 and 3.2. Ruby 3.0 and 3.1 both instantly crash with the given example, whereas Ruby 3.2 does not crash even if given a minute. ---------------------------------------- Bug #17667: Module#name needs synchronization https://bugs.ruby-lang.org/issues/17667#change-104302 * Author: ko1 (Koichi Sasada) * Status: Closed * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.1.0dev (2021-02-28T11:24:42Z master 80e2c45f55) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ```ruby class C; @iv = 1; end Ractor.new{ loop{C.name} } class C 0.step{|i| instance_variable_set("@iv#{i}", i)} end ``` ``` /home/ko1/ruby/src/trunk/test.rb:4: [BUG] Segmentation fault at 0x000056513df4ef10 ruby 3.1.0dev (2021-02-28T11:24:42Z master 80e2c45f55) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0005 p:---- s:0017 e:000016 CFUNC :name c:0004 p:0011 s:0013 e:000012 BLOCK /home/ko1/ruby/src/trunk/test.rb:4 [FINISH] c:0003 p:---- s:0010 e:000009 CFUNC :loop c:0002 p:0004 s:0006 e:000005 BLOCK /home/ko1/ruby/src/trunk/test.rb:4 [FINISH] c:0001 p:---- s:0003 e:000002 (none) [FINISH] -- Ruby level backtrace information ---------------------------------------- /home/ko1/ruby/src/trunk/test.rb:4:in `block in <main>' /home/ko1/ruby/src/trunk/test.rb:4:in `loop' /home/ko1/ruby/src/trunk/test.rb:4:in `block (2 levels) in <main>' /home/ko1/ruby/src/trunk/test.rb:4:in `name' -- Machine register context ------------------------------------------------ RIP: 0x000056513dbe09dc RBP: 0x000000000000000e RSP: 0x00007f96276e2140 RAX: 0x000056513df4ef10 RBX: 0x0000000000001238 RCX: 0x000000000000000d RDX: 0x0000000000000ee1 RDI: 0x000056513de6f040 RSI: 0x0000000000000001 R8: 0x000056513deedb00 R9: 0x000056513dec70c0 R10: 0x0000000000000000 R11: 0x00007f96276e2d29 R12: 0x00000000000040d8 R13: 0x000056513dea2470 R14: 0x00000000000076d5 R15: 0xffffffffffffffff EFL: 0x0000000000010206 -- C level backtrace information ------------------------------------------- /home/ko1/ruby/build/trunk/miniruby(rb_print_backtrace+0x11) [0x56513dc7e67e] /home/ko1/ruby/src/trunk/vm_dump.c:758 /home/ko1/ruby/build/trunk/miniruby(rb_vm_bugreport) /home/ko1/ruby/src/trunk/vm_dump.c:1042 /home/ko1/ruby/build/trunk/miniruby(rb_bug_for_fatal_signal+0xf4) [0x56513da892e4] /home/ko1/ruby/src/trunk/error.c:801 /home/ko1/ruby/build/trunk/miniruby(sigsegv+0x4d) [0x56513dbd5cbd] /home/ko1/ruby/src/trunk/signal.c:960 /lib/x86_64-linux-gnu/libpthread.so.0(__restore_rt+0x0) [0x7f962b7283c0] ../sysdeps/pthread/funlockfile.c:28 /home/ko1/ruby/build/trunk/miniruby(find_table_entry_ind+0x5c) [0x56513dbe09dc] /home/ko1/ruby/src/trunk/st.c:839 /home/ko1/ruby/build/trunk/miniruby(rb_st_lookup+0x4a) [0x56513dbe16fa] /home/ko1/ruby/src/trunk/st.c:1021 /home/ko1/ruby/build/trunk/miniruby(classname+0x79) [0x56513dc46380] /home/ko1/ruby/src/trunk/variable.c:102 /home/ko1/ruby/build/trunk/miniruby(rb_mod_name+0x32) [0x56513dc46405] /home/ko1/ruby/src/trunk/variable.c:121 /home/ko1/ruby/build/trunk/miniruby(vm_call_cfunc_with_frame+0x11b) [0x56513dc562eb] /home/ko1/ruby/src/trunk/vm_insnhelper.c:2924 /home/ko1/ruby/build/trunk/miniruby(vm_sendish+0xe) [0x56513dc63957] /home/ko1/ruby/src/trunk/vm_insnhelper.c:4525 ``` -- https://bugs.ruby-lang.org/

1 0

[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