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

[ruby-core:116738] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by naruse (Yui NARUSE) 14 Feb '24

14 Feb '24

Issue #18576 has been updated by naruse (Yui NARUSE). byroot (Jean Boussier) wrote in #note-33: > I'd like to change `Encoding::BINARY.inspect` from `"#<Encoding:ASCII-8BIT>"` to `"#<Encoding:ASCII-8BIT (BINARY)>"`. > > Would that be acceptable? I agree the idea. ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106757 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ### Context I'm now used to it, but something that confused me for years was errors such as: ```ruby >> "fée" + "\xFF".b (irb):3:in `+': incompatible character encodings: UTF-8 and ASCII-8BIT (Encoding::CompatibilityError) ``` When you aren't that familiar with Ruby, it's really not evident that `ASCII-8BIT` basically means "no encoding" or "binary". And even when you know it, if you don't read carefully it's very easily confused with `US-ASCII`. The `Encoding::BINARY` alias is much more telling IMHO. ### Proposal Since `Encoding::ASCII_8BIT` has been aliased as `Encoding::BINARY` for years, I think renaming it to `BINARY` and then making asking `ASCII_8BIT` the alias would significantly improve usability without backward compatibility concerns. The only concern I could see would be the consistency with a handful of C API functions: - `rb_encoding *rb_ascii8bit_encoding(void)` - `int rb_ascii8bit_encindex(void)` - `VALUE rb_io_ascii8bit_binmode(VALUE io)` But that's for much more advanced users, so I don't think it's much of a concern. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116065] [Ruby master Feature#20160] rescue keyword for case expressions
by lloeki (Loic Nageleisen) 14 Feb '24

14 Feb '24

Issue #20160 has been reported by lloeki (Loic Nageleisen). ---------------------------------------- Feature #20160: rescue keyword for case expressions https://bugs.ruby-lang.org/issues/20160 * Author: lloeki (Loic Nageleisen) * Status: Open * Priority: Normal ---------------------------------------- It is frequent to find this piece of hypothetical Ruby code: ``` case (parsed = parse(input)) when Integer then handle_int(parsed) when Float then handle_float(parsed) end ``` What if we need to handle `parse` raising a hypothetical `ParseError`? Currently this can be done in two ways. Either option A, wrapping `case .. end`: ``` begin case (parsed = parse(input)) when Integer then handle_int(parsed) when Float then handle_float(parsed) # ... end rescue ParseError # ... end ``` Or option B, guarding before `case`: ``` begin parsed = parse(input) rescue ParseError # ... end case parsed when Integer then handle_int(parsed) when Float then handle_float(parsed) # ... end ``` The difference between option A and option B is that: - option A `rescue` is not localised to parsing and also covers code following `when` (including calling `===`), `then`, and `else`, which may or may not be what one wants. - option B `rescue` is localised to parsing but moves the definition of the variable (`parsed`) and the call to what is actually done (`parse(input)`) far away from `case`. With option B in some cases the variable needs to be introduced even though it might not be needed in `then` parts (e.g if the call in `case` is side-effectful or its value simply leading to branching decision logic). The difference becomes important when rescued exceptions are more general (e.g `Errno` stuff, `ArgumentError`, etc..), as well as when we consider `ensure` and `else`. I feel like option B is the most sensible one in general. I would like to suggest a new syntax: ``` case (parsed = parse(input)) when Integer then handle_int(parsed) when Float then handle_float(parsed) rescue ParseError # ... rescue ArgumentError # ... else # ... fallthrough for all rescue and when cases ensure # ... called always end ``` If more readability is needed as to what these `rescue` are aimed to handle one could optionally write like this: ``` case (parsed = parse(input)) rescue ParseError # ... rescue ArgumentError # ... when Integer then handle_int(parsed) when Float then handle_float(parsed) ... else # ... ensure # ... end ``` Examples: - A made-up pubsub streaming parser with internal state, abstracting away reading from source: ``` parser = Parser.new(io) loop do case parser.parse # blocks for reading io in chunks rescue StandardError => e if parser.can_recover?(e) # tolerate failure, ignore next else emit_fail(e) end when :integer emit_integer(parser.last) when :float emit_float(parser.last) when :done # e.g EOF reached, IO closed, YAML --- end of doc, XML top-level closed, whatever makes sense emit_done break else parser.rollback # e.g rewinds io, we may not have enough data ensure parser.checkpoint # e.g saves io position for rollback end end ``` - Network handling, extrapolated from [ruby docs](https://ruby-doc.org/stdlib-2.7.1/libdoc/net/http/rdoc/Net/HTTP.html#…: ``` case (response = Net::HTTP.get_response(URI(uri_str)) rescue URI::InvalidURIError # handle URI errors rescue SocketError # handle socket errors rescue # other general errors when Net::HTTPSuccess response when Net::HTTPRedirection then location = response['location'] warn "redirected to #{location}" fetch(location, limit - 1) else response.value ensure @counter += 1 end ``` Credit: the idea initially came to me from [this article](https://inside.java/2023/12/15/switch-case-effect/), and thinking how it could apply to Ruby. -- https://bugs.ruby-lang.org/

5 8

[ruby-core:116729] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by matz (Yukihiro Matsumoto) 14 Feb '24

14 Feb '24

Issue #19117 has been updated by matz (Yukihiro Matsumoto). I am OK with adding method owner. I am against removing quote signs. Matz. ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106748 * 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:116728] [Ruby master Feature#16495] Inconsistent quotes in error messages
by matz (Yukihiro Matsumoto) 14 Feb '24

14 Feb '24

Issue #16495 has been updated by matz (Yukihiro Matsumoto). I am positive. I'd say go. We need to experiment anyway. Matz. ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-106747 * Author: Kolano (Kenneth Kolano) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Error messages use inconsistent pairs of quotes, for instance: ``` -e:1:in `<main>': undefined local variable or method `foo' for main:Object (NameError) ``` where a back tick is used on the left-hand side, and a single quote is used on the right. The same quotes should be used on either side of the elements being quoted. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116315] [Ruby master Misc#20193] DevMeeting-2024-02-14
by mame (Yusuke Endoh) 14 Feb '24

14 Feb '24

Issue #20193 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #20193: DevMeeting-2024-02-14 https://bugs.ruby-lang.org/issues/20193 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2024/02/14 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2024/02/11. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

12 15

[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