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

[ruby-core:114753] [Ruby master Bug#9115] Logger traps all exceptions; breaks Timeout
by mame (Yusuke Endoh) 14 Sep '23

14 Sep '23

Issue #9115 has been updated by mame (Yusuke Endoh). Discussed at the dev meeting. * It is clear that Logger has the intention not to interfere with the execution of the application on a log write failure. * On the other hand, it is also clear that Logger is not considering about asynchronous exceptions. As a better-than-nothing mitigation, it is proposed to enclose the entire `Logger::LogDevice#write` in `Thread.handle_interrupt(:never) { ... }`. It could be a problem if the method takes a very long time because `Timeout.timeout` cannot interrupt the execution, but such a case will be rare (hopefully). What exception `Timeout.timeout` raises is user-configurable, so it would be difficult to reraise only a specific exception class. It is ultimately up to the maintainer, @sonots, to decide. ---------------------------------------- Bug #9115: Logger traps all exceptions; breaks Timeout https://bugs.ruby-lang.org/issues/9115#change-104590 * Author: cphoenix (Chris Phoenix) * Status: Assigned * Priority: Normal * Assignee: sonots (Naotoshi Seo) * ruby -v: ruby 2.0.0p247 (2013-06-27) [i386-mingw32] ---------------------------------------- Line 577-579 of logger.rb rescue Exception => ignored warn("log writing failed. #{ignored}") end Thus, when the system times out in the middle of writing a log message, it warns "log writing failed. execution expired" and just keeps right on running. This is true in 1.9.3 as well. I haven't looked at older versions. Pardon me while I go grep "rescue Exception" in the entire Ruby codebase, and see whether I can reliably use Timeout at all... OK, you might check out C:\Ruby200\lib\ruby\gems\2.0.0\gems\activerecord-3.2.13\lib\active_record\railties\databases.rake All the other "rescue Exception" seem to re-raise it, except maybe C:\Ruby200\lib\ruby\2.0.0\xmlrpc\server.rb and C:\Ruby200\lib\ruby\gems\2.0.0\gems\activesupport-3.2.13\lib\active_support\callbacks.rb -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114751] [Ruby master Bug#17146] Queue operations are allowed after it is frozen
by mame (Yusuke Endoh) 14 Sep '23

14 Sep '23

Issue #17146 has been updated by mame (Yusuke Endoh). I would like to add a point that came up during the dev meeting: if a thread is waiting for `Queue#pop`, and another thread freezes the Queue, what should the first thread do? Wait forever? Raise a FrozenError? To raise a FrozenError, it needs to be told that the Queue was asynchronously frozen by another thread. In other words, `Queue#freeze` needs to wake up the thread waiting for the Queue, which is likely to do more than `#freeze` would normally be expected to do. ---------------------------------------- Bug #17146: Queue operations are allowed after it is frozen https://bugs.ruby-lang.org/issues/17146#change-104587 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * ruby -v: ruby 2.6.6p146 (2020-03-31 revision 67876) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- ``` [1] pry(main)> q = Queue.new => #<Thread::Queue:0x000056263683aee8> [2] pry(main)> q.freeze => #<Thread::Queue:0x000056263683aee8> [3] pry(main)> q << 1 => #<Thread::Queue:0x000056263683aee8> [4] pry(main)> q.pop => 1 [5] pry(main)> q.frozen? => true ``` Found by @ko1 in https://bugs.ruby-lang.org/issues/17100#note-28 I think it's a bug, since those are clear mutations. I guess old Thread::Queue implemented in Ruby did not have this bug. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114348] [Ruby master Feature#19832] Method#destructive?, UnboundMethod#destructive?
by sawa (Tsuyoshi Sawada) 14 Sep '23

14 Sep '23

Issue #19832 has been reported by sawa (Tsuyoshi Sawada). ---------------------------------------- Feature #19832: Method#destructive?, UnboundMethod#destructive? https://bugs.ruby-lang.org/issues/19832 * Author: sawa (Tsuyoshi Sawada) * Status: Open * Priority: Normal ---------------------------------------- I propose to add `destructive?` property to `Method` and `UnboundMethod` instances, which shall behave like: ```ruby String.instance_method(:<<).destructive? # => true String.instance_method(:+).destructive? # => false ``` One main purpose of using these classes is to inspect and make sure how a certain method behaves. Besides arity and owner, whether a method is destructive or not is one important piece of information, but currently, you cannot achieve that from `Method` or `UnboundMethod` instances. -- https://bugs.ruby-lang.org/

9 14

[ruby-core:114617] [Ruby master Misc#19860] Update license phrases to SPDX BSD-2-Clause
by nobu (Nobuyoshi Nakada) 14 Sep '23

14 Sep '23

Issue #19860 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Misc #19860: Update license phrases to SPDX BSD-2-Clause https://bugs.ruby-lang.org/issues/19860 * Author: nobu (Nobuyoshi Nakada) * Status: Assigned * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- There seem to be many variations on the "2-clause BSDL" these days. The current BSDL file seems to be the old style of the BSD 2 Clause "Simplified" license (BSD-2-Clause), so I think we should clarify this and update it to a more [recent version]. [recent version]: https://spdx.org/licenses/BSD-2-Clause.html -- https://bugs.ruby-lang.org/

2 2

[ruby-core:114740] [Ruby master Bug#17354] Module#const_source_location is misleading for constants awaiting autoload
by matz (Yukihiro Matsumoto) 14 Sep '23

14 Sep '23

Issue #17354 has been updated by matz (Yukihiro Matsumoto). Currently, it gives the place we called `autoload`. If you want the place where the loaded module defined (after autoload), you can explicitly reference the module before calling `const_source_location`. So I vote for keeping it as it is now. Matz. ---------------------------------------- Bug #17354: Module#const_source_location is misleading for constants awaiting autoload https://bugs.ruby-lang.org/issues/17354#change-104575 * Author: tomstuart (Tom Stuart) * Status: Open * Priority: Normal * ruby -v: ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-darwin20] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- Feature #10771 added `Module#const_source_location` as a way to find the source location of a constant’s definition. Bug #16764 reported that it didn’t work correctly for autoloaded constants, instead giving the source location of the `autoload` call site. This was fixed in `v3_0_0_preview1` in commit:92730810 and backported to `v2_7_2` in commit:c65aae11. However, `#const_source_location` still returns the `autoload` call site for constants which have not yet been loaded: ``` % echo 'class Foo; end' > foo.rb % irb >> Module.const_defined?(:Foo) => false >> Module.const_source_location(:Foo) => nil >> autoload :Foo, './foo' => nil >> Module.const_defined?(:Foo) => true >> Module.const_source_location(:Foo) => ["(irb)", 3] >> Module.const_get(:Foo) => Foo >> Module.const_defined?(:Foo) => true >> Module.const_source_location(:Foo) => ["./foo.rb", 1] ``` This edge case is undocumented and surprising. It looks like a bug to the programmer who receives the `autoload` location instead of one of the documented return values of `#const_source_location` (`nil`, `[]`, or the definition’s source location). We could either: * change the behaviour of `#const_source_location` to return `[]` for constants awaiting autoload, which is consistent with the [return value of `Module#const_defined?`](https://docs.ruby-lang.org/en/2.7.0/Module.html#method-i-const_defined-3F) in this case (“if the constant is not present but there is an autoload for it, `true` is returned directly”), as well as the [return value of `#const_source_location`](https://docs.ruby-lang.org/en/2.7.0/Module.html#method-i-const_source_location) for other constants whose source location is unknown (“if the constant is found, but its source location can not be extracted (constant is defined in C code), empty array is returned”); or * document the current behaviour of `#const_source_location` to make it less surprising. I recommend the first option — although the current behaviour was recently specified in source:spec/ruby/core/module/const_source_location_spec.rb@6d059674#L209, it doesn’t seem intentional — but if that’s not feasible, simply documenting this edge case would also be an improvement. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114739] [Ruby master Bug#17146] Queue operations are allowed after it is frozen
by matz (Yukihiro Matsumoto) 14 Sep '23

14 Sep '23

Issue #17146 has been updated by matz (Yukihiro Matsumoto). Since frozen `queue` is meaningless, if you care about consistency, we should prohibit `freeze` queues, like `ENV`. Matz. ---------------------------------------- Bug #17146: Queue operations are allowed after it is frozen https://bugs.ruby-lang.org/issues/17146#change-104574 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * ruby -v: ruby 2.6.6p146 (2020-03-31 revision 67876) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- ``` [1] pry(main)> q = Queue.new => #<Thread::Queue:0x000056263683aee8> [2] pry(main)> q.freeze => #<Thread::Queue:0x000056263683aee8> [3] pry(main)> q << 1 => #<Thread::Queue:0x000056263683aee8> [4] pry(main)> q.pop => 1 [5] pry(main)> q.frozen? => true ``` Found by @ko1 in https://bugs.ruby-lang.org/issues/17100#note-28 I think it's a bug, since those are clear mutations. I guess old Thread::Queue implemented in Ruby did not have this bug. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114738] [Ruby master Feature#19075] Binary searching for the last element
by matz (Yukihiro Matsumoto) 14 Sep '23

14 Sep '23

Issue #19075 has been updated by matz (Yukihiro Matsumoto). Status changed from Open to Closed We reject `bsearch_last`, it's not intuitive (from my POV). If we come up with good name candidates, resubmit the proposal. Matz. ---------------------------------------- Feature #19075: Binary searching for the last element https://bugs.ruby-lang.org/issues/19075#change-104573 * Author: kyanagi (Kouhei Yanagita) * Status: Closed * Priority: Normal ---------------------------------------- My latest proposal is https://bugs.ruby-lang.org/issues/19075#note-6. I will leave the initial proposal below. --- PR: https://github.com/ruby/ruby/pull/6611 (I'm going to talk about `Array` here, but the same argument can be made for `Range`. If `Array#bsearch_last` is acceptable, I will work also for `Range`.) Ruby's bsearch returns the first element which satisfies the given block. ```ruby # Search the first element greater than 18 array = [10, 15, 20, 25] array.bsearch { |x| x > 18 } # => 20 ``` If we want the last element, we need to invert the condition and step backward. ```ruby # Search the last element less than 18 array = [10, 15, 20, 25] index = array.bsearch_index { |x| !(x < 18) } array[index-1] # => 15 ``` Of course, we need to consider `nil` and the boundary. ```ruby # Search the last element less than 100 index = array.bsearch_index { |x| !(x < 100) } # => nil if index.nil? array.last # => 25 else array[index-1] end ``` ```ruby # Search the last element less than 0 index = array.bsearch_index { |x| !(x < 0) } # => 0 if index.nil? array.last elsif index == 0 nil else array[index-1] end ``` This is where mistakes can easily be made, so I propose `Array#bsearch_last` and `Array#bsearch_last_index`. `Array#bsearch_last` returns the last element which satisfies the given block. `Array#bsearch` requires that all false-evaluating elements precede all true-evaluating elements. As is clear from the meaning of the method, conversely to `bsearch`, `bsearch_last` requires that all true-evaluating elements precede all false-evaluating elements. (If `bsearch_last` is acceptable, the name "find-minimum mode" should be changed.) ```ruby array = [10, 15, 20, 25] array.bsearch_last { |x| x < 18 } # => 15 array.bsearch_last { |x| x < 100 } # => 25 array.bsearch_last { |x| x < 0 } # => nil ``` There are several possible options for find-any mode. (1) `bsearch_last` does not support find-any mode. A block for `bsearch_last` must return `true`, `false` or `nil`. ``` [1, 2, 3].bsearch_last { 0 } # => TypeError ``` My pull request tentatively includes this implementation. (2) `bsearch_last` supports find-any mode and it behaves like `bsearch`. `bsearch` with find-any mode returns an element, for which the block returns zero. If multiple elements satisfy the condition, it is not determined which of them will be returned. It is conceivable that `bsearch_last` behaves in the same way as `bsearch`. ``` # current behavior # It is not specified whether `:b`, `:c`, or `:d` is returned. [[1,:a], [2, :b], [2, :c], [2, :d], [3, :e]].bsearch { |a, b| 2 <=> a } # => [2, :c] ``` (3) `bsearch_last` supports find-any mode and returns the last element. Make `bsearch` return the first element. Change the behavior of `bsearch` to return the first element for which the block returns zero. `bsearch_last` returns the last element for which the block returns zero. ``` # Change it like this: [[1,:a], [2, :b], [2, :c], [2, :d], [3, :e]].bsearch { |a, b| 2 <=> a } # => [2, :b] [[1,:a], [2, :b], [2, :c], [2, :d], [3, :e]].bsearch_last { |a, b| 2 <=> a } # => [2, :d] ``` (If this option is adopted, the name "find-any mode" should be renamed.) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114733] [Ruby master Bug#18257] rb_mRubyVMFrozenCore is broken by GC run
by vo.x (Vit Ondruch) 13 Sep '23

13 Sep '23

Issue #18257 has been updated by vo.x (Vit Ondruch). I don't think this is resolved, at least to the full extent. I trying again with the patch from comment #18257-13 and this is the results: ~~~ $ ./miniruby -v ruby 3.3.0dev (2023-09-05 master 7c8932365f) [x86_64-linux] $ ./miniruby -e "10000.times {[1].push[2]}" Before mark: RubyVM::FrozenCore After mark: RubyVM::FrozenCore Before sweep: RubyVM::FrozenCore After sweep: RubyVM::FrozenCore Before sweep: RubyVM::FrozenCore After sweep: RubyVM::FrozenCore Before sweep: RubyVM::FrozenCore After sweep: RubyVM::FrozenCore Before sweep: RubyVM::FrozenCore After sweep: RubyVM::FrozenCore Before sweep: RubyVM::FrozenCore After sweep: RubyVM::FrozenCore Before sweep: RubyVM::FrozenCore After sweep: RubyVM::FrozenCore Before sweep: RubyVM::FrozenCore Before sweep: RubyVM::FrozenCore Before sweep: RubyVM::FrozenCore Before sweep: RubyVM::FrozenCore Before mark: RubyVM::FrozenCore After mark: RubyVM::FrozenCore Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before mark: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After mark: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before mark: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After mark: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) Before sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) After sweep: OFFSETOF((*((struct rb_iseq_struct *)NULL)), aux) ~~~ Either the patch is completely off or something strange happens somewhere with the `rb_mRubyVMFrozenCore` ---------------------------------------- Bug #18257: rb_mRubyVMFrozenCore is broken by GC run https://bugs.ruby-lang.org/issues/18257#change-104568 * Author: vo.x (Vit Ondruch) * Status: Feedback * Priority: Normal * ruby -v: ruby 3.0.3p157 (2021-11-24 revision 3fb7d2cadc) [x86_64-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- Testing Ruby with SystemTap on RHEL9 beta following these steps: ~~~ $ stap -v /usr/share/doc/ruby-doc/ruby-exercise.stp & $ ruby -e '[1, 2, 3].push(4)' ~~~ I get the following error: ~~~ /usr/share/rubygems/rubygems/errors.rb:181: [BUG] Segmentation fault at 0x0000000000000014 ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [powerpc64le-linux] -- Control frame information ----------------------------------------------- c:0008 p:0028 s:0032 e:000027 CLASS /usr/share/rubygems/rubygems/errors.rb:181 c:0007 p:0110 s:0025 e:000024 CLASS /usr/share/rubygems/rubygems/errors.rb:153 c:0006 p:0007 s:0022 e:000021 TOP /usr/share/rubygems/rubygems/errors.rb:9 [FINISH] c:0005 p:---- s:0019 e:000018 CFUNC :require c:0004 p:0037 s:0014 e:000013 TOP /usr/share/rubygems/rubygems.rb:19 [FINISH] c:0003 p:---- s:0011 e:000010 CFUNC :require c:0002 p:0012 s:0006 e:000005 TOP <internal:gem_prelude>:2 [FINISH] c:0001 p:0000 s:0003 E:0026c0 (none) [FINISH] -- Ruby level backtrace information ---------------------------------------- <internal:gem_prelude>:2:in `<internal:gem_prelude>' <internal:gem_prelude>:2:in `require' /usr/share/rubygems/rubygems.rb:19:in `<top (required)>' /usr/share/rubygems/rubygems.rb:19:in `require' /usr/share/rubygems/rubygems/errors.rb:9:in `<top (required)>' /usr/share/rubygems/rubygems/errors.rb:153:in `<module:Gem>' /usr/share/rubygems/rubygems/errors.rb:181:in `<class:SourceFetchProblem>' -- C level backtrace information ------------------------------------------- /lib64/libruby.so.3.0(0x7fffb3b06ba0) [0x7fffb3b06ba0] /lib64/libruby.so.3.0(0x7fffb38d9680) [0x7fffb38d9680] /lib64/libruby.so.3.0(0x7fffb3a4b9d8) [0x7fffb3a4b9d8] linux-vdso64.so.1(__kernel_sigtramp_rt64+0x0) [0x7fffb3ca0464] [0x7fffb3a67ff8] /lib64/libruby.so.3.0(rb_str_dup+0x130) [0x7fffb3a6b950] /lib64/libruby.so.3.0(rb_class_path+0x3c) [0x7fffb3ac72ac] /lib64/libruby.so.3.0(rb_dtrace_setup+0x134) [0x7fffb3ae46a4] [0x7fffb3ae4a00] [0x7fffb3ae7644] [0x7fffb3aeba5c] /lib64/libruby.so.3.0(rb_vm_exec+0x140) [0x7fffb3af1710] /lib64/libruby.so.3.0(rb_iseq_eval+0x164) [0x7fffb3af29f4] [0x7fffb394ce68] /lib64/libruby.so.3.0(rb_require_string+0x44) [0x7fffb394e7f4] /lib64/libruby.so.3.0(rb_f_require+0x1c) [0x7fffb394e88c] [0x7fffb3acf538] [0x7fffb3ae4900] [0x7fffb3ae7644] [0x7fffb3aeba5c] /lib64/libruby.so.3.0(rb_vm_exec+0x140) [0x7fffb3af1710] /lib64/libruby.so.3.0(rb_iseq_eval+0x164) [0x7fffb3af29f4] [0x7fffb394ce68] /lib64/libruby.so.3.0(rb_require_string+0x44) [0x7fffb394e7f4] /lib64/libruby.so.3.0(rb_f_require+0x1c) [0x7fffb394e88c] [0x7fffb3acf538] [0x7fffb3ae4900] [0x7fffb3ae7644] [0x7fffb3aeba5c] /lib64/libruby.so.3.0(rb_vm_exec+0x140) [0x7fffb3af1710] /lib64/libruby.so.3.0(rb_iseq_eval+0x164) [0x7fffb3af29f4] [0x7fffb3b15f60] [0x7fffb3a4826c] [0x7fffb3a499d8] /lib64/libruby.so.3.0(ruby_process_options+0x158) [0x7fffb3a4a778] /lib64/libruby.so.3.0(ruby_options+0xf4) [0x7fffb38e5904] [0x11a360a60] [0x7fffb35d7ca4] [0x7fffb35d7e80] -- Other runtime information ----------------------------------------------- * Loaded script: ruby * Loaded features: 0 enumerator.so 1 thread.rb 2 rational.so 3 complex.so 4 ruby2_keywords.rb 5 /usr/lib64/ruby/enc/encdb.so 6 /usr/lib64/ruby/enc/trans/transdb.so 7 /usr/lib64/ruby/rbconfig.rb 8 /usr/share/rubygems/rubygems/compatibility.rb 9 /usr/share/rubygems/rubygems/defaults.rb 10 /usr/share/rubygems/rubygems/deprecate.rb * Process memory map: 11a360000-11a370000 r-xp 00000000 fd:00 34097694 /usr/bin/ruby 11a370000-11a380000 r--p 00000000 fd:00 34097694 /usr/bin/ruby 11a380000-11a390000 rw-p 00010000 fd:00 34097694 /usr/bin/ruby 1000d490000-1000d6b0000 rw-p 00000000 00:00 0 [heap] 7fffaf470000-7fffaf8d0000 r--s 00000000 fd:00 67811909 /usr/lib64/libruby.so.3.0.2 7fffaf8d0000-7fffaf8f0000 r--s 00000000 fd:00 34097694 /usr/bin/ruby 7fffaf8f0000-7fffaf900000 r-xp 00000000 fd:00 100999014 /usr/lib64/ruby/enc/trans/transdb.so 7fffaf900000-7fffaf910000 r--p 00000000 fd:00 100999014 /usr/lib64/ruby/enc/trans/transdb.so 7fffaf910000-7fffaf920000 rw-p 00000000 00:00 0 7fffaf920000-7fffaf930000 r-xp 00000000 fd:00 67811915 /usr/lib64/ruby/enc/encdb.so 7fffaf930000-7fffaf940000 r--p 00000000 fd:00 67811915 /usr/lib64/ruby/enc/encdb.so 7fffaf940000-7fffaf950000 rw-p 00000000 00:00 0 7fffaf950000-7fffaf960000 ---p 00000000 00:00 0 7fffaf960000-7fffafa10000 rw-p 00000000 00:00 0 7fffafa10000-7fffafa20000 ---p 00000000 00:00 0 7fffafa20000-7fffafad0000 rw-p 00000000 00:00 0 7fffafad0000-7fffafae0000 ---p 00000000 00:00 0 7fffafae0000-7fffafb90000 rw-p 00000000 00:00 0 7fffafb90000-7fffafba0000 ---p 00000000 00:00 0 7fffafba0000-7fffafc50000 rw-p 00000000 00:00 0 7fffafc50000-7fffafc60000 ---p 00000000 00:00 0 7fffafc60000-7fffafd10000 rw-p 00000000 00:00 0 7fffafd10000-7fffafd20000 ---p 00000000 00:00 0 7fffafd20000-7fffafdd0000 rw-p 00000000 00:00 0 7fffafdd0000-7fffafde0000 ---p 00000000 00:00 0 7fffafde0000-7fffafe90000 rw-p 00000000 00:00 0 7fffafe90000-7fffafea0000 ---p 00000000 00:00 0 7fffafea0000-7fffaff50000 rw-p 00000000 00:00 0 7fffaff50000-7fffaff60000 ---p 00000000 00:00 0 7fffaff60000-7fffb0010000 rw-p 00000000 00:00 0 7fffb0010000-7fffb0020000 ---p 00000000 00:00 0 7fffb0020000-7fffb00d0000 rw-p 00000000 00:00 0 7fffb00d0000-7fffb00e0000 ---p 00000000 00:00 0 7fffb00e0000-7fffb0190000 rw-p 00000000 00:00 0 7fffb0190000-7fffb01a0000 ---p 00000000 00:00 0 7fffb01a0000-7fffb0250000 rw-p 00000000 00:00 0 7fffb0250000-7fffb0260000 ---p 00000000 00:00 0 7fffb0260000-7fffb0310000 rw-p 00000000 00:00 0 7fffb0310000-7fffb0320000 ---p 00000000 00:00 0 7fffb0320000-7fffb03d0000 rw-p 00000000 00:00 0 7fffb03d0000-7fffb03e0000 ---p 00000000 00:00 0 7fffb03e0000-7fffb0490000 rw-p 00000000 00:00 0 7fffb0490000-7fffb04a0000 ---p 00000000 00:00 0 7fffb04a0000-7fffb0550000 rw-p 00000000 00:00 0 7fffb0550000-7fffb0560000 ---p 00000000 00:00 0 7fffb0560000-7fffb0610000 rw-p 00000000 00:00 0 7fffb0610000-7fffb0620000 ---p 00000000 00:00 0 7fffb0620000-7fffb06d0000 rw-p 00000000 00:00 0 7fffb06d0000-7fffb06e0000 ---p 00000000 00:00 0 7fffb06e0000-7fffb0790000 rw-p 00000000 00:00 0 7fffb0790000-7fffb07a0000 ---p 00000000 00:00 0 7fffb07a0000-7fffb0850000 rw-p 00000000 00:00 0 7fffb0850000-7fffb0860000 ---p 00000000 00:00 0 7fffb0860000-7fffb0910000 rw-p 00000000 00:00 0 7fffb0910000-7fffb0920000 ---p 00000000 00:00 0 7fffb0920000-7fffb09d0000 rw-p 00000000 00:00 0 7fffb09d0000-7fffb09e0000 ---p 00000000 00:00 0 7fffb09e0000-7fffb0a90000 rw-p 00000000 00:00 0 7fffb0a90000-7fffb0aa0000 ---p 00000000 00:00 0 7fffb0aa0000-7fffb0b50000 rw-p 00000000 00:00 0 7fffb0b50000-7fffb0b60000 ---p 00000000 00:00 0 7fffb0b60000-7fffb0c10000 rw-p 00000000 00:00 0 7fffb0c10000-7fffb0c20000 ---p 00000000 00:00 0 7fffb0c20000-7fffb0cd0000 rw-p 00000000 00:00 0 7fffb0cd0000-7fffb0ce0000 ---p 00000000 00:00 0 7fffb0ce0000-7fffb0d90000 rw-p 00000000 00:00 0 7fffb0d90000-7fffb0da0000 ---p 00000000 00:00 0 7fffb0da0000-7fffb0e50000 rw-p 00000000 00:00 0 7fffb0e50000-7fffb0e60000 ---p 00000000 00:00 0 7fffb0e60000-7fffb0f10000 rw-p 00000000 00:00 0 7fffb0f10000-7fffb0f20000 ---p 00000000 00:00 0 7fffb0f20000-7fffb0fd0000 rw-p 00000000 00:00 0 7fffb0fd0000-7fffb0fe0000 ---p 00000000 00:00 0 7fffb0fe0000-7fffb1090000 rw-p 00000000 00:00 0 7fffb1090000-7fffb10a0000 ---p 00000000 00:00 0 7fffb10a0000-7fffb32e0000 rw-p 00000000 00:00 0 7fffb32e0000-7fffb3340000 r--p 00000000 fd:00 33555845 /usr/lib/locale/en_US.utf8/LC_CTYPE 7fffb3340000-7fffb3420000 r-xp 00000000 fd:00 67172714 /usr/lib64/libm.so.6 7fffb3420000-7fffb3430000 r--p 000d0000 fd:00 67172714 /usr/lib64/libm.so.6 7fffb3430000-7fffb3440000 rw-p 000e0000 fd:00 67172714 /usr/lib64/libm.so.6 7fffb3440000-7fffb3480000 r-xp 00000000 fd:00 67172871 /usr/lib64/libcrypt.so.2.0.0 7fffb3480000-7fffb3490000 r--p 00030000 fd:00 67172871 /usr/lib64/libcrypt.so.2.0.0 7fffb3490000-7fffb34a0000 rw-p 00000000 00:00 0 7fffb34a0000-7fffb3540000 r-xp 00000000 fd:00 67172912 /usr/lib64/libgmp.so.10.4.0 7fffb3540000-7fffb3550000 r--p 00090000 fd:00 67172912 /usr/lib64/libgmp.so.10.4.0 7fffb3550000-7fffb3560000 rw-p 000a0000 fd:00 67172912 /usr/lib64/libgmp.so.10.4.0 7fffb3560000-7fffb3580000 r-xp 00000000 fd:00 67172832 /usr/lib64/libz.so.1.2.11 7fffb3580000-7fffb3590000 r--p 00010000 fd:00 67172832 /usr/lib64/libz.so.1.2.11 7fffb3590000-7fffb35a0000 rw-p 00020000 fd:00 67172832 /usr/lib64/libz.so.1.2.11 7fffb35a0000-7fffb37e0000 r-xp 00000000 fd:00 67172711 /usr/lib64/libc.so.6 7fffb37e0000-7fffb37f0000 r--p 00230000 fd:00 67172711 /usr/lib64/libc.so.6 7fffb37f0000-7fffb3800000 rw-p 00240000 fd:00 67172711 /usr/lib64/libc.so.6 7fffb3800000-7fffb3c30000 r-xp 00000000 fd:00 67811909 /usr/lib64/libruby.so.3.0.2 7fffb3c30000-7fffb3c40000 ---p 00430000 fd:00 67811909 /usr/lib64/libruby.so.3.0.2 7fffb3c40000-7fffb3c50000 r--p 00430000 fd:00 67811909 /usr/lib64/libruby.so.3.0.2 7fffb3c50000-7fffb3c60000 rw-p 00440000 fd:00 67811909 /usr/lib64/libruby.so.3.0.2 7fffb3c60000-7fffb3c70000 rw-p 00000000 00:00 0 7fffb3c70000-7fffb3c80000 r--s 00000000 fd:00 100673889 /usr/lib64/gconv/gconv-modules.cache 7fffb3c80000-7fffb3ca0000 r--p 00000000 00:00 0 [vvar] 7fffb3ca0000-7fffb3cb0000 r-xp 00000000 00:00 0 [vdso] 7fffb3cb0000-7fffb3d00000 r-xp 00000000 fd:00 67172707 /usr/lib64/ld64.so.2 7fffb3d00000-7fffb3d10000 r--p 00040000 fd:00 67172707 /usr/lib64/ld64.so.2 7fffb3d10000-7fffb3d20000 rw-p 00050000 fd:00 67172707 /usr/lib64/ld64.so.2 7fffdee00000-7fffdf600000 rw-p 00000000 00:00 0 [stack] ~~~ This should be the full BT: ~~~ (gdb) bt #0 0x00007fffa5711550 in uleb128 (p=0x10039917f10) at addr2line.c:200 #1 di_read_die (reader=reader@entry=0x10039917eb8, die=die@entry=0x10039917dc8) at addr2line.c:1343 #2 0x00007fffa5714574 in debug_info_read (offset=<optimized out>, lines=<optimized out>, traces=<optimized out>, num_traces=<optimized out>, reader=<optimized out>) at addr2line.c:1630 #3 fill_lines (num_traces=num_traces@entry=39, traces=traces@entry=0x7fffa585d778 <trace>, check_debuglink=check_debuglink@entry=0, objp=objp@entry=0x10039919370, lines=lines@entry=0x100399756f0, offset=<optimized out>, offset@entry=0) at addr2line.c:1887 #4 0x00007fffa5714f28 in follow_debuglink (offset=0, lines=0x100399756f0, objp=0x10039919370, traces=<optimized out>, num_traces=39, debuglink=0x7fffa14e01e4 "ruby-3.0.2-155.el9.ppc64le.debug") at addr2line.c:574 #5 fill_lines (num_traces=num_traces@entry=39, traces=traces@entry=0x7fffa585d778 <trace>, check_debuglink=check_debuglink@entry=1, objp=0x10039919370, objp@entry=0x100399193f0, lines=lines@entry=0x100399756f0, offset=<optimized out>, offset@entry=-1) at addr2line.c:1925 #6 0x00007fffa571576c in rb_dump_backtrace_with_lines (num_traces=<optimized out>, traces=0x7fffa585d778 <trace>) at addr2line.c:2286 #7 0x00007fffa5706bac in rb_print_backtrace () at vm_dump.c:760 #8 rb_vm_bugreport (ctx=<optimized out>) at vm_dump.c:998 #9 0x00007fffa54d9680 in rb_bug_for_fatal_signal (default_sighandler=0x0, sig=<optimized out>, ctx=0x100399197c0, fmt=0x7fffa574e8f0 "Segmentation fault at %p") at error.c:786 #10 0x00007fffa564b9d8 in sigsegv (sig=<optimized out>, info=0x1003991a540, ctx=0x100399197c0) at signal.c:960 #11 <signal handler called> #12 0x00007fffa5667ff8 in str_new_frozen_buffer (klass=klass@entry=1100477014720, orig=orig@entry=1100476844400, copy_encoding=copy_encoding@entry=1) at string.c:1329 #13 0x00007fffa566b950 in str_new_frozen (orig=1100476844400, klass=1100477014720) at string.c:1297 #14 str_duplicate_setup (dup=1100478149120, str=1100476844400, klass=1100477014720) at string.c:1570 #15 str_duplicate (str=1100476844400, klass=1100477014720) at string.c:1602 #16 rb_str_dup (str=1100476844400) at string.c:1608 #17 0x00007fffa56c72ac in rb_class_path (klass=1100476844480) at variable.c:173 #18 0x00007fffa56e46a4 in rb_dtrace_setup (ec=<optimized out>, klass=1100476844480, id=159, args=0x7fffe9d953d8) at vm.c:449 #19 0x00007fffa56e4a00 in vm_call_cfunc_with_frame (ec=<optimized out>, reg_cfp=0x7fffa4ecfe50, calling=<optimized out>) at vm_insnhelper.c:2916 #20 0x00007fffa56e7644 in vm_sendish (ec=0x10039811cf0, reg_cfp=0x7fffa4ecfe50, cd=0x100399a8db0, block_handler=<optimized out>, method_explorer=<optimized out>) at vm_callinfo.h:336 #21 0x00007fffa56eba5c in vm_exec_core (ec=0x10039811cf0, initial=<optimized out>, initial@entry=0) at insns.def:789 #22 0x00007fffa56f1710 in rb_vm_exec (ec=0x10039811cf0, mjit_enable_p=<optimized out>) at vm.c:2172 #23 0x00007fffa56f29f4 in rb_iseq_eval (iseq=0x100398aa7c0) at vm.c:2409 #24 0x00007fffa554ce68 in load_iseq_eval (fname=1100477137480, ec=0x10039811cf0) at load.c:594 #25 require_internal (ec=ec@entry=0x10039811cf0, fname=<optimized out>, fname@entry=1100476430040, exception=exception@entry=1) at load.c:1065 #26 0x00007fffa554e7f4 in rb_require_string (fname=1100476430040) at load.c:1142 #27 0x00007fffa554e88c in rb_f_require (obj=<optimized out>, fname=<optimized out>) at load.c:838 #28 0x00007fffa56cf538 in ractor_safe_call_cfunc_1 (recv=<optimized out>, argc=<optimized out>, argv=<optimized out>, func=<optimized out>) at vm_insnhelper.c:2750 #29 0x00007fffa56e4900 in vm_call_cfunc_with_frame (ec=0x10039811cf0, reg_cfp=0x7fffa4ecff30, calling=<optimized out>) at vm_insnhelper.c:2926 #30 0x00007fffa56e7644 in vm_sendish (ec=0x10039811cf0, reg_cfp=0x7fffa4ecff30, cd=0x10039901e50, block_handler=<optimized out>, method_explorer=<optimized out>) at vm_callinfo.h:336 #31 0x00007fffa56eba5c in vm_exec_core (ec=0x10039811cf0, initial=<optimized out>, initial@entry=0) at insns.def:789 #32 0x00007fffa56f1710 in rb_vm_exec (ec=0x10039811cf0, mjit_enable_p=<optimized out>) at vm.c:2172 #33 0x00007fffa56f29f4 in rb_iseq_eval (iseq=0x1003981b9a8) at vm.c:2409 #34 0x00007fffa554ce68 in load_iseq_eval (fname=1100476613760, ec=0x10039811cf0) at load.c:594 #35 require_internal (ec=ec@entry=0x10039811cf0, fname=<optimized out>, fname@entry=1100476614040, exception=exception@entry=1) at load.c:1065 #36 0x00007fffa554e7f4 in rb_require_string (fname=1100476614040) at load.c:1142 #37 0x00007fffa554e88c in rb_f_require (obj=<optimized out>, fname=<optimized out>) at load.c:838 #38 0x00007fffa56cf538 in ractor_safe_call_cfunc_1 (recv=<optimized out>, argc=<optimized out>, argv=<optimized out>, func=<optimized out>) at vm_insnhelper.c:2750 #39 0x00007fffa56e4900 in vm_call_cfunc_with_frame (ec=0x10039811cf0, reg_cfp=0x7fffa4ecffa0, calling=<optimized out>) at vm_insnhelper.c:2926 #40 0x00007fffa56e7644 in vm_sendish (ec=0x10039811cf0, reg_cfp=0x7fffa4ecffa0, cd=0x10039970580, block_handler=<optimized out>, method_explorer=<optimized out>) at vm_callinfo.h:336 #41 0x00007fffa56eba5c in vm_exec_core (ec=0x10039811cf0, initial=<optimized out>, initial@entry=0) at insns.def:789 #42 0x00007fffa56f1710 in rb_vm_exec (ec=0x10039811cf0, mjit_enable_p=<optimized out>) at vm.c:2172 #43 0x00007fffa56f29f4 in rb_iseq_eval (iseq=0x100398489f8) at vm.c:2409 #44 0x00007fffa5715f60 in rb_load_with_builtin_functions (feature_name=0x7fffa57b61c0 "gem_prelude", table=0x0) at builtin.c:54 #45 0x00007fffa564826c in ruby_init_prelude () at ruby.c:1498 #46 ruby_opt_init (opt=0x7fffe9d98690) at ruby.c:1521 #47 ruby_opt_init (opt=0x7fffe9d98690) at ruby.c:1506 #48 0x00007fffa56499d8 in process_options (argc=0, argc@entry=3, argv=0x7fffe9d98f10, argv@entry=0x7fffe9d98ef8, opt=opt@entry=0x7fffe9d98690) at ruby.c:1951 #49 0x00007fffa564a778 in ruby_process_options (argc=<optimized out>, argv=0x7fffe9d98ef8) at ruby.c:230 #50 0x00007fffa54e5904 in ruby_options (argc=<optimized out>, argv=0x7fffe9d98ef8) at eval.c:138 #51 0x000000010b860a60 in main (argc=<optimized out>, argv=<optimized out>) at ./main.c:50 ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114732] [Ruby master Bug#17354] Module#const_source_location is misleading for constants awaiting autoload
by mame (Yusuke Endoh) 13 Sep '23

13 Sep '23

Issue #17354 has been updated by mame (Yusuke Endoh). I said this could be useful for debugging. If a user finds a call to `autoload` on the line pointed to by `const_source_location`, they can guess that autoload is set. If they want to know the actual definition location, they can actually access it and then use `const_source_location`. The current behavior allows the user to choose these. In that sense, I think the current behavior is flexible. If `const_source_location` triggers autoload, not only is this flexibility lost, but loading may cause side effects, which may be inconvenient for a debugging purpose. ---------------------------------------- Bug #17354: Module#const_source_location is misleading for constants awaiting autoload https://bugs.ruby-lang.org/issues/17354#change-104567 * Author: tomstuart (Tom Stuart) * Status: Open * Priority: Normal * ruby -v: ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-darwin20] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- Feature #10771 added `Module#const_source_location` as a way to find the source location of a constant’s definition. Bug #16764 reported that it didn’t work correctly for autoloaded constants, instead giving the source location of the `autoload` call site. This was fixed in `v3_0_0_preview1` in commit:92730810 and backported to `v2_7_2` in commit:c65aae11. However, `#const_source_location` still returns the `autoload` call site for constants which have not yet been loaded: ``` % echo 'class Foo; end' > foo.rb % irb >> Module.const_defined?(:Foo) => false >> Module.const_source_location(:Foo) => nil >> autoload :Foo, './foo' => nil >> Module.const_defined?(:Foo) => true >> Module.const_source_location(:Foo) => ["(irb)", 3] >> Module.const_get(:Foo) => Foo >> Module.const_defined?(:Foo) => true >> Module.const_source_location(:Foo) => ["./foo.rb", 1] ``` This edge case is undocumented and surprising. It looks like a bug to the programmer who receives the `autoload` location instead of one of the documented return values of `#const_source_location` (`nil`, `[]`, or the definition’s source location). We could either: * change the behaviour of `#const_source_location` to return `[]` for constants awaiting autoload, which is consistent with the [return value of `Module#const_defined?`](https://docs.ruby-lang.org/en/2.7.0/Module.html#method-i-const_defined-3F) in this case (“if the constant is not present but there is an autoload for it, `true` is returned directly”), as well as the [return value of `#const_source_location`](https://docs.ruby-lang.org/en/2.7.0/Module.html#method-i-const_source_location) for other constants whose source location is unknown (“if the constant is found, but its source location can not be extracted (constant is defined in C code), empty array is returned”); or * document the current behaviour of `#const_source_location` to make it less surprising. I recommend the first option — although the current behaviour was recently specified in source:spec/ruby/core/module/const_source_location_spec.rb@6d059674#L209, it doesn’t seem intentional — but if that’s not feasible, simply documenting this edge case would also be an improvement. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114731] [Ruby master Bug#17354] Module#const_source_location is misleading for constants awaiting autoload
by sawa (Tsuyoshi Sawada) 13 Sep '23

13 Sep '23

Issue #17354 has been updated by sawa (Tsuyoshi Sawada). mame (Yusuke Endoh) wrote in #note-16: > Why do you want to know the location of the autoload call after it is actually loaded? I do not know. I do not understand in the first place your use case where you want to identify where a constant is set as autoload. > I guess that information is already gone from the runtime as well. I see. ---------------------------------------- Bug #17354: Module#const_source_location is misleading for constants awaiting autoload https://bugs.ruby-lang.org/issues/17354#change-104565 * Author: tomstuart (Tom Stuart) * Status: Open * Priority: Normal * ruby -v: ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-darwin20] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- Feature #10771 added `Module#const_source_location` as a way to find the source location of a constant’s definition. Bug #16764 reported that it didn’t work correctly for autoloaded constants, instead giving the source location of the `autoload` call site. This was fixed in `v3_0_0_preview1` in commit:92730810 and backported to `v2_7_2` in commit:c65aae11. However, `#const_source_location` still returns the `autoload` call site for constants which have not yet been loaded: ``` % echo 'class Foo; end' > foo.rb % irb >> Module.const_defined?(:Foo) => false >> Module.const_source_location(:Foo) => nil >> autoload :Foo, './foo' => nil >> Module.const_defined?(:Foo) => true >> Module.const_source_location(:Foo) => ["(irb)", 3] >> Module.const_get(:Foo) => Foo >> Module.const_defined?(:Foo) => true >> Module.const_source_location(:Foo) => ["./foo.rb", 1] ``` This edge case is undocumented and surprising. It looks like a bug to the programmer who receives the `autoload` location instead of one of the documented return values of `#const_source_location` (`nil`, `[]`, or the definition’s source location). We could either: * change the behaviour of `#const_source_location` to return `[]` for constants awaiting autoload, which is consistent with the [return value of `Module#const_defined?`](https://docs.ruby-lang.org/en/2.7.0/Module.html#method-i-const_defined-3F) in this case (“if the constant is not present but there is an autoload for it, `true` is returned directly”), as well as the [return value of `#const_source_location`](https://docs.ruby-lang.org/en/2.7.0/Module.html#method-i-const_source_location) for other constants whose source location is unknown (“if the constant is found, but its source location can not be extracted (constant is defined in C code), empty array is returned”); or * document the current behaviour of `#const_source_location` to make it less surprising. I recommend the first option — although the current behaviour was recently specified in source:spec/ruby/core/module/const_source_location_spec.rb@6d059674#L209, it doesn’t seem intentional — but if that’s not feasible, simply documenting this edge case would also be an improvement. -- https://bugs.ruby-lang.org/

1 0