February 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:114915] [Ruby master Feature#19905] Introduce `Queue#peek`
by hi＠joaofernandes.me (Joao Fernandes) 13 Feb '24

13 Feb '24

Issue #19905 has been reported by hi(a)joaofernandes.me (Joao Fernandes). ---------------------------------------- Feature #19905: Introduce `Queue#peek` https://bugs.ruby-lang.org/issues/19905 * Author: hi(a)joaofernandes.me (Joao Fernandes) * Status: Open * Priority: Normal ---------------------------------------- This ticket proposes the introduction of the `Queue#peek` method, similar to what we can find in other object oriented languages such as Java and C#. This method is similar to `Queue#pop`, but does not change the data, nor does it require a lock. ``` q = Queue.new([1,2,3]) => #<Thread::Queue:0x00000001065d7148> q.peek => 1 q.peek => 1 ``` I have felt the need of this for debugging, but I think that it can also be of practical use for presentation. I believe that the only drawback could be that newcomers could misuse it in multi-threaded work without taking into account that this method is not thread safe. I also volunteer myself to implement this method. -- https://bugs.ruby-lang.org/

6 7

[ruby-core:116523] [Ruby master Bug#20230] Fix crash when passing large keyword splat to method accepting keywords and keyword splat
by jeremyevans0 (Jeremy Evans) 13 Feb '24

13 Feb '24

Issue #20230 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #20230: Fix crash when passing large keyword splat to method accepting keywords and keyword splat https://bugs.ruby-lang.org/issues/20230 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The following code causes a crash in Ruby 2.2-3.3 and master: ```ruby h = {} 1000000.times{|i| h[i.to_s.to_sym] = i} def f(kw: 1, **kws) end f(**h) ``` Inside a thread or fiber, the size of the keyword splat could be much smaller and still cause a crash. This is similar to the issue in #4040, but for keyword splats instead of positional splats. I found this issue while optimizing method calling by reducing implicit allocations. Given the following code: ```ruby def f(kw: , **kws) end kw = {kw: 1} f(**kw) ``` The `f(**kw)` call previously allocated two hashes callee side instead of a single hash. This is because `setup_parameters_complex` would extract the keywords from the keyword splat hash to the C stack, to attempt to mirror the case when literal keywords are passed without a keyword splat. Then, `make_rest_kw_hash` would build a new hash based on the extracted keywords that weren't used for literal keywords. I have submitted a pull request which changes the implementation so that if a keyword splat is passed, literal keywords are deleted from the keyword splat hash (or a copy of the hash if the hash is not mutable): https://github.com/ruby/ruby/pull/9776 In addition to fixing the bug, the new implementation also eliminates the unnecessary hash allocation. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:116706] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by Eregon (Benoit Daloze) 13 Feb '24

13 Feb '24

Issue #19117 has been updated by Eregon (Benoit Daloze). Oops, indeed. It seems a bit easier to me to read with the quotes: ``` /Users/byroot/.gem/ruby/3.2.2/gems/activerecord-7.1.2/lib/active_record/connection_adapters/abstract/connection_pool.rb:30:in 'ActiveRecord::Foo::Bar#checkin': wrong number of arguments (given 0, expected 1) (ArgumentError) ``` Also the `from ./test.rb:16:in block in Concrete#oops` above seems clearer with quotes: `from ./test.rb:16:in 'block in Concrete#oops'` I was searching for a long backtrace mixing many filenames/paths of different length but didn't find one at hand. That could be good to get a clearer idea of what's more readable (although obviously some of it is subjective). ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106722 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ``` module Foo class Bar def inspect 1 + '1' end end end p Foo::Bar.new ``` This code produce the following backtrace: ``` /tmp/foo.rb:4:in `+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `inspect' from /tmp/foo.rb:9:in `p' from /tmp/foo.rb:9:in `<main>' ``` This works, but on large codebases and large backtraces the method name isn't always all that revealing, most of the time you need to open many of the locations listed in the backtrace to really understand what is going on. I propose that we also include the owner name: ``` /tmp/foo.rb:4:in `Integer#+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `Foo::Bar#inspect' from /tmp/foo.rb:9:in `Kernel#p' from /tmp/foo.rb:9:in `<main>' ``` I believe that in many case it would allow to much better understand the backtrace without having to jump back and forth between it and the source code. This is inspired by @ivoanjo 's `backtracie` gem: https://github.com/ivoanjo/backtracie -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116705] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by ko1 (Koichi Sasada) 13 Feb '24

13 Feb '24

Issue #19117 has been updated by ko1 (Koichi Sasada). It should be: ``` /Users/byroot/.gem/ruby/3.2.2/gems/activerecord-7.1.2/lib/active_record/connection_adapters/abstract/connection_pool.rb:30:in ActiveRecord::Foo::Bar#checkin: wrong number of arguments (given 0, expected 1) (ArgumentError) ``` (I'm not sure the correct class name...) I meant that it may be easy to find method names by adding class name without using quotation marks. ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106721 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ``` module Foo class Bar def inspect 1 + '1' end end end p Foo::Bar.new ``` This code produce the following backtrace: ``` /tmp/foo.rb:4:in `+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `inspect' from /tmp/foo.rb:9:in `p' from /tmp/foo.rb:9:in `<main>' ``` This works, but on large codebases and large backtraces the method name isn't always all that revealing, most of the time you need to open many of the locations listed in the backtrace to really understand what is going on. I propose that we also include the owner name: ``` /tmp/foo.rb:4:in `Integer#+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `Foo::Bar#inspect' from /tmp/foo.rb:9:in `Kernel#p' from /tmp/foo.rb:9:in `<main>' ``` I believe that in many case it would allow to much better understand the backtrace without having to jump back and forth between it and the source code. This is inspired by @ivoanjo 's `backtracie` gem: https://github.com/ivoanjo/backtracie -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116559] [Ruby master Bug#20234] Segfault parsing begin statement inside method definition receiver
by tompng (tomoya ishida) 13 Feb '24

13 Feb '24

Issue #20234 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20234: Segfault parsing begin statement inside method definition receiver https://bugs.ruby-lang.org/issues/20234 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.4.0dev (2024-02-02T05:26:20Z master ccffc6ee09) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Segmentation fault parsing these code in Ruby 3.3.0 and 3.4.0dev ~~~ruby # Segmentation fault ruby -ce "def (begin;end).foo; end" ruby -ce "def (begin;else;end).foo; end" ruby -ce "def (begin;ensure;else;end).foo; end" ruby -e "RubyVM::AbstractSyntaxTree.parse('def (begin;end).foo; end')" # Ripper is OK ruby -rripper -e "p Ripper.sexp('def (begin;end).foo; end')" # Syntax OK ruby -ce "def (begin;rescue;end).foo; end" ruby -ce "def (begin;ensure;end).foo; end" ruby -ce "def (begin;rescue;else;end).foo; end" ~~~ ~~~ # ruby -ce "def (begin;end).foo; end" ruby: [BUG] Segmentation fault at 0x0000000000000000 ruby 3.4.0dev (2024-02-02T05:26:20Z master ccffc6ee09) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0001 p:0000 s:0003 E:001940 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x000000400189b2d8 RBP: 0xfffffffffffffffd RSP: 0x0000004001802d80 RAX: 0x0000000000000012 RBX: 0x0000004001803098 RCX: 0x0000004001cb6bb4 RDX: 0x0000000000000000 RDI: 0x0000004001802ef0 RSI: 0x00000040000ba888 R8: 0x0000000000000029 R9: 0x0000004001802ea0 R10: 0x0000004002192ef0 R11: 0x00000000000003b9 R12: 0x00000040000bacbe R13: 0x00000040018030b0 R14: 0x0000004001803720 R15: 0x00000040000ba340 EFL: 0x0000000000000246 -- C level backtrace information ------------------------------------------- /opt/ruby/lib/libruby.so.3.4(rb_print_backtrace+0x14) [0x4001b6fee1] /ruby/vm_dump.c:820 /opt/ruby/lib/libruby.so.3.4(rb_vm_bugreport) /ruby/vm_dump.c:1151 /opt/ruby/lib/libruby.so.3.4(rb_bug_for_fatal_signal+0x104) [0x4001962b44] /ruby/error.c:1065 /opt/ruby/lib/libruby.so.3.4(sigsegv+0x4d) [0x4001abb4cd] /ruby/signal.c:926 /lib/x86_64-linux-gnu/libc.so.6(0x400205c520) [0x400205c520] /opt/ruby/lib/libruby.so.3.4(ruby_yyparse+0x32) [0x400189b2d8] ./include/ruby/internal/arithmetic/long.h:144 /opt/ruby/lib/libruby.so.3.4(yycompile0+0xf5) [0x4001a49025] /ruby/parse.y:7738 /opt/ruby/lib/libruby.so.3.4(rb_suppress_tracing+0x114) [0x4001b73654] /ruby/vm_trace.c:487 /opt/ruby/lib/libruby.so.3.4(yycompile+0x63) [0x4001a25b7b] /ruby/parse.y:7794 /opt/ruby/lib/libruby.so.3.4(parser_compile_string) /ruby/parse.y:7857 /opt/ruby/lib/libruby.so.3.4(rb_ruby_parser_compile_string_path) /ruby/parse.y:7864 /opt/ruby/lib/libruby.so.3.4(rb_ruby_parser_compile_string) /ruby/parse.y:7870 /opt/ruby/lib/libruby.so.3.4(rb_parser_compile_string+0x57) [0x4001a25d07] /ruby/parse.y:16200 /opt/ruby/lib/libruby.so.3.4(process_options+0xc29) [0x4001ab6469] /ruby/ruby.c:2288 /opt/ruby/lib/libruby.so.3.4(ruby_process_options+0x146) [0x4001ab7526] /ruby/ruby.c:3012 /opt/ruby/lib/libruby.so.3.4(ruby_options+0xcc) [0x400196f88c] /ruby/eval.c:118 /opt/ruby/bin/ruby(rb_main+0x19) [0x400000117f] ./main.c:39 /opt/ruby/bin/ruby(main) ./main.c:58 /lib/x86_64-linux-gnu/libc.so.6(0x4002043d90) [0x4002043d90] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x4002043e40] [0x40000011d5] -- Other runtime information ----------------------------------------------- * Loaded script: ruby * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb 6 /opt/ruby/lib/ruby/3.4.0+0/x86_64-linux/enc/encdb.so 7 /opt/ruby/lib/ruby/3.4.0+0/x86_64-linux/enc/trans/transdb.so * Process memory map: 4000000000-4000001000 r--p 00000000 fe:01 1690625 /opt/ruby/bin/ruby 4000001000-4000002000 r-xp 00001000 fe:01 1690625 /opt/ruby/bin/ruby 4000002000-4000003000 r--p 00002000 fe:01 1690625 /opt/ruby/bin/ruby 4000003000-4000004000 r--p 00002000 fe:01 1690625 /opt/ruby/bin/ruby 4000004000-4000005000 rw-p 00003000 fe:01 1690625 /opt/ruby/bin/ruby 4000005000-40000cb000 rw-p 00000000 00:00 0 4001005000-4001006000 ---p 00000000 00:00 0 4001006000-4001806000 rw-p 00000000 00:00 0 [stack] 4001806000-4001808000 r--p 00000000 fe:01 1584490 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 4001808000-4001832000 r-xp 00002000 fe:01 1584490 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 4001832000-400183d000 r--p 0002c000 fe:01 1584490 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 400183d000-400183e000 ---p 00000000 00:00 0 400183e000-4001840000 r--p 00037000 fe:01 1584490 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 4001840000-4001842000 rw-p 00039000 fe:01 1584490 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 4001842000-4001846000 rw-p 00000000 00:00 0 4001846000-4001892000 r--p 00000000 fe:01 1690976 /opt/ruby/lib/libruby.so.3.4.0 4001892000-4001c9b000 r-xp 0004c000 fe:01 1690976 /opt/ruby/lib/libruby.so.3.4.0 4001c9b000-4001e27000 r--p 00455000 fe:01 1690976 /opt/ruby/lib/libruby.so.3.4.0 4001e27000-4001e3f000 r--p 005e0000 fe:01 1690976 /opt/ruby/lib/libruby.so.3.4.0 4001e3f000-4001e43000 rw-p 005f8000 fe:01 1690976 /opt/ruby/lib/libruby.so.3.4.0 4001e43000-4001e58000 rw-p 00000000 00:00 0 4001e5b000-4001e5d000 r--p 00000000 fe:01 1584639 /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 4001e5d000-4001e6e000 r-xp 00002000 fe:01 1584639 /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 4001e6e000-4001e74000 r--p 00013000 fe:01 1584639 /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 4001e74000-4001e75000 ---p 00019000 fe:01 1584639 /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 4001e75000-4001e76000 r--p 00019000 fe:01 1584639 /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 4001e76000-4001e77000 rw-p 0001a000 fe:01 1584639 /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 4001e77000-4001e81000 r--p 00000000 fe:01 1584537 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 4001e81000-4001ee0000 r-xp 0000a000 fe:01 1584537 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 4001ee0000-4001ef7000 r--p 00069000 fe:01 1584537 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 4001ef7000-4001ef8000 r--p 0007f000 fe:01 1584537 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 4001ef8000-4001ef9000 rw-p 00080000 fe:01 1584537 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 4001ef9000-4001efb000 r--p 00000000 fe:01 1584517 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 4001efb000-4001f0f000 r-xp 00002000 fe:01 1584517 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 4001f0f000-4001f28000 r--p 00016000 fe:01 1584517 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 4001f28000-4001f29000 ---p 0002f000 fe:01 1584517 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 4001f29000-4001f2a000 r--p 0002f000 fe:01 1584517 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 4001f2a000-4001f2b000 rw-p 00030000 fe:01 1584517 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 4001f2b000-4001f33000 rw-p 00000000 00:00 0 4001f33000-4001f41000 r--p 00000000 fe:01 1584560 /usr/lib/x86_64-linux-gnu/libm.so.6 4001f41000-4001fbd000 r-xp 0000e000 fe:01 1584560 /usr/lib/x86_64-linux-gnu/libm.so.6 4001fbd000-4002018000 r--p 0008a000 fe:01 1584560 /usr/lib/x86_64-linux-gnu/libm.so.6 4002018000-4002019000 r--p 000e4000 fe:01 1584560 /usr/lib/x86_64-linux-gnu/libm.so.6 4002019000-400201a000 rw-p 000e5000 fe:01 1584560 /usr/lib/x86_64-linux-gnu/libm.so.6 400201a000-4002042000 r--p 00000000 fe:01 1584508 /usr/lib/x86_64-linux-gnu/libc.so.6 4002042000-40021d7000 r-xp 00028000 fe:01 1584508 /usr/lib/x86_64-linux-gnu/libc.so.6 40021d7000-400222f000 r--p 001bd000 fe:01 1584508 /usr/lib/x86_64-linux-gnu/libc.so.6 400222f000-4002233000 r--p 00214000 fe:01 1584508 /usr/lib/x86_64-linux-gnu/libc.so.6 4002233000-4002235000 rw-p 00218000 fe:01 1584508 /usr/lib/x86_64-linux-gnu/libc.so.6 4002235000-4002244000 rw-p 00000000 00:00 0 4002244000-4002247000 r--p 00000000 fe:01 1584533 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 4002247000-400225e000 r-xp 00003000 fe:01 1584533 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 400225e000-4002262000 r--p 0001a000 fe:01 1584533 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 4002262000-4002263000 r--p 0001d000 fe:01 1584533 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 4002263000-4002264000 rw-p 0001e000 fe:01 1584533 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 4002264000-4002368000 rw-p 00000000 00:00 0 4002370000-4002380000 rw-p 00000000 00:00 0 4002388000-401b7e9000 rw-p 00000000 00:00 0 401b7f0000-401b800000 rw-p 00000000 00:00 0 401b810000-401b820000 rw-p 00000000 00:00 0 401b830000-401b840000 rw-p 00000000 00:00 0 401b850000-401b860000 rw-p 00000000 00:00 0 401b870000-401b880000 rw-p 00000000 00:00 0 401b889000-401b88a000 ---p 00000000 00:00 0 401b88a000-401c08a000 rw-p 00000000 00:00 0 401c08a000-401c08b000 ---p 00000000 00:00 0 401c08b000-401c12c000 rw-p 00000000 00:00 0 401c12c000-401c12d000 ---p 00000000 00:00 0 401c12d000-401c1ce000 rw-p 00000000 00:00 0 401c1ce000-401c1cf000 ---p 00000000 00:00 0 401c1cf000-401c270000 rw-p 00000000 00:00 0 401c270000-401c271000 ---p 00000000 00:00 0 401c271000-401c312000 rw-p 00000000 00:00 0 401c312000-401c313000 ---p 00000000 00:00 0 401c313000-401c3b4000 rw-p 00000000 00:00 0 401c3b4000-401c3b5000 ---p 00000000 00:00 0 401c3b5000-401c456000 rw-p 00000000 00:00 0 401c456000-401c457000 ---p 00000000 00:00 0 401c457000-401c4f8000 rw-p 00000000 00:00 0 401c4f8000-401c4f9000 ---p 00000000 00:00 0 401c4f9000-401c59a000 rw-p 00000000 00:00 0 401c59a000-401c59b000 ---p 00000000 00:00 0 401c59b000-401c63c000 rw-p 00000000 00:00 0 401c63c000-401c63d000 ---p 00000000 00:00 0 401c63d000-401c6de000 rw-p 00000000 00:00 0 401c6de000-401c6df000 ---p 00000000 00:00 0 401c6df000-401c780000 rw-p 00000000 00:00 0 401c780000-401c781000 ---p 00000000 00:00 0 401c781000-401c822000 rw-p 00000000 00:00 0 401c822000-401c823000 ---p 00000000 00:00 0 401c823000-401c8c4000 rw-p 00000000 00:00 0 401c8c4000-401c8c5000 ---p 00000000 00:00 0 401c8c5000-401c966000 rw-p 00000000 00:00 0 401c966000-401c967000 ---p 00000000 00:00 0 401c967000-401ca08000 rw-p 00000000 00:00 0 401ca08000-401ca09000 ---p 00000000 00:00 0 401ca09000-401caaa000 rw-p 00000000 00:00 0 401caaa000-401caab000 ---p 00000000 00:00 0 401caab000-401cb4c000 rw-p 00000000 00:00 0 401cb4c000-401cb4d000 ---p 00000000 00:00 0 401cb4d000-401cbee000 rw-p 00000000 00:00 0 401cbee000-401cbef000 ---p 00000000 00:00 0 401cbef000-401cc90000 rw-p 00000000 00:00 0 401cc90000-401cc91000 ---p 00000000 00:00 0 401cc91000-401cd32000 rw-p 00000000 00:00 0 401cd32000-401cd33000 ---p 00000000 00:00 0 401cd33000-401cdd4000 rw-p 00000000 00:00 0 401cdd4000-401cdd5000 ---p 00000000 00:00 0 401cdd5000-401ce76000 rw-p 00000000 00:00 0 401ce76000-401ce77000 ---p 00000000 00:00 0 401ce77000-401cf18000 rw-p 00000000 00:00 0 401cf18000-401cf19000 ---p 00000000 00:00 0 401cf19000-401cfba000 rw-p 00000000 00:00 0 401cfba000-401cfbb000 ---p 00000000 00:00 0 401cfbb000-401d05c000 rw-p 00000000 00:00 0 401d05c000-401d05d000 ---p 00000000 00:00 0 401d05d000-401d0fe000 rw-p 00000000 00:00 0 401d0fe000-401d0ff000 ---p 00000000 00:00 0 401d0ff000-401d1a0000 rw-p 00000000 00:00 0 401d1a0000-401d1a1000 ---p 00000000 00:00 0 401d1a1000-401d242000 rw-p 00000000 00:00 0 401d242000-401d243000 ---p 00000000 00:00 0 401d243000-401d2e4000 rw-p 00000000 00:00 0 401d2e4000-401d2e5000 ---p 00000000 00:00 0 401d2e5000-401d386000 rw-p 00000000 00:00 0 401d386000-401d387000 ---p 00000000 00:00 0 401d387000-401d428000 rw-p 00000000 00:00 0 401d428000-401d429000 ---p 00000000 00:00 0 401d429000-401d4ca000 rw-p 00000000 00:00 0 401d4ca000-401d4cb000 r--p 00000000 fe:01 3870170 /opt/ruby/lib/ruby/3.4.0+0/x86_64-linux/enc/encdb.so 401d4cb000-401d4cc000 r-xp 00001000 fe:01 3870170 /opt/ruby/lib/ruby/3.4.0+0/x86_64-linux/enc/encdb.so 401d4cc000-401d4cd000 r--p 00002000 fe:01 3870170 /opt/ruby/lib/ruby/3.4.0+0/x86_64-linux/enc/encdb.so 401d4cd000-401d4ce000 r--p 00002000 fe:01 3870170 /opt/ruby/lib/ruby/3.4.0+0/x86_64-linux/enc/encdb.so 401d4ce000-401d4cf000 rw-p 00003000 fe:01 3870170 /opt/ruby/lib/ruby/3.4.0+0/x86_64-linux/enc/encdb.so 401d4d0000-401d4e0000 rw-p 00000000 00:00 0 401d4ef000-401d4f0000 r--p 00000000 fe:01 3870214 /opt/ruby/lib/ruby/3.4.0+0/x86_64-linux/enc/trans/transdb.so 401d4f0000-401d4f1000 r-xp 00001000 fe:01 3870214 /opt/ruby/lib/ruby/3.4.0+0/x86_64-linux/enc/trans/transdb.so 401d4f1000-401d4f2000 r--p 00002000 fe:01 3870214 /opt/ruby/lib/ruby/3.4.0+0/x86_64-linux/enc/trans/transdb.so 401d4f2000-401d4f3000 r--p 00002000 fe:01 3870214 /opt/ruby/lib/ruby/3.4.0+0/x86_64-linux/enc/trans/transdb.so 401d4f3000-401d4f4000 rw-p 00003000 fe:01 3870214 /opt/ruby/lib/ruby/3.4.0+0/x86_64-linux/enc/trans/transdb.so 401d4f4000-401d52a000 r--- 00000000 fe:01 1690625 /opt/ruby/bin/ruby 401d52a000-401e852000 r--- 00000000 fe:01 1690976 /opt/ruby/lib/libruby.so.3.4.0 401e852000-401ff77000 rw-p 00000000 00:00 0 401ff77000-4020195000 r--- 00000000 fe:01 1584508 /usr/lib/x86_64-linux-gnu/libc.so.6 ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault ~~~ -- https://bugs.ruby-lang.org/

2 1

[ruby-core:116695] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by Eregon (Benoit Daloze) 13 Feb '24

13 Feb '24

Issue #19117 has been updated by Eregon (Benoit Daloze). I think without quotes, while it looks clean for a simple example of all short paths it can be slower/harder to find the method name with more realistic cases. For example in the case in https://bugs.ruby-lang.org/issues/19117#note-32, it would be: ``` /Users/byroot/.gem/ruby/3.2.2/gems/activerecord-7.1.2/lib/active_record/connection_adapters/abstract/connection_pool.rb:30:in checkin: wrong number of arguments (given 0, expected 1) (ArgumentError) ``` If the exception message contains `:` then it becomes quite hard to scan too. ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106710 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ``` module Foo class Bar def inspect 1 + '1' end end end p Foo::Bar.new ``` This code produce the following backtrace: ``` /tmp/foo.rb:4:in `+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `inspect' from /tmp/foo.rb:9:in `p' from /tmp/foo.rb:9:in `<main>' ``` This works, but on large codebases and large backtraces the method name isn't always all that revealing, most of the time you need to open many of the locations listed in the backtrace to really understand what is going on. I propose that we also include the owner name: ``` /tmp/foo.rb:4:in `Integer#+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `Foo::Bar#inspect' from /tmp/foo.rb:9:in `Kernel#p' from /tmp/foo.rb:9:in `<main>' ``` I believe that in many case it would allow to much better understand the backtrace without having to jump back and forth between it and the source code. This is inspired by @ivoanjo 's `backtracie` gem: https://github.com/ivoanjo/backtracie -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116694] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by byroot (Jean Boussier) 13 Feb '24

13 Feb '24

Issue #19117 has been updated by byroot (Jean Boussier). > Do we need quotes? I'm not attached to them, and I suppose removing them would also solve https://bugs.ruby-lang.org/issues/16495 / https://bugs.ruby-lang.org/issues/17107. ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106709 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ``` module Foo class Bar def inspect 1 + '1' end end end p Foo::Bar.new ``` This code produce the following backtrace: ``` /tmp/foo.rb:4:in `+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `inspect' from /tmp/foo.rb:9:in `p' from /tmp/foo.rb:9:in `<main>' ``` This works, but on large codebases and large backtraces the method name isn't always all that revealing, most of the time you need to open many of the locations listed in the backtrace to really understand what is going on. I propose that we also include the owner name: ``` /tmp/foo.rb:4:in `Integer#+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `Foo::Bar#inspect' from /tmp/foo.rb:9:in `Kernel#p' from /tmp/foo.rb:9:in `<main>' ``` I believe that in many case it would allow to much better understand the backtrace without having to jump back and forth between it and the source code. This is inspired by @ivoanjo 's `backtracie` gem: https://github.com/ivoanjo/backtracie -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116693] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by ko1 (Koichi Sasada) 13 Feb '24

13 Feb '24

Issue #19117 has been updated by ko1 (Koichi Sasada). Do we need quotes? From comment #28 ``` ./test.rb:10:in `Integer#+': String can't be coerced into Integer (TypeError) from ./test.rb:10:in `block in Concrete.oops' from ./test.rb:3:in `Abstract#oops' from ./test.rb:16:in `block in Concrete#oops' from <internal:kernel>:90:in `Kernel#tap' from ./test.rb:15:in `Concrete#oops' from ./test.rb:10:in `Concrete.oops' from ./test.rb:21:in `Method#call' from ./test.rb:21:in `<main>' ``` vs ``` ./test.rb:10:in Integer#+: String can't be coerced into Integer (TypeError) from ./test.rb:10:in block in Concrete.oops from ./test.rb:3:in Abstract#oops from ./test.rb:16:in block in Concrete#oops from <internal:kernel>:90:in Kernel#tap from ./test.rb:15:in Concrete#oops from ./test.rb:10:in Concrete.oops from ./test.rb:21:in Method#call from ./test.rb:21:in <main> ``` For example, python's case; ``` $ python3 Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> def foo(a): ... a + 10 ... >>> foo("str") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 2, in foo TypeError: can only concatenate str (not "int") to str ``` ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106705 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ``` module Foo class Bar def inspect 1 + '1' end end end p Foo::Bar.new ``` This code produce the following backtrace: ``` /tmp/foo.rb:4:in `+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `inspect' from /tmp/foo.rb:9:in `p' from /tmp/foo.rb:9:in `<main>' ``` This works, but on large codebases and large backtraces the method name isn't always all that revealing, most of the time you need to open many of the locations listed in the backtrace to really understand what is going on. I propose that we also include the owner name: ``` /tmp/foo.rb:4:in `Integer#+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `Foo::Bar#inspect' from /tmp/foo.rb:9:in `Kernel#p' from /tmp/foo.rb:9:in `<main>' ``` I believe that in many case it would allow to much better understand the backtrace without having to jump back and forth between it and the source code. This is inspired by @ivoanjo 's `backtracie` gem: https://github.com/ivoanjo/backtracie -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116691] [Ruby master Bug#20263] Backport https://github.com/ruby/ruby/pull/9498 to Ruby 3.3
by anton-stepanof (Anton Stepanov) 13 Feb '24

13 Feb '24

Issue #20263 has been reported by anton-stepanof (Anton Stepanov). ---------------------------------------- Bug #20263: Backport https://github.com/ruby/ruby/pull/9498 to Ruby 3.3 https://bugs.ruby-lang.org/issues/20263 * Author: anton-stepanof (Anton Stepanov) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Pull request: https://github.com/ruby/ruby/pull/9805 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115286] [Ruby master Bug#19991] rb_register_postponed_job async-signal-unsafety causes crash in GC
by kjtsanaktsidis (KJ Tsanaktsidis) 13 Feb '24

13 Feb '24

Issue #19991 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #19991: rb_register_postponed_job async-signal-unsafety causes crash in GC https://bugs.ruby-lang.org/issues/19991 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Our production application experienced an interpreter crash today that I’m fairly sure is the result of a bug in the `rb_register_postponed_job` infrastructure. ## Diagnosis I’ve attached a more complete version of the crash dump, but the key information I think is the following backtrace: ``` <internal:gc>:35: [BUG] Segmentation fault at 0x00000000000000c8 .... /usr/lib/libruby.so.3.1(rb_vm_bugreport+0x60c) [0xffffaaf57a6c] vm_dump.c:759 /usr/lib/libruby.so.3.1(rb_bug_for_fatal_signal+0xd8) [0xffffaad6d120] error.c:821 /usr/lib/libruby.so.3.1(sigsegv+0x58) [0xffffaaeb4350] signal.c:964 /usr/lib/libruby.so.3.1(sigill) (null):0 linux-vdso.so.1(__kernel_rt_sigreturn+0x0) [0xffffab20f78c] /usr/lib/libruby.so.3.1(rbimpl_atomic_exchange+0x0) [0xffffaad94018] gc.c:4081 /usr/lib/libruby.so.3.1(gc_finalize_deferred) gc.c:4081 /usr/lib/libruby.so.3.1(rb_postponed_job_flush+0x218) [0xffffaaf5dd60] vm_trace.c:1728 /usr/lib/libruby.so.3.1(rb_threadptr_execute_interrupts+0x328) [0xffffaaef7520] thread.c:2444 /usr/lib/libruby.so.3.1(vm_exec_core+0x4e54) [0xffffaaf41c6c] vm.inc:588 /usr/lib/libruby.so.3.1(rb_vm_exec+0x144) [0xffffaaf427cc] vm.c:2211 ``` I disassembled `gc_finalize_deferred` in GDB (different execution, so the addresses don’t line up - this is NOT from a core dump): ``` (gdb) disassemble gc_finalize_deferred Dump of assembler code for function gc_finalize_deferred: 0x0000fffff7cc3ff8 <+0>: stp x29, x30, [sp, #-48]! 0x0000fffff7cc3ffc <+4>: mov w1, #0x1 // #1 0x0000fffff7cc4000 <+8>: mov x29, sp 0x0000fffff7cc4004 <+12>: stp x19, x20, [sp, #16] 0x0000fffff7cc4008 <+16>: mov x19, x0 0x0000fffff7cc400c <+20>: add x20, x0, #0xc8 0x0000fffff7cc4010 <+24>: ldaxr w0, [x20] .... continues .... ``` Based on the line numbers from the debuginfo, the faulting instruction is likely to be `gc_finalize_deferred+24` (which is the inlined `rbimpl_atomic_exchange`). That would attempt a load of 0xc8 if x0 was zero - i.e. if `gc_finalize_deferred` was called with a NULL objspace. The enqueuing of `gc_finalize_deferred` with postponed job only happens in one place (in gc_sweep_page, [here](https://github.com/ruby/ruby/blob/5cff4c5aa375787924e2df5c0b981dd922b…) and if `objspace` was null there then the crash would have had to have already happened in `gc_sweep_page`. Thus, I think that `gc_finalize_deferred` was _enqueued_ into the postponed job list with a not-NULL argument, but the argument was corrupted whilst it was in `vm->postponed_job_buffer`, and if objspace was null there then the crash would have had to have already happened in `gc_sweep_page`. Thus, I think that `gc_finalize_deferred` was enqueued into the postponed job list with a not-NULL argument, but the argument was corrupted whilst it was in `vm->postponed_job_buffer`. I had a look at the postponed job code, which is of course very tricky because it needs to be async-signal-safe. More specifically: * It needs to work if run from a thread not holding the GVL * It needs to work if run from a thread, whilst another thread is actually executing `rb_postponed_job_flush` * It needs to work if run from a signal caught in a thread that is currently executing `rb_postponed_job_flush` (this rules out trivial mutex-based solutions) We use the Datadog continuous profiler in our application (CC: @ivoanjo ;), which calls `rb_postponed_job_register` to capture profiling samples. Thus, I think our application is likely to hit all of those scenarios semi-reguarly. My best guess at a plausible sequence of events, to generate this particular crash, is that: 1. `rb_postponed_job_flush` was running on thread T1. 2. There is a queued call to gc_finalize_deferred sitting in `vm->postponed_job_buffer[vm->postponed_job_index-1]`. 3. T1 executed the `ATOMIC_CAS` at vm_trace.c:1800, decrementing `vm->postponed_job_index` (which now equals `index - 1`) and determining that a job at index index should be run. 4. Thread T2 received a signal, and the Datadog continuous profiler called `rb_postponed_job_register_one(0, sample_from_postponed_job, NULL)` 5. T2 executed the `ATOMIC_CAS` at vm_trace.c:1679, re-incrementing `vm->postponed_job_index`. It’s now equal to `index` from T1 again. 6. T2 then executes the sets on `pjob->func` and `pjob->data` at vm_trace.c:1687. It sets `->func` to `sample_from_postponed_job` (from ddtrace), and `->data` to 0. 7. T1 then goes to call `(*pjob->func)(pjob->data)` at vm_trace.c:1802 8. Since there is no memory barrier between 6 & 7, T1 is allowed to see the effects of the set on `pjob->data` and not see that of `pjob->func`. 9, T1 thus calls `gc_finalize_deferred` (which it was meant to do) with an argument of 0 (which it was not). ## Solution Managing a thread-safe list of too-big-to-be-atomic objects (like `rb_postponed_job_t`) is really tricky. I think it might be best for this code if we use a combination of masking signals (to prevent manipulation of the postponed job list occurring during `rb_postponed_job_flush`, and using a semaphore to protect the list (since semaphores are required to be async-signal-safe on POSIX systems). I've implemented this in a PR here: https://github.com/ruby/ruby/pull/8856 It seems _slightly_ slower to do it this way - semaphores require system calls in the uncontended case, which is why they're async-signal-safe but also makes them more expensive than pthread mutexes, which don't, on most systems. I ran my branch through yjit bench: With my patch: ``` interp: ruby 3.3.0dev (2023-11-07T08:14:09Z ktsanaktsidis/post.. 342f30f566) [arm64-darwin22] yjit: ruby 3.3.0dev (2023-11-07T08:14:09Z ktsanaktsidis/post.. 342f30f566) +YJIT [arm64-darwin22] -------------- ----------- ---------- --------- ---------- ------------ ----------- bench interp (ms) stddev (%) yjit (ms) stddev (%) yjit 1st itr interp/yjit activerecord 31.2 3.4 17.0 5.7 1.29 1.83 chunky-png 543.5 0.5 367.0 0.7 1.40 1.48 erubi-rails 1044.2 0.6 564.7 1.3 1.69 1.85 hexapdf 1517.6 3.1 917.6 1.2 1.46 1.65 liquid-c 37.1 1.3 28.9 1.4 0.89 1.29 liquid-compile 39.0 1.4 29.9 1.6 0.76 1.30 liquid-render 89.9 1.8 39.6 1.4 1.37 2.27 lobsters 598.2 1.7 435.4 5.2 0.63 1.37 mail 79.8 3.1 52.5 1.0 0.79 1.52 psych-load 1441.5 1.7 885.4 0.5 1.60 1.63 railsbench 1010.8 1.0 609.3 1.3 1.24 1.66 ruby-lsp 40.9 3.4 29.2 30.0 0.66 1.40 sequel 39.8 1.8 33.0 2.4 1.18 1.21 -------------- ----------- ---------- --------- ---------- ------------ ----------- ``` Without the patch: ``` interp: ruby 3.3.0dev (2023-11-07T07:56:43Z master 5a2779d40f) [arm64-darwin22] yjit: ruby 3.3.0dev (2023-11-07T07:56:43Z master 5a2779d40f) +YJIT [arm64-darwin22] -------------- ----------- ---------- --------- ---------- ------------ ----------- bench interp (ms) stddev (%) yjit (ms) stddev (%) yjit 1st itr interp/yjit activerecord 31.3 3.3 16.7 5.5 1.36 1.88 chunky-png 521.6 0.6 348.8 0.7 1.40 1.50 erubi-rails 1038.9 0.9 566.3 1.2 1.70 1.83 hexapdf 1501.9 1.1 951.7 3.9 1.42 1.58 liquid-c 36.7 1.2 29.3 1.7 0.86 1.25 liquid-compile 38.8 1.1 29.7 3.7 0.73 1.31 liquid-render 92.2 0.9 38.3 1.0 1.47 2.40 lobsters 582.5 2.0 429.8 5.6 0.59 1.36 mail 77.9 1.3 54.8 0.9 0.76 1.42 psych-load 1419.1 0.7 887.7 0.5 1.60 1.60 railsbench 1017.8 1.1 609.9 1.2 1.24 1.67 ruby-lsp 41.0 2.2 28.8 28.8 0.64 1.43 sequel 36.0 1.5 30.4 1.8 1.11 1.18 -------------- ----------- ---------- --------- ---------- ------------ ----------- ``` Maybe this is within the noise floor, but I thought I should bring it up. -- https://bugs.ruby-lang.org/

2 3