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

[ruby-core:115517] [Ruby master Bug#20026] Ruby doesn't throw a syntax error when rescuing with ||
by arian (Arian Faurtosh) 29 Nov '23

29 Nov '23

Issue #20026 has been reported by arian (Arian Faurtosh). ---------------------------------------- Bug #20026: Ruby doesn't throw a syntax error when rescuing with || https://bugs.ruby-lang.org/issues/20026 * Author: arian (Arian Faurtosh) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [arm64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- We had a coworker new to ruby try an interesting syntax for rescue that doesn't result in a syntax error, and works partially. Why does ruby allow the logical OR || operator, is there a purpose for this? If not this feels like it should be a syntax error, instead of resulting in partially working code. ``` ruby class FooError < StandardError; end class BarError < StandardError; end # works begin raise FooError rescue FooError || BarError => e puts "rescued #{e.class}" end # doesn't work begin raise FooError rescue FooError || BarError => e puts "rescued #{e.class}" end ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:115519] [Ruby master Bug#18886] Struct aref and aset don't trigger any tracepoints.
by jeremyevans0 (Jeremy Evans) 28 Nov '23

28 Nov '23

Issue #18886 has been updated by jeremyevans0 (Jeremy Evans). mame (Yusuke Endoh) wrote in #note-7: > @jeremyevans0 Could you measure the overhead? Using the benchmark in the pull request, the pull request seems reliably ~5% faster in my testing for the member reader method, but mixed for other cases (sometimes up to 3% faster/slower depending on run). I don't have any explanation as to why it would be faster, so I'm going to assume that the difference is still within the margin of error. I don't think this will affect performance unless TracePoint is used, because the same method caching is done in both cases. ---------------------------------------- Bug #18886: Struct aref and aset don't trigger any tracepoints. https://bugs.ruby-lang.org/issues/18886#change-105448 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Given the following program, `thing.name` and `thing.shape` don't trigger `c_call` trace points (or any trace points actually). ```ruby pp RUBY_VERSION trace_point = TracePoint.new(:line, :call, :c_call, :a_call) do |trace| puts trace.event if trace.event == :call # Ruby doesn't always mark call-sites in sub-expressions, so we use this approach to compute a call site and mark it: if location = caller_locations(2, 1).first and path = location.path puts "> #{path}:#{location.lineno}:#{trace.event}" end end if path = trace.path puts "= #{path}:#{trace.lineno}:#{trace.event}" end end trace_point.enable # This will trigger call trace points class Thing def name :cat end def shape :square end end thing = Thing.new # Thing = Struct.new(:name, :shape) # thing = Thing.new(:cat, :rectangle) [ name: thing.name, shape: thing.shape, ] ``` ## Current HEAD ``` = ../test.rb:30:line: = ../test.rb:30:c_call:new = ../test.rb:30:c_call:inherited = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:const_added = ../test.rb:31:line: = ../test.rb:31:c_call:new = ../test.rb:31:c_call:initialize = ../test.rb:34:line: ``` ## Proposed PR ``` = ../test.rb:30:line: = ../test.rb:30:c_call:new = ../test.rb:30:c_call:inherited = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:const_added = ../test.rb:31:line: = ../test.rb:31:c_call:new = ../test.rb:31:c_call:initialize = ../test.rb:34:line: = ../test.rb:34:c_call:name = ../test.rb:35:c_call:shape ``` The reason is the internal implementation of struct doesn't have trace point instrumentation in `vm_call_opt_struct_aset` or `vm_call_opt_struct_aref`. Proposed fix: https://github.com/ruby/ruby/pull/6071 but this would need a review, maybe @jeremyevans0 and @ko1 can help. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115502] [Ruby master Bug#8299] Minor error in float parsing
by naruse (Yui NARUSE) 28 Nov '23

28 Nov '23

Issue #8299 has been updated by naruse (Yui NARUSE). Status changed from Assigned to Closed hdtoa has the rounding logic, but it doesn't work well on x87, but no one use x87 now. This issue is resolved. ---------------------------------------- Bug #8299: Minor error in float parsing https://bugs.ruby-lang.org/issues/8299#change-105431 * Author: bobjalex (Bob Alexander) * Status: Closed * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: trunk ---------------------------------------- I encountered a float that either parses [slightly] differently (or converts to string differently) in Ruby than it does in Python or Java. This looks like a Ruby bug since the result "looks" incorrect. It is easily reproduced by entering the magic number (-1.1505945E-5) into irb. It behaves the same in 2.0 and 1.9. I'm using Windows. Below is an irb session that demonstrates. Also included are JRuby and Python trials that show better behavior. This issue is not causing me any problems, but just in case someone there is interested in looking into it... Bob >ruby -v ruby 2.0.0p0 (2013-02-24) [i386-mingw32] >irb irb(main):001:0> RUBY_VERSION => "2.0.0" irb(main):002:0> -1.1505945E-5 => -1.1505945000000001e-05 >ruby19 -v ruby 1.9.3p392 (2013-02-22) [i386-mingw32] >irb19 irb(main):001:0> RUBY_VERSION => "1.9.3" irb(main):002:0> -1.1505945E-5 => -1.1505945000000001e-05 irb(main):002:0> >jirb irb(main):001:0> -1.1505945E-5 => -1.1505945e-05 >python Python 2.7.4rc1 (default, Mar 24 2013, 14:34:32) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> -1.1505945E-5 -1.1505945e-05 >>> repr(-1.1505945E-5) '-1.1505945e-05' -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115355] [Ruby master Bug#20003] Array#rassoc does not preform implicit conversion
by temabolshakov (Tema Bolshakov) 28 Nov '23

28 Nov '23

Issue #20003 has been reported by temabolshakov (Tema Bolshakov). ---------------------------------------- Bug #20003: Array#rassoc does not preform implicit conversion https://bugs.ruby-lang.org/issues/20003 * Author: temabolshakov (Tema Bolshakov) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- There is a difference between behaviour of Array#assoc and Array#rassoc. The first one performs implicit conversion (calls #to_ary) while the former does not. ``` ruby class ArrayConvertible def initialize(*values) @values = values; end def to_ary @values end end s1 = [1, 2] s2 = ArrayConvertible.new(2, 3) a = [s1, s2] ``` The `a.assoc(2)` call returns `[2, 3]` as expected. However, `a.rassoc(3)` returns `nil` **Expected behaviour**: `a.rassoc(3)` returns `[2, 3]` in such cases. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:115499] [Ruby master Bug#9189] Build failure on Windows in case of nonascii TEMP environment.
by nobu (Nobuyoshi Nakada) 28 Nov '23

28 Nov '23

Issue #9189 has been updated by nobu (Nobuyoshi Nakada). Backport changed from 1.9.3: DONTNEED, 2.0.0: REQUIRED to 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN pcai (Peter Cai) wrote in #note-13: > I'm unable to reproduce. Windows presents an ascii-safe alias of the TEMP folder for me so I can't seem to test the handling: Thank you for testing. Does it work after `set TEMP=C:\Users\희섭\tmp`? ---------------------------------------- Bug #9189: Build failure on Windows in case of nonascii TEMP environment. https://bugs.ruby-lang.org/issues/9189#change-105428 * Author: phasis68 (Heesob Park) * Status: Assigned * Priority: Normal * ruby -v: ruby 2.1.0dev (2013-11-30 trunk 43936) [i386-mingw32] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I experienced a build failure during build extension library with trunk on Windows. make[2]: Entering directory `/c/work/ruby-2.1.0-r43936/ext/bigdecimal' generating bigdecimal-i386-mingw32.def compiling bigdecimal.c In file included from bigdecimal.c:20:0: bigdecimal.h:62:1: error: static declaration of 'labs' follows non-static declar ation make[2]: *** [bigdecimal.o] Error 1 make[2]: Leaving directory `/c/work/ruby-2.1.0-r43936/ext/bigdecimal' make[1]: *** [ext/bigdecimal/all] Error 2 make[1]: Leaving directory `/c/work/ruby-2.1.0-r43936' make: *** [build-ext] Error 2 I found the cause of this error is mkmk failure. Here is a part of mkmf.log have_func: checking for labs() in stdlib.h... -------------------- no "i686-w64-mingw32-gcc -o conftest.exe -I../../.ext/include/i386-mingw32 -I../.././include -I../.././ext/bigdecimal -D_WIN32_WINNT=0x0501 -D_FILE_OFFSET_BITS=64 -O3 -fno-omit-frame-pointer -fno-fast-math -ggdb3 -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement -Wimplicit-function-declaration conftest.c -L. -L../.. -L. -lmsvcrt-ruby210-static -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi " This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Cannot create temporary file in C:\Users\??苑?AppData\Local\Temp\: Invalid argument The TEMP environment varable is C:\work\ruby-2.1.0-r43936>set TEMP TEMP=C:\Users\희섭\AppData\Local\Temp It seems that miniruby cannot handle encoding properly. C:\work\ruby-2.1.0-r43936>miniruby -ve "p ENV['TEMP']" ruby 2.1.0dev (2013-11-30 trunk 43936) [i386-mingw32] "C:\\Users\\\xED\x9D\xAC\xEC\x84\xAD\\AppData\\Local\\Temp" C:\work\ruby-2.1.0-r43936>miniruby.exe -ve "p ENV['TEMP'].encoding" ruby 2.1.0dev (2013-11-30 trunk 43936) [i386-mingw32] #<Encoding:ASCII-8BIT> Whereas, the final ruby can handle encoding properly. C:\work>ruby -ve "p ENV['TEMP']" ruby 2.1.0dev (2013-11-30 trunk 43923) [i386-mingw32] "C:\\Users\\희섭\\AppData\\Local\\Temp" C:\work>ruby -ve "p ENV['TEMP'].encoding" ruby 2.1.0dev (2013-11-30 trunk 43923) [i386-mingw32] #<Encoding:CP949> -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115498] [Ruby master Feature#18551] Make `Range#reverse_each` to raise an exception if endless
by mame (Yusuke Endoh) 28 Nov '23

28 Nov '23

Issue #18551 has been updated by mame (Yusuke Endoh). In the previous dev meething, matz accepted this. I will merge the PR ---------------------------------------- Feature #18551: Make `Range#reverse_each` to raise an exception if endless https://bugs.ruby-lang.org/issues/18551#change-105427 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal ---------------------------------------- https://github.com/ruby/ruby/pull/5498 Currently, `Range#reverse_each` for an endless range never returns. ``` % ruby -e '(1..).reverse_each { }' # never return ... ``` (This is because `Enumerable#reverse_each` tries `#to_a` and `#to_a` for an endless range comes into an infinite loop.) I think `Range#reverse_each` for an endless range should raise an exception, similar to `Range#each` for a beginless range. ``` % ruby -e '(..1).each { }' -e:1:in `each': can't iterate from NilClass (TypeError) from -e:1:in `<main>' ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115483] [Ruby master Bug#20021] TestGCCompact#test_moving_hashes_down_size_pools is flaky
by kjtsanaktsidis (KJ Tsanaktsidis) 28 Nov '23

28 Nov '23

Issue #20021 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #20021: TestGCCompact#test_moving_hashes_down_size_pools is flaky https://bugs.ruby-lang.org/issues/20021 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The test `TestGCCompact#test_moving_hashes_down_size_pools is flaky` is, I believe, flaky, and sometimes fails with this message: ``` 1) Failure: TestGCCompact#test_moving_hashes_down_size_pools [/home/chkbuild/chkbuild/tmp/build/20231112T183003Z/ruby/test/ruby/test_gc_compact.rb:442]: Expected 499 to be >= 500. ``` I started looking at this because when https://github.com/ruby/ruby/pull/8858 was merged, rubyci began failing on Ubuntu 22.04 with this message (https://rubyci.s3.amazonaws.com/ubuntu2204/ruby-master/log/20231112T183003Z…) I was able to reproduce this failure after _very_ carefully reproducing the ruibyci testing environment (same EC2 instance type, and I actually had to install _exactly_ the same kernel version as well!). After debugging the test, what I discovered is that the _last_ hash that was modified in the test is actually on the machine stack when `GC.verify_compaction_references` is called, which means it gets pinned and cannot be moved; thus, the test fails because only 499 out of 500 objects got moved! The hash's VALUE is "on the stack" in the sense that it's in a memory location below `%rsp`, but it is _NOT_ actually live in any C local variable. The stack address I found the VALUE in is part of the frame of `gc_start`, but `gc_start` obviously doesn't hold a reference to the hash from the test. Rather, it's left-behind in uninitialized memory. I think this is made more likely because of how GCC wound up compiling the `gc_start` function. It seems to have allocated quite a lot of stack space - 440 bytes of it - and very little of it seems to be used for local variables. Thus, a lot of this memory just contains assorted tidbits from previous VM execution state. This patch works around the issue, at least on my testbench, by running the code which touches the test hashes in a separate fiber. Each fiber gets its own machine stack, so references to the to-be-moved hashes shouldn't leak into the main stack, and this fiber's stack should be out of scope when the compaction is run, so it should get freed. https://github.com/ruby/ruby/pull/9040 The other approach I considered is counting the number of pinned objects, and asserting that (moved + pinned) >= 500 instead of just moved >= 500. However, it's very likely that there will be a pinned hash (or string, etc, for the other, similar test cases), so this would make the test pass even when it should not, I think. Also, since this these tests were skipped on Solaris because of this bug, I have unskipped them (although it seems we no longer have solaris on ruby ci, so I guess it doesn't matter). -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115494] [Ruby master Bug#18886] Struct aref and aset don't trigger any tracepoints.
by mame (Yusuke Endoh) 28 Nov '23

28 Nov '23

Issue #18886 has been updated by mame (Yusuke Endoh). @jeremyevans0 Could you measure the overhead? ---------------------------------------- Bug #18886: Struct aref and aset don't trigger any tracepoints. https://bugs.ruby-lang.org/issues/18886#change-105423 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Given the following program, `thing.name` and `thing.shape` don't trigger `c_call` trace points (or any trace points actually). ```ruby pp RUBY_VERSION trace_point = TracePoint.new(:line, :call, :c_call, :a_call) do |trace| puts trace.event if trace.event == :call # Ruby doesn't always mark call-sites in sub-expressions, so we use this approach to compute a call site and mark it: if location = caller_locations(2, 1).first and path = location.path puts "> #{path}:#{location.lineno}:#{trace.event}" end end if path = trace.path puts "= #{path}:#{trace.lineno}:#{trace.event}" end end trace_point.enable # This will trigger call trace points class Thing def name :cat end def shape :square end end thing = Thing.new # Thing = Struct.new(:name, :shape) # thing = Thing.new(:cat, :rectangle) [ name: thing.name, shape: thing.shape, ] ``` ## Current HEAD ``` = ../test.rb:30:line: = ../test.rb:30:c_call:new = ../test.rb:30:c_call:inherited = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:const_added = ../test.rb:31:line: = ../test.rb:31:c_call:new = ../test.rb:31:c_call:initialize = ../test.rb:34:line: ``` ## Proposed PR ``` = ../test.rb:30:line: = ../test.rb:30:c_call:new = ../test.rb:30:c_call:inherited = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:const_added = ../test.rb:31:line: = ../test.rb:31:c_call:new = ../test.rb:31:c_call:initialize = ../test.rb:34:line: = ../test.rb:34:c_call:name = ../test.rb:35:c_call:shape ``` The reason is the internal implementation of struct doesn't have trace point instrumentation in `vm_call_opt_struct_aset` or `vm_call_opt_struct_aref`. Proposed fix: https://github.com/ruby/ruby/pull/6071 but this would need a review, maybe @jeremyevans0 and @ko1 can help. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115489] [Ruby master Bug#20023] rb_require("noexist") causes segfault
by mtasaka (Mamoru Tasaka) 27 Nov '23

27 Nov '23

Issue #20023 has been reported by mtasaka (Mamoru Tasaka). ---------------------------------------- Bug #20023: rb_require("noexist") causes segfault https://bugs.ruby-lang.org/issues/20023 * Author: mtasaka (Mamoru Tasaka) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-11-27 master a07d84b63c) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Extracted from swig 4.1.1 testsuite. With commit:a07d84b63c (and probably with earlier commit), `rb_require("noexist") ;` seems segfault. foo.rb: ``` #!/usr/bin/env ruby begin require "bar" rescue LoadError => e p e.to_s end ``` bar.c: ``` #include <ruby.h> void Init_bar(void) { VALUE m_bar = rb_define_module("Bar"); rb_require("noexist"); } ``` Execute: ``` gcc -shared -I/usr/include -Wall -O2 -g -fpic -fPIC -o bar.so bar.c ruby -I. foo.rb ``` With `ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]`: OK ``` + ruby -I. foo.rb "cannot load such file -- noexist" ``` With `ruby 3.3.0dev (2023-11-27 master a07d84b63c) [x86_64-linux]`: ``` + ruby -I. foo.rb <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:129: [BUG] Segmentation fault at 0x0000000000000000 ruby 3.3.0dev (2023-11-27 master a07d84b63c) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0004 p:0020 s:0019 e:000016 RESCUE <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:129 c:0003 p:0024 s:0013 e:000012 METHOD <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:126 c:0002 p:0005 s:0007 E:000818 EVAL foo.rb:4 [FINISH] c:0001 p:0000 s:0003 E:001d70 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- foo.rb:4:in `<main>' <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:126:in `require' <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:129:in `rescue in require' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x00007feedd015807 RBP: 0x00007ffd9f27ad00 RSP: 0x00007ffd9f27ac98 RAX: 0x000000000000008c RBX: 0x0000008c00100003 RCX: 0x00007feedd34dc78 RDX: 0x00007ffd9f27acb8 RDI: 0x0041710f058b48c3 RSI: 0x000000000000008c R8: 0x00007feec1788690 R9: 0x00007ffd9f27a8a0 R10: 0x00007feedc98dc08 R11: 0x0000000000000001 R12: 0x00007feedcf35049 R13: 0x0041710f058b48c3 R14: 0x0000562a51a61c20 R15: 0x000000000000008c EFL: 0x0000000000010206 -- C level backtrace information ------------------------------------------- /lib64/libruby.so.3.3(rb_print_backtrace+0x21) [0x7feedd078041] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/vm_dump.c:820 /lib64/libruby.so.3.3(rb_vm_bugreport+0x9aa) [0x7feedd07adda] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/vm_dump.c:1151 /lib64/libruby.so.3.3(rb_bug_for_fatal_signal+0x110) [0x7feedced5900] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/error.c:1065 /lib64/libruby.so.3.3(sigsegv+0x56) [0x7feedcfeef06] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/signal.c:920 /lib64/libc.so.6(__restore_rt+0x0) [0x7feedcc5b9a0] /lib64/libruby.so.3.3(rb_id_table_lookup+0x7) [0x7feedd015807] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/symbol.h:72 /lib64/libruby.so.3.3(vm_search_cc.lto_priv.0+0x58) [0x7feedd04dc58] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/vm_insnhelper.c:2032 /lib64/libruby.so.3.3(vm_search_method_slowpath0.lto_priv.0+0x39) [0x7feedd04e0d9] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/vm_insnhelper.c:2128 /lib64/libruby.so.3.3(vm_exec_core.lto_priv.0+0x4d7e) [0x7feedd062c1e] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/vm_insnhelper.c:2210 /lib64/libruby.so.3.3(rb_vm_exec+0x39e) [0x7feedd07665e] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/vm.c:2494 /lib64/libruby.so.3.3(rb_ec_exec_node+0xaa) [0x7feedcedb02a] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/eval.c:287 /lib64/libruby.so.3.3(ruby_run_node+0x93) [0x7feedcedba73] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/eval.c:328 /usr/bin/ruby-mri(0x562a5047f197) [0x562a5047f197] /lib64/libc.so.6(__libc_start_call_main+0x7a) [0x7feedcc4514a] /lib64/libc.so.6(__libc_start_main+0x8b) [0x7feedcc4520b] /usr/bin/ruby-mri(_start+0x25) [0x562a5047f1e5] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/main.c:59 -- Other runtime information ----------------------------------------------- * Loaded script: foo.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb 6 /usr/lib64/ruby/enc/encdb.so 7 /usr/lib64/ruby/enc/trans/transdb.so 8 /usr/lib64/ruby/rbconfig.rb 9 /usr/share/rubygems/rubygems/compatibility.rb 10 /usr/share/rubygems/rubygems/defaults.rb 11 /usr/share/rubygems/rubygems/deprecate.rb 12 /usr/share/rubygems/rubygems/errors.rb 13 /usr/share/rubygems/rubygems/unknown_command_spell_checker.rb 14 /usr/share/rubygems/rubygems/exceptions.rb 15 /usr/share/rubygems/rubygems/basic_specification.rb 16 /usr/share/rubygems/rubygems/stub_specification.rb 17 /usr/share/rubygems/rubygems/platform.rb 18 /usr/share/rubygems/rubygems/util/list.rb 19 /usr/share/rubygems/rubygems/version.rb 20 /usr/share/rubygems/rubygems/requirement.rb 21 /usr/share/rubygems/rubygems/specification.rb 22 /usr/share/rubygems/rubygems/defaults/operating_system.rb 23 /usr/share/rubygems/rubygems/util.rb 24 /usr/share/rubygems/rubygems/dependency.rb 25 /usr/share/rubygems/rubygems/core_ext/kernel_gem.rb 26 /usr/lib64/ruby/monitor.so 27 /usr/share/ruby/monitor.rb 28 /usr/share/rubygems/rubygems.rb 29 /usr/share/ruby/bundled_gems.rb 30 /usr/share/rubygems/rubygems/path_support.rb 31 /usr/share/ruby/error_highlight/version.rb 32 /usr/share/ruby/error_highlight/base.rb 33 /usr/share/ruby/error_highlight/formatter.rb 34 /usr/share/ruby/error_highlight/core_ext.rb 35 /usr/share/ruby/error_highlight.rb 36 /usr/share/ruby/did_you_mean/version.rb 37 /usr/share/ruby/did_you_mean/core_ext/name_error.rb 38 /usr/share/ruby/did_you_mean/levenshtein.rb 39 /usr/share/ruby/did_you_mean/jaro_winkler.rb 40 /usr/share/ruby/did_you_mean/spell_checker.rb 41 /usr/share/ruby/did_you_mean/spell_checkers/name_error_checkers/class_name_checker.rb 42 /usr/share/ruby/did_you_mean/spell_checkers/name_error_checkers/variable_name_checker.rb 43 /usr/share/ruby/did_you_mean/spell_checkers/name_error_checkers.rb 44 /usr/share/ruby/did_you_mean/spell_checkers/method_name_checker.rb 45 /usr/share/ruby/did_you_mean/spell_checkers/key_error_checker.rb 46 /usr/share/ruby/did_you_mean/spell_checkers/null_checker.rb 47 /usr/share/ruby/did_you_mean/tree_spell_checker.rb 48 /usr/share/ruby/did_you_mean/spell_checkers/require_path_checker.rb 49 /usr/share/ruby/did_you_mean/spell_checkers/pattern_key_name_checker.rb 50 /usr/share/ruby/did_you_mean/formatter.rb 51 /usr/share/ruby/did_you_mean.rb 52 /usr/share/ruby/syntax_suggest/core_ext.rb * Process memory map: 562a5047e000-562a5047f000 r--p 00000000 08:08 6739413 /usr/bin/ruby-mri 562a5047f000-562a50480000 r-xp 00001000 08:08 6739413 /usr/bin/ruby-mri 562a50480000-562a50481000 r--p 00002000 08:08 6739413 /usr/bin/ruby-mri 562a50481000-562a50482000 r--p 00002000 08:08 6739413 /usr/bin/ruby-mri 562a50482000-562a50483000 rw-p 00003000 08:08 6739413 /usr/bin/ruby-mri 562a51832000-562a51c68000 rw-p 00000000 00:00 0 [heap] 7feebc800000-7feebca51000 r--s 00000000 08:08 6732430 /usr/lib64/libc.so.6 7feebcc00000-7feebec0c000 r--s 00000000 08:08 6731115 /usr/lib/debug/usr/lib64/libruby.so.3.3.0-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64.debug 7feebee00000-7feec0e0c000 r--s 00000000 08:08 6731115 /usr/lib/debug/usr/lib64/libruby.so.3.3.0-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64.debug 7feec1000000-7feec1571000 r--s 00000000 08:08 6731218 /usr/lib64/libruby.so.3.3.0 7feec15d0000-7feec15e0000 rw-p 00000000 00:00 0 7feec16f0000-7feec1700000 rw-p 00000000 00:00 0 7feec1760000-7feec17a0000 rw-p 00000000 00:00 0 7feec17b0000-7feec1870000 rw-p 00000000 00:00 0 7feec187a000-7feec187f000 r--s 00000000 08:08 6731114 /usr/lib/debug/usr/bin/ruby-mri-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64.debug 7feec187f000-7feec1880000 ---p 00000000 00:00 0 7feec1880000-7feec1921000 rw-p 00000000 00:00 0 7feec1921000-7feec1922000 ---p 00000000 00:00 0 7feec1922000-7feec19c3000 rw-p 00000000 00:00 0 7feec19c3000-7feec19c4000 ---p 00000000 00:00 0 7feec19c4000-7feec1a65000 rw-p 00000000 00:00 0 7feec1a65000-7feec1a66000 ---p 00000000 00:00 0 7feec1a66000-7feec1b07000 rw-p 00000000 00:00 0 7feec1b07000-7feec1b08000 ---p 00000000 00:00 0 7feec1b08000-7feec1ba9000 rw-p 00000000 00:00 0 7feec1ba9000-7feec1baa000 ---p 00000000 00:00 0 7feec1baa000-7feec1c4b000 rw-p 00000000 00:00 0 7feec1c4b000-7feec1c4c000 ---p 00000000 00:00 0 7feec1c4c000-7feec1ced000 rw-p 00000000 00:00 0 7feec1ced000-7feec1cee000 ---p 00000000 00:00 0 7feec1cee000-7feec1d8f000 rw-p 00000000 00:00 0 7feec1d8f000-7feec1d90000 ---p 00000000 00:00 0 7feec1d90000-7feec1e31000 rw-p 00000000 00:00 0 7feec1e31000-7feec1e32000 ---p 00000000 00:00 0 7feec1e32000-7feec1ed3000 rw-p 00000000 00:00 0 7feec1ed3000-7feec1ed4000 ---p 00000000 00:00 0 7feec1ed4000-7feec1f75000 rw-p 00000000 00:00 0 7feec1f75000-7feec1f76000 ---p 00000000 00:00 0 7feec1f76000-7feec2017000 rw-p 00000000 00:00 0 7feec2017000-7feec2018000 ---p 00000000 00:00 0 7feec2018000-7feec20b9000 rw-p 00000000 00:00 0 7feec20b9000-7feec20ba000 ---p 00000000 00:00 0 7feec20ba000-7feec215b000 rw-p 00000000 00:00 0 7feec215b000-7feec215c000 ---p 00000000 00:00 0 7feec215c000-7feec21fd000 rw-p 00000000 00:00 0 7feec21fd000-7feec21fe000 ---p 00000000 00:00 0 7feec21fe000-7feec229f000 rw-p 00000000 00:00 0 7feec229f000-7feec22a0000 ---p 00000000 00:00 0 7feec22a0000-7feec2341000 rw-p 00000000 00:00 0 7feec2341000-7feec2342000 ---p 00000000 00:00 0 7feec2342000-7feec23e3000 rw-p 00000000 00:00 0 7feec23e3000-7feec23e4000 ---p 00000000 00:00 0 7feec23e4000-7feec2485000 rw-p 00000000 00:00 0 7feec2485000-7feec2486000 ---p 00000000 00:00 0 7feec2486000-7feec2527000 rw-p 00000000 00:00 0 7feec2527000-7feec2528000 ---p 00000000 00:00 0 7feec2528000-7feec25c9000 rw-p 00000000 00:00 0 7feec25c9000-7feec25ca000 ---p 00000000 00:00 0 7feec25ca000-7feec266b000 rw-p 00000000 00:00 0 7feec266b000-7feec266c000 ---p 00000000 00:00 0 7feec266c000-7feec270d000 rw-p 00000000 00:00 0 7feec270d000-7feec270e000 ---p 00000000 00:00 0 7feec270e000-7feec27af000 rw-p 00000000 00:00 0 7feec27af000-7feec27b0000 ---p 00000000 00:00 0 7feec27b0000-7feec2851000 rw-p 00000000 00:00 0 7feec2851000-7feec2852000 ---p 00000000 00:00 0 7feec2852000-7feec28f3000 rw-p 00000000 00:00 0 7feec28f3000-7feec28f4000 ---p 00000000 00:00 0 7feec28f4000-7feec2995000 rw-p 00000000 00:00 0 7feec2995000-7feec2996000 ---p 00000000 00:00 0 7feec2996000-7feec2a37000 rw-p 00000000 00:00 0 7feec2a37000-7feec2a38000 ---p 00000000 00:00 0 7feec2a38000-7feec2ad9000 rw-p 00000000 00:00 0 7feec2ad9000-7feec2ada000 ---p 00000000 00:00 0 7feec2ada000-7feec2b7b000 rw-p 00000000 00:00 0 7feec2b7b000-7feec2b7c000 ---p 00000000 00:00 0 7feec2b7c000-7feec2c1d000 rw-p 00000000 00:00 0 7feec2c1d000-7feec2c1e000 ---p 00000000 00:00 0 7feec2c1e000-7feec2cbf000 rw-p 00000000 00:00 0 7feec2cbf000-7feec2cc0000 ---p 00000000 00:00 0 7feec2cc0000-7feec3510000 rw-p 00000000 00:00 0 7feec3511000-7feec3516000 r--s 00000000 08:08 6731114 /usr/lib/debug/usr/bin/ruby-mri-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64.debug 7feec3516000-7feec351a000 r--s 00000000 08:08 6739413 /usr/bin/ruby-mri 7feec351a000-7feec351b000 r--p 00000000 08:08 7079696 /builddir/build/BUILD/swig-4.1.1/TEST/bar.so 7feec351b000-7feec351c000 r-xp 00001000 08:08 7079696 /builddir/build/BUILD/swig-4.1.1/TEST/bar.so 7feec351c000-7feec351d000 r--p 00002000 08:08 7079696 /builddir/build/BUILD/swig-4.1.1/TEST/bar.so 7feec351d000-7feec351e000 r--p 00002000 08:08 7079696 /builddir/build/BUILD/swig-4.1.1/TEST/bar.so 7feec351e000-7feec351f000 rw-p 00003000 08:08 7079696 /builddir/build/BUILD/swig-4.1.1/TEST/bar.so 7feec351f000-7feedc990000 rw-p 00000000 00:00 0 7feedc990000-7feedc991000 r--p 00000000 08:08 6738604 /usr/lib64/ruby/monitor.so 7feedc991000-7feedc992000 r-xp 00001000 08:08 6738604 /usr/lib64/ruby/monitor.so 7feedc992000-7feedc993000 r--p 00002000 08:08 6738604 /usr/lib64/ruby/monitor.so 7feedc993000-7feedc994000 r--p 00002000 08:08 6738604 /usr/lib64/ruby/monitor.so 7feedc994000-7feedca96000 rw-p 00000000 00:00 0 7feedca96000-7feedcaa6000 r--p 00000000 08:08 6732433 /usr/lib64/libm.so.6 7feedcaa6000-7feedcb1c000 r-xp 00010000 08:08 6732433 /usr/lib64/libm.so.6 7feedcb1c000-7feedcb76000 r--p 00086000 08:08 6732433 /usr/lib64/libm.so.6 7feedcb76000-7feedcb77000 r--p 000df000 08:08 6732433 /usr/lib64/libm.so.6 7feedcb77000-7feedcb78000 rw-p 000e0000 08:08 6732433 /usr/lib64/libm.so.6 7feedcb78000-7feedcb89000 r--p 00000000 08:08 6732764 /usr/lib64/libgmp.so.10.4.1 7feedcb89000-7feedcc05000 r-xp 00011000 08:08 6732764 /usr/lib64/libgmp.so.10.4.1 7feedcc05000-7feedcc1a000 r--p 0008d000 08:08 6732764 /usr/lib64/libgmp.so.10.4.1 7feedcc1a000-7feedcc1c000 r--p 000a1000 08:08 6732764 /usr/lib64/libgmp.so.10.4.1 7feedcc1c000-7feedcc1d000 rw-p 000a3000 08:08 6732764 /usr/lib64/libgmp.so.10.4.1 7feedcc1d000-7feedcc43000 r--p 00000000 08:08 6732430 /usr/lib64/libc.so.6 7feedcc43000-7feedcda4000 r-xp 00026000 08:08 6732430 /usr/lib64/libc.so.6 7feedcda4000-7feedcdf2000 r--p 00187000 08:08 6732430 /usr/lib64/libc.so.6 7feedcdf2000-7feedcdf6000 r--p 001d4000 08:08 6732430 /usr/lib64/libc.so.6 7feedcdf6000-7feedcdf8000 rw-p 001d8000 08:08 6732430 /usr/lib64/libc.so.6 7feedcdf8000-7feedce00000 rw-p 00000000 00:00 0 7feedce00000-7feedce4a000 r--p 00000000 08:08 6731218 /usr/lib64/libruby.so.3.3.0 7feedce4a000-7feedd1c9000 r-xp 0004a000 08:08 6731218 /usr/lib64/libruby.so.3.3.0 7feedd1c9000-7feedd334000 r--p 003c9000 08:08 6731218 /usr/lib64/libruby.so.3.3.0 7feedd334000-7feedd34d000 r--p 00533000 08:08 6731218 /usr/lib64/libruby.so.3.3.0 7feedd34d000-7feedd34e000 rw-p 0054c000 08:08 6731218 /usr/lib64/libruby.so.3.3.0 7feedd34e000-7feedd363000 rw-p 00000000 00:00 0 7feedd365000-7feedd368000 rw-p 00000000 00:00 0 7feedd368000-7feedd36b000 r--p 00000000 08:08 6731236 /usr/lib64/libgcc_s-13-20231113.so.1 7feedd36b000-7feedd386000 r-xp 00003000 08:08 6731236 /usr/lib64/libgcc_s-13-20231113.so.1 7feedd386000-7feedd38a000 r--p 0001e000 08:08 6731236 /usr/lib64/libgcc_s-13-20231113.so.1 7feedd38a000-7feedd38b000 r--p 00021000 08:08 6731236 /usr/lib64/libgcc_s-13-20231113.so.1 7feedd38b000-7feedd38e000 rw-p 00000000 00:00 0 7feedd38e000-7feedd390000 r--p 00000000 08:08 6732782 /usr/lib64/libcrypt.so.2.0.0 7feedd390000-7feedd3a4000 r-xp 00002000 08:08 6732782 /usr/lib64/libcrypt.so.2.0.0 7feedd3a4000-7feedd3bd000 r--p 00016000 08:08 6732782 /usr/lib64/libcrypt.so.2.0.0 7feedd3bd000-7feedd3be000 r--p 0002e000 08:08 6732782 /usr/lib64/libcrypt.so.2.0.0 7feedd3be000-7feedd3c7000 rw-p 00000000 00:00 0 7feedd3c7000-7feedd3ca000 r--p 00000000 08:08 6732659 /usr/lib64/libz.so.1.2.13 7feedd3ca000-7feedd3d9000 r-xp 00003000 08:08 6732659 /usr/lib64/libz.so.1.2.13 7feedd3d9000-7feedd3df000 r--p 00012000 08:08 6732659 /usr/lib64/libz.so.1.2.13 7feedd3df000-7feedd3e0000 r--p 00018000 08:08 6732659 /usr/lib64/libz.so.1.2.13 7feedd3e0000-7feedd3e3000 rw-p 00000000 00:00 0 7feedd3e3000-7feedd3e4000 r--p 00000000 08:08 6738584 /usr/lib64/ruby/enc/trans/transdb.so 7feedd3e4000-7feedd3e5000 r-xp 00001000 08:08 6738584 /usr/lib64/ruby/enc/trans/transdb.so 7feedd3e5000-7feedd3e6000 r--p 00002000 08:08 6738584 /usr/lib64/ruby/enc/trans/transdb.so 7feedd3e6000-7feedd3e7000 r--p 00002000 08:08 6738584 /usr/lib64/ruby/enc/trans/transdb.so 7feedd3e7000-7feedd3e8000 rw-p 00000000 00:00 0 7feedd3e8000-7feedd3e9000 r--p 00000000 08:08 6732495 /usr/lib64/ruby/enc/encdb.so 7feedd3e9000-7feedd3ea000 r-xp 00001000 08:08 6732495 /usr/lib64/ruby/enc/encdb.so 7feedd3ea000-7feedd3eb000 r--p 00002000 08:08 6732495 /usr/lib64/ruby/enc/encdb.so 7feedd3eb000-7feedd3ec000 r--p 00002000 08:08 6732495 /usr/lib64/ruby/enc/encdb.so 7feedd3ec000-7feedd3ed000 rw-p 00000000 00:00 0 7feedd3ed000-7feedd3ee000 r--p 00000000 08:08 6732427 /usr/lib64/ld-linux-x86-64.so.2 7feedd3ee000-7feedd415000 r-xp 00001000 08:08 6732427 /usr/lib64/ld-linux-x86-64.so.2 7feedd415000-7feedd41f000 r--p 00028000 08:08 6732427 /usr/lib64/ld-linux-x86-64.so.2 7feedd41f000-7feedd421000 r--p 00031000 08:08 6732427 /usr/lib64/ld-linux-x86-64.so.2 7feedd421000-7feedd423000 rw-p 00033000 08:08 6732427 /usr/lib64/ld-linux-x86-64.so.2 7ffd9ea7e000-7ffd9f27d000 rw-p 00000000 00:00 0 [stack] 7ffd9f35d000-7ffd9f361000 r--p 00000000 00:00 0 [vvar] 7ffd9f361000-7ffd9f363000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] foofoo-test.sh: line 6: 141 Aborted (core dumped) ruby -I. foo.rb ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115485] [Ruby master Bug#14582] Unable to use `method__entry` and `method_return` tracing probes since 2.5
by vo.x (Vit Ondruch) 27 Nov '23

27 Nov '23

Issue #14582 has been updated by vo.x (Vit Ondruch). Yes, this si still the case. And it is [documented](https://github.com/ruby/ruby/pull/3115). Nevertheless, I don't think this is acceptable. The original DTrace probes implementation imposed nearly zero cost for runtime. Later it was somehow bound to TracePoint and now due to TracePoint being slow, the DTrace probes are disabled? Just reading the code, (I have not tested this snipped, but) would something like this help? ~~~diff $ git diff diff --git a/vm_insnhelper.c b/vm_insnhelper.c index 9f9d0fcfd8..ee0a77e9fb 100644 --- a/vm_insnhelper.c +++ b/vm_insnhelper.c @@ -6489,7 +6489,6 @@ vm_trace_hook(rb_execution_context_t *ec, rb_control_frame_t *reg_cfp, const VAL if (event & global_hooks->events) { /* increment PC because source line is calculated with PC-1 */ reg_cfp->pc++; - vm_dtrace(event, ec); rb_exec_event_hook_orig(ec, global_hooks, event, self, 0, 0, 0 , val, 0); reg_cfp->pc--; } @@ -6622,6 +6621,8 @@ vm_trace(rb_execution_context_t *ec, rb_control_frame_t *reg_cfp) vm_trace_hook(ec, reg_cfp, pc, RUBY_EVENT_RETURN, RUBY_EVENT_RETURN, global_hooks, bmethod_local_hooks_ptr, TOPN(0)); } + vm_dtrace(pc_events & RUBY_EVENT_CALL, ec); + // Pin the iseq since `local_hooks_ptr` points inside the iseq's slot on the GC heap. // We need the pointer to stay valid in case compaction happens in a trace hook. // ~~~ ---------------------------------------- Bug #14582: Unable to use `method__entry` and `method_return` tracing probes since 2.5 https://bugs.ruby-lang.org/issues/14582#change-105415 * Author: guilhermereiscampos (Guilherme Reis Campos) * Status: Open * Priority: Normal * ruby -v: 2.5 * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- Hi, I am trying to use dtrace/systemtap probes and not being able to use it after the 2.5. The 2.4 version works fine. I was hoping this was fixed on 2.6-preview, but apparently not (just downloaded dev and tested). I tried on OSX using dtrace and also on ubuntu (vagrant). ``` # test.rb class Foo def bar 100.times { "Bar" } end end foo = Foo.new foo.bar # test.stp probe process("/home/vagrant/.rbenv/versions/2.4.0/bin/ruby").mark("method__entry") # you will need to change this to your ruby path of your version. { printf("%s => %s.%s in %s:%d\n", thread_indent(1), kernel_string($arg1),kernel_string($arg2),kernel_string($arg3),$arg4); } probe process("/home/vagrant/.rbenv/versions/2.4.0/bin/ruby").mark("method__return") { printf("%s <= %s.%s in %s:%d\n", thread_indent(-1), kernel_string($arg1),kernel_string($arg2),kernel_string($arg3),$arg4); } ``` dtrace was something similar to it. I was expecting to see this output: ``` # lots of calls # .... # then: 4090 ruby(9667): <= Gem::Specification.unresolved_deps in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/specification.rb:1298 4095 ruby(9667): => MonitorMixin.mon_exit in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:197 4100 ruby(9667): => MonitorMixin.mon_check_owner in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:247 4104 ruby(9667): <= MonitorMixin.mon_check_owner in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:251 4109 ruby(9667): <= MonitorMixin.mon_exit in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:204 4283 ruby(9667): <= Kernel.require in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55 4303 ruby(9667): <= Kernel.require in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55 0 ruby(9667): => Foo.bar in test.rb:3 16 ruby(9667): <= Foo.bar in test.rb:5 ``` (The output above is 2.4) my ruby (all versions that I tested) was install with rb-env: ``` RUBY_CONFIGURE_OPTS='--enable-dtrace --disable-install-doc' rbenv install 2.5.0 ``` I am happy to provide details if required. I'd also be happy to fix it if I have guidance. Thanks, -- https://bugs.ruby-lang.org/

1 0