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

[ruby-core:114862] [Ruby master Feature#13933] Add Range#empty?
by akr (Akira Tanaka) 21 Sep '23

21 Sep '23

Issue #13933 has been updated by akr (Akira Tanaka). I described that this is difficult to implement in https://bugs.ruby-lang.org/issues/19839#note-18. The problem is not only with -Float::INFINITY. There are many minimum values other than -Float::INFINITY : [], "", true, false, Object.new, etc. Of course, a user may define a class with a minimum value. Range#empty? should work with them. ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104710 * Author: ted (Ted Johansson) * Status: Open * Priority: Normal ---------------------------------------- Range already responds to #size. It would be nice if it also responded to predicate #empty? :-) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114332] [Ruby master Bug#19794] Ruby 3.2.2 fails to build on macOS Sonoma betas
by jhaungs (Jim Haungs) 21 Sep '23

21 Sep '23

Issue #19794 has been reported by jhaungs (Jim Haungs). ---------------------------------------- Bug #19794: Ruby 3.2.2 fails to build on macOS Sonoma betas https://bugs.ruby-lang.org/issues/19794 * Author: jhaungs (Jim Haungs) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- With Big Sur, Apple deprecated putting dylibs in /usr/local/lib. In Sonoma (beta 4), this directory has disappeared completely. However, ruby's configure script depends on its existence. So, virtually every ruby installer (RVM, rbenv, asdf, ruby-build, and even building from source tarball) fails. When building ruby 3.2.2 from source, the configure step outputs the irritatingly useless "something wrong with LDFLAGS" error message and fails to build. The solution was to `cd /usr/local; sudo mkdir lib` to create the missing lib directory under /usr/local. It would be nice to remove this dependency from the configure script. -- https://bugs.ruby-lang.org/

5 6

[ruby-core:114855] [Ruby master Feature#13933] Add Range#empty?
by Dan0042 (Daniel DeLorme) 21 Sep '23

21 Sep '23

Issue #13933 has been updated by Dan0042 (Daniel DeLorme). It was an ad-hoc example that just seemed to me like it should return true. As to how to define it... maybe we can say that numeric ranges are equivalent to `begin == -Float::INFINITY` if beginless, and `end == +Float::INFINITY` if endless. Then it would be like saying `(k...k).empty?` with `k == -Float::INFINITY` ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104702 * Author: ted (Ted Johansson) * Status: Open * Priority: Normal ---------------------------------------- Range already responds to #size. It would be nice if it also responded to predicate #empty? :-) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114853] [Ruby master Feature#13933] Add Range#empty?
by nobu (Nobuyoshi Nakada) 21 Sep '23

21 Sep '23

Issue #13933 has been updated by nobu (Nobuyoshi Nakada). Dan0042 (Daniel DeLorme) wrote in #note-5: > ```ruby > (...-Float::INFINITY).empty? #=> true > ``` How do you define this? `Range#empty?` must know if the element is a `Float`, and negative infinity? ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104699 * Author: ted (Ted Johansson) * Status: Open * Priority: Normal ---------------------------------------- Range already responds to #size. It would be nice if it also responded to predicate #empty? :-) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114846] [Ruby master Bug#19895] Memory leak in Ripper#sexp_raw called with invalid syntax
by jemmai (Jemma Issroff) 20 Sep '23

20 Sep '23

Issue #19895 has been reported by jemmai (Jemma Issroff). ---------------------------------------- Bug #19895: Memory leak in Ripper#sexp_raw called with invalid syntax https://bugs.ruby-lang.org/issues/19895 * Author: jemmai (Jemma Issroff) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- There is a memory leak in `Ripper#sexp_raw` with invalid syntax I used [the ruby_memcheck gem](https://github.com/Shopify/ruby_memcheck) to find this leak. # Script to reproduce: ``` $ ruby_memcheck -e 'require "ripper"; Ripper.sexp_raw("break 1,;")' ``` # Stack trace ``` 64 bytes in 1 blocks are definitely lost in loss record 8,335 of 11,879 malloc (at /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) objspace_xmalloc0 (gc.c:11465) *vtable_alloc_gen (ripper.y:6209) *local_push.constprop.0 (ripper.y:12587) *ripper_yyparse (ripper.y:1329) *ripper_parse0 (ripper.y:13817) rb_ensure (eval.c:997) *ripper_parse (ripper.y:13855) vm_call_cfunc_with_frame (vm_insnhelper.c:3037) vm_sendish (vm_insnhelper.c:4751) vm_exec_core (insns.def:778) rb_vm_exec (vm.c:2220) rb_ec_exec_node (eval.c:280) ruby_run_node (eval.c:321) main (main.c:47) 88 (24 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 8,508 of 11,879 malloc (at /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) objspace_xmalloc0 (gc.c:11465) *vtable_alloc_gen (ripper.y:6206) *local_push.constprop.0 (ripper.y:12586) *ripper_yyparse (ripper.y:1329) *ripper_parse0 (ripper.y:13817) rb_ensure (eval.c:997) *ripper_parse (ripper.y:13855) vm_call_cfunc_with_frame (vm_insnhelper.c:3037) vm_sendish (vm_insnhelper.c:4751) vm_exec_core (insns.def:778) rb_vm_exec (vm.c:2220) rb_ec_exec_node (eval.c:280) ruby_run_node (eval.c:321) main (main.c:47) Valgrind reported errors (e.g. memory leak or use-after-free) (RuntimeError) ``` # Expected behavior The [`Ripper#sexp_raw` docs](https://docs.ruby-lang.org/en/master/Ripper.html#method-c-sexp_raw) state that "By default, this method does not handle syntax errors in src, returning nil in such cases." Expected behavior, according to the documentation, would be `nil` returned without any memory leak -- https://bugs.ruby-lang.org/

1 1

[ruby-core:114845] [Ruby master Feature#13933] Add Range#empty?
by Dan0042 (Daniel DeLorme) 20 Sep '23

20 Sep '23

Issue #13933 has been updated by Dan0042 (Daniel DeLorme). Since 6 years ago, beginless and endless ranges have been added, so `#none?` is no longer sufficient. ```ruby (nil..0).none? #=> TypeError (can't iterate from NilClass) ``` And as mentioned above `Range#size` doesn't work for String ranges. So I think it would be good to have `Range#empty?`, with cover-based semantics rather than succ-based: ```ruby (1..0).empty? #=> true (1..1).empty? #=> false (1...1).empty? #=> true ("a".."b").empty? #=> false ("b".."a").empty? #=> true (nil..0).empty? #=> false (..-Float::INFINITY).empty? #=> false (...-Float::INFINITY).empty? #=> true ``` ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104692 * Author: ted (Ted Johansson) * Status: Open * Priority: Normal ---------------------------------------- Range already responds to #size. It would be nice if it also responded to predicate #empty? :-) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113381] [Ruby master Bug#19624] Backticks - IO object leakage
by pineman 20 Sep '23

20 Sep '23

Issue #19624 has been reported by pineman (João Pinheiro). ---------------------------------------- Bug #19624: Backticks - IO object leakage https://bugs.ruby-lang.org/issues/19624 * Author: pineman (João Pinheiro) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hi, This code works on ruby 3.0.6: ```ruby `echo` ObjectSpace.each_object(IO) do |io| if ![STDIN, STDOUT, STDERR].include?(io) io.close end end ``` but raises `IOError` on 3.2.2: ``` minimal-repro-case.rb:8:in `close': uninitialized stream (IOError) ``` I found it started failing on ruby 3.1.0 and after, on macOS and Linux. This code is useful for closing unneeded IO objects in forked processes. It looks like backticks is 'leaking' IO objects, waiting for GC, and it didn't used to in 3.1.0. In ruby 3.1.0, inside `rb_f_backquote`, `rb_gc_force_recycle` was removed in favor of `RB_GC_GUARD`. I wonder if this has something to do with the problem. Is this code incorrect since ruby 3.1.0 or is it a bug in ruby? Thanks. ---Files-------------------------------- minimal-repro-case.rb (109 Bytes) -- https://bugs.ruby-lang.org/

4 9

[ruby-core:114824] [Ruby master Bug#4040] SystemStackError with Hash[*a] for Large _a_
by tenderlovemaking (Aaron Patterson) 20 Sep '23

20 Sep '23

Issue #4040 has been updated by tenderlovemaking (Aaron Patterson). Hi, We (on the YJIT team) have been tracking Ruby performance. We usually look at YJIT performance as compared to the interpreter, but recently we started looking at interpreter performance (it's getting later in the year so we want to make sure things look good for the release). We noticed there was a degradation in interpreter performance in April, and I tracked the issue to this commit. We were specifically looking at [the chunky png benchmark](https://github.com/Shopify/yjit-bench/blob/main/benchmarks/chunk…. If you check [this graph](https://rubybench.github.io/benchmarks/yjit-bench.html#chunky_png) then click "Time" on the bottom, you can see the increase in time in April. Running `perf stat` on the benchmark shows this commit increases the executed instructions from 232,171,088,239 to 244,008,191,171. Here is the `perf stat` results I got for e7cdce83e8: ``` Performance counter stats for 'ruby -v benchmark.rb': 18,995.65 msec task-clock # 1.000 CPUs utilized 68 context-switches # 3.580 /sec 1 cpu-migrations # 0.053 /sec 33,003 page-faults # 1.737 K/sec 82,022,881,262 cycles # 4.318 GHz (83.32%) 449,576,108 stalled-cycles-frontend # 0.55% frontend cycles idle (83.32%) 21,629,264,292 stalled-cycles-backend # 26.37% backend cycles idle (83.33%) 232,171,088,239 instructions # 2.83 insn per cycle # 0.09 stalled cycles per insn (83.35%) 40,092,228,662 branches # 2.111 G/sec (83.37%) 76,492,242 branch-misses # 0.19% of all branches (83.34%) 18.997823376 seconds time elapsed 18.904486000 seconds user 0.091909000 seconds sys ``` vs `perf stat` for 99c6d19e50 ``` Performance counter stats for 'ruby -v benchmark.rb': 19,415.14 msec task-clock # 1.000 CPUs utilized 66 context-switches # 3.399 /sec 2 cpu-migrations # 0.103 /sec 38,513 page-faults # 1.984 K/sec 82,876,137,933 cycles # 4.269 GHz (83.32%) 577,427,117 stalled-cycles-frontend # 0.70% frontend cycles idle (83.33%) 20,414,833,187 stalled-cycles-backend # 24.63% backend cycles idle (83.35%) 244,008,191,171 instructions # 2.94 insn per cycle # 0.08 stalled cycles per insn (83.37%) 41,385,015,387 branches # 2.132 G/sec (83.35%) 76,702,379 branch-misses # 0.19% of all branches (83.32%) 19.417447024 seconds time elapsed 19.346844000 seconds user 0.068922000 seconds sys ``` It's cool we could fix a 13 year old bug, but given the "rarity" of this issue I'm not sure it's worth the slowdown? 😅 I will try to find some way to speed this up, but I'm not sure if I'll have time. In case someone has time to look, the way to reproduce this is by checking out [yjit-bench](https://github.com/shopify/yjit-bench) then running [the chunky-png benchmark](https://github.com/Shopify/yjit-bench/blob/main/benchmarks/chunk… like this: `perf stat ruby -v benchmark.rb` ---------------------------------------- Bug #4040: SystemStackError with Hash[*a] for Large _a_ https://bugs.ruby-lang.org/issues/4040#change-104668 * Author: runpaint (Run Paint Run Run) * Status: Closed * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 1.9.3dev (2010-11-09 trunk 29737) [x86_64-linux] * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- =begin I've been hesitating over whether to file a ticket about this, so please feel free to close if I've made the wrong choice. I often use Hash[*array.flatten] in IRB to convert arrays of arrays into hashes. Today I noticed that if the array is big enough, this would raise a SystemStackError. Puzzled, I looked deeper. I assumed I was hitting the maximum number of arguments a method's argc can hold, but realised that the minimum size of the array needed to trigger this exception differed depending on whether I used IRB or not. So, presumably this is indeed exhausting the stack... In IRB, the following is the minimal reproduction of this problem: Hash[*130648.times.map{ 1 }]; true I haven't looked for the minimum value needed with `ruby -e`, but the following reproduces: ruby -e 'Hash[*1380888.times.map{ 1 }]' I suppose this isn't technically a bug, but maybe it offers another argument for either #666 or an extension of #3131. =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114814] [Ruby master Bug#19891] rb_mRubyVMFrozenCore is reported by DTrace but ignored by TracePoint
by vo.x (Vit Ondruch) 19 Sep '23

19 Sep '23

Issue #19891 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19891: rb_mRubyVMFrozenCore is reported by DTrace but ignored by TracePoint https://bugs.ruby-lang.org/issues/19891 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-09-05 master 7c8932365f) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This is related to #18257 where I wonder why rb_mRubyVMFrozenCore is ignored by TracePoint (if I am not mistaken) [1]: ~~~ if (ec->trace_arg == NULL && /* check reentrant */ trace_arg->self != rb_mRubyVMFrozenCore /* skip special methods. TODO: remove it. */) { ~~~ This was introduced in commit:git|1be7c799e6ed39f7ac41906c05db149e8c391add but hard to guess what was the reason. If there were issues similar to @18257 or if it is by design. The `TODO` part was introduced by commit:git|4a4a702e61d1c5585d522f1185a82a5685c554f6 which also does not give a clue what is intention here. Generally, my point is that it is strange that DTrace would report about rb_mRubyVMFrozenCore while TracePoint is happy to skip it. [1]: https://github.com/ruby/ruby/blob/647390308239fbf82d159ecd83ed8df090af518d/… -- https://bugs.ruby-lang.org/

2 1

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

19 Sep '23

Issue #18257 has been updated by vo.x (Vit Ondruch). The `TODO` part was introduced by commit:git|4a4a702e61d1c5585d522f1185a82a5685c554f6 which also does not give a clue what is intention here. Generally, my point is that it is strange that DTrace would report about rb_mRubyVMFrozenCore while TracePoint is happy to skip it. ---------------------------------------- Bug #18257: rb_mRubyVMFrozenCore is broken by GC run https://bugs.ruby-lang.org/issues/18257#change-104660 * Author: vo.x (Vit Ondruch) * Status: Closed * Priority: Normal * ruby -v: ruby 3.0.3p157 (2021-11-24 revision 3fb7d2cadc) [x86_64-linux] * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- 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